diff options
author | David Hildenbrand <david@redhat.com> | 2019-11-30 17:54:14 -0800 |
---|---|---|
committer | Linus Torvalds <torvalds@linux-foundation.org> | 2019-12-01 12:59:04 -0800 |
commit | 848e19ad3c3352b6e0906f05b282a3e22c67c98f (patch) | |
tree | 3e07546dd9726cde595bcb59df30fb464d3a455d /mm/memory_hotplug.c | |
parent | aba9817da150e9dcf4c599c0508c38d1971d66e1 (diff) | |
download | linux-848e19ad3c3352b6e0906f05b282a3e22c67c98f.tar.bz2 |
drivers/base/memory.c: drop the mem_sysfs_mutex
The mem_sysfs_mutex isn't really helpful. Also, it's not really clear
what the mutex protects at all.
The device lists of the memory subsystem are protected separately. We
don't need that mutex when looking up. creating, or removing
independent devices. find_memory_block_by_id() will perform locking on
its own and grab a reference of the returned device.
At the time memory_dev_init() is called, we cannot have concurrent
hot(un)plug operations yet - we're still fairly early during boot. We
don't need any locking.
The creation/removal of memory block devices should be protected on a
higher level - especially using the device hotplug lock to avoid
documented issues (see Documentation/core-api/memory-hotplug.rst) - or
if that is reworked, using similar locking.
Protecting in the context of these functions only doesn't really make
sense. Especially, if we would have a situation where the same memory
blocks are created/deleted at the same time, there is something horribly
going wrong (imagining adding/removing a DIMM at the same time from two
call paths) - after the functions succeeded something else in the
callers would blow up (e.g., create_memory_block_devices() succeeded but
there are no memory block devices anymore).
All relevant call paths (except when adding memory early during boot via
ACPI, which is now documented) hold the device hotplug lock when adding
memory, and when removing memory. Let's document that instead.
Add a simple safety net to create_memory_block_devices() in case we
would actually remove memory blocks while adding them, so we'll never
dereference a NULL pointer. Simplify memory_dev_init() now that the
lock is gone.
Link: http://lkml.kernel.org/r/20190925082621.4927-1-david@redhat.com
Signed-off-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Oscar Salvador <osalvador@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'mm/memory_hotplug.c')
0 files changed, 0 insertions, 0 deletions