After checking all possible call chains to firmware_map_add_hotplug(), my tool finds that this function is never called in atomic context, namely never in an interrupt handler or holding a spinlock. I manually check the code, and find that this function is only called by add_memory_resource() that calls mem_hotplug_begin(), and mem_hotplug_begin() calls mutex_lock() that can sleep, so it indicates that firmware_map_add_hotplug() can call function which can sleep. Thus GFP_ATOMIC is not necessary, and it can be replaced with GFP_KERNEL.
This is found by a static analysis tool named DCNS written by myself. And I also manually audit the result. Signed-off-by: Jia-Ju Bai <[email protected]> --- drivers/firmware/memmap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/firmware/memmap.c b/drivers/firmware/memmap.c index 5de3ed2..598eb05 100644 --- a/drivers/firmware/memmap.c +++ b/drivers/firmware/memmap.c @@ -297,7 +297,7 @@ int __meminit firmware_map_add_hotplug(u64 start, u64 end, const char *type) entry = firmware_map_find_entry_bootmem(start, end - 1, type); if (!entry) { - entry = kzalloc(sizeof(struct firmware_map_entry), GFP_ATOMIC); + entry = kzalloc(sizeof(struct firmware_map_entry), GFP_KERNEL); if (!entry) return -ENOMEM; } else { -- 1.7.9.5
