Commit c6a8093
drivers/base/memory: add node id parameter to add_memory_block()
Patch series "mm/memory_hotplug: fixup crash during uevent handling", v4.
we have some udev rules trying to read the sysfs attribute 'valid_zones'
during an memory 'add' event, causing a crash in zone_for_pfn_range().
Debugging found that mem->nid was set to NUMA_NO_NODE, which crashed in
NODE_DATA(nid). Further analysis revealed that we're running into a race
with udev event processing: add_memory_resource() has this function calls:
1) __try_online_node()
2) arch_add_memory()
3) create_memory_block_devices()
-> calls device_register() -> memory 'add' event
4) node_set_online()/__register_one_node()
-> calls device_register() -> node 'add' event
5) register_memory_blocks_under_node()
-> sets mem->nid
Which, to the uninitated, is ... weird ...
Why do we try to online the node in 1), but only register the node in 4)
_after_ we have created the memory blocks in 3) ? And why do we set the
'nid' value in 5), when the uevent (which might need to see the correct
'nid' value) is sent out in 3) ? There must be a reason, I'm sure ...
So here's a small patchset to fixup uevent ordering. The first patch adds
a 'nid' parameter to add_memory_blocks() (to avoid mem->nid being
initialized with NUMA_NO_NODE), and the second patch reshuffles the code
in add_memory_resource() to fully initialize the node prior to calling
create_memory_block_devices() so that the node is valid at that time and
uevent processing will see correct values in sysfs.
This patch (of 3):
We have some udev rules trying to read the sysfs attribute 'valid_zones'
during an memory 'add' event, causing a crash in zone_for_pfn_range().
Debugging found that mem->nid was set to NUMA_NO_NODE, which crashed in
NODE_DATA(nid). Further analysis revealed that we're running into a race
with udev event processing: add_memory_resource() has this function calls:
1) __try_online_node()
2) arch_add_memory()
3) create_memory_block_devices()
-> calls device_register() -> memory 'add' event
4) node_set_online()/__register_one_node()
-> calls device_register() -> node 'add' event
5) register_memory_blocks_under_node()
-> sets mem->nid
Which, to the uninitated, is ... weird ...
Why do we try to online the node in 1), but only register the node in 4)
_after_ we have created the memory blocks in 3) ? And why do we set the
'nid' value in 5), when the uevent (which might need to see the correct
'nid' value) is sent out in 3) ? There must be a reason, I'm sure ...
So here's a small patchset to fixup uevent ordering. The first patch adds
a 'nid' parameter to add_memory_blocks() (to avoid mem->nid being
initialized with NUMA_NO_NODE), and the second patch reshuffles the code
in add_memory_resource() to fully initialize the node prior to calling
create_memory_block_devices() so that the node is valid at that time and
uevent processing will see correct values in sysfs.
This patch (of 3):
Add a 'nid' parameter to add_memory_block() to initialize the memory block
with the correct node id.
Link: https://lkml.kernel.org/r/[email protected]
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Hannes Reinecke <[email protected]>
Acked-by: David Hildenbrand <[email protected]>
Acked-by: Oscar Salvador <[email protected]>
Reviewed-by: Donet Tom <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>1 parent 1367da7 commit c6a8093
1 file changed
+4
-11
lines changed| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
809 | 809 | | |
810 | 810 | | |
811 | 811 | | |
812 | | - | |
| 812 | + | |
813 | 813 | | |
814 | 814 | | |
815 | 815 | | |
| |||
827 | 827 | | |
828 | 828 | | |
829 | 829 | | |
830 | | - | |
| 830 | + | |
831 | 831 | | |
832 | 832 | | |
833 | 833 | | |
| |||
854 | 854 | | |
855 | 855 | | |
856 | 856 | | |
857 | | - | |
858 | | - | |
859 | | - | |
860 | | - | |
861 | | - | |
862 | | - | |
863 | | - | |
864 | 857 | | |
865 | 858 | | |
866 | 859 | | |
| |||
900 | 893 | | |
901 | 894 | | |
902 | 895 | | |
903 | | - | |
| 896 | + | |
904 | 897 | | |
905 | 898 | | |
906 | 899 | | |
| |||
1005 | 998 | | |
1006 | 999 | | |
1007 | 1000 | | |
1008 | | - | |
| 1001 | + | |
1009 | 1002 | | |
1010 | 1003 | | |
1011 | 1004 | | |
| |||
0 commit comments