The mesh_path_node_copy() can be called like this: mesh_path_add `- write_lock(&pathtbl_resize_lock); /* ! */ `- mesh_table_grow `- ->copy_node `- mesh_path_node_copy thus, the GFP_KERNEL is not suitable here. The acceptable fix, I suppose, is make this allocation GPF_ATOMIC - the mpath_node being allocated is 4 pointers, i.e. this allocation is small enough to survive even under a moderate memory pressure. Signed-off-by: Pavel Emelyanov <xemul@openvz.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>tirimbino
parent
00242c40a1
commit
8566dc3fca
Loading…
Reference in new issue