[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <9703e77f-35e8-aa11-9ddb-fdc322efd6d2@oracle.com>
Date: Tue, 10 Apr 2018 11:01:46 -0400
From: Boris Ostrovsky <boris.ostrovsky@...cle.com>
To: Jia-Ju Bai <baijiaju1990@...il.com>, jgross@...e.com,
gregkh@...uxfoundation.org
Cc: xen-devel@...ts.xenproject.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/4] xen: xen-pciback: Replace GFP_ATOMIC with GFP_KERNEL
in pcistub_probe
On 04/10/2018 10:31 AM, Jia-Ju Bai wrote:
>
>
>
> On 2018/4/10 22:27, Boris Ostrovsky wrote:
>> On 04/09/2018 11:03 AM, Jia-Ju Bai wrote:
>>> pcistub_probe() is never called in atomic context.
>>> 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@...il.com>
>> What about use of GFP_ATOMIC in pcistub_reg_add()?
>
> Thanks for your reply :)
> 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.
I don't see why it needs to be ATOMIC, it's sysfs access. Can you send a
patch to fix it as well?
Thanks.
-boris
Powered by blists - more mailing lists