On 04/10/2018 10:31 AM, Jia-Ju Bai wrote:
I don't see why it needs to be ATOMIC, it's sysfs access. Can you send a
On 2018/4/10 22:27, Boris Ostrovsky wrote:
On 04/09/2018 11:03 AM, Jia-Ju Bai wrote:Thanks for your reply :)
pcistub_probe() is never called in atomic context.What about use of GFP_ATOMIC in pcistub_reg_add()?
This function is only set as ".probe" in struct pci_driver.
Despite never getting called from atomic context,
pcistub_probe() calls kmalloc() with GFP_ATOMIC,
which does not sleep for allocation.
GFP_ATOMIC is not necessary and can be replaced with GFP_KERNEL,
which can sleep and improve the possibility of sucessful allocation.
This is found by a static analysis tool named DCNS written by myself.
And I also manually check it.
Signed-off-by: Jia-Ju Bai <baijiaju1990@xxxxxxxxx>
I find pcistub_reg_add() is called by pcistub_quirk_add().
And pcistub_quirk_add() is called in the macro DRIVER_ATTR().
I am not sure whether DRIVER_ATTR() can make the function called in
atomic context,
so I do not analyze it in my tool.
patch to fix it as well?