lkml.org 
[lkml]   [2020]   [Jan]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH] mm/memory_hotplug: Fix remove_memory() lockdep splat
On Fri, Jan 24, 2020 at 4:56 AM Michal Hocko <mhocko@kernel.org> wrote:
>
> On Fri 10-01-20 13:27:24, Dan Williams wrote:
> > On Fri, Jan 10, 2020 at 9:42 AM David Hildenbrand <david@redhat.com> wrote:
> [...]
> > > For your reference (roughly 5 months ago, so not that old)
> > >
> > > https://lkml.kernel.org/r/20190724143017.12841-1-david@redhat.com
> >
> > Oh, now I see the problem. You need to add that lock so far away from
> > the __add_memory() to avoid lock inversion problems with the
> > acpi_scan_lock. The organization I was envisioning would not work
> > without deeper refactoring.
>
> Sorry to come back to this late. Has this been resolved?

The mem_hotplug_lock lockdep splat fix in this patch has not landed.
David and I have not quite come to consensus on how to resolve online
racing removal. IIUC David wants that invalidation to be
pages_correctly_probed(), I would prefer it to be directly tied to the
object, struct memory_block, that remove_memory_block_devices() has
modified, mem->section_count = 0.

...or are you referring to the discussion about acpi_scan_lock()? I
came around to agreeing with your position that documenting was better
than adding superfluous locking especially because the
acpi_scan_lock() is take so far away from where the device_hotplug
lock is needed.

\
 
 \ /
  Last update: 2020-01-24 19:05    [W:0.078 / U:0.380 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site