Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [PATCH 1/4] xen: xen-pciback: Replace GFP_ATOMIC with GFP_KERNEL
 in pcistub_probe
To:     Boris Ostrovsky <boris.ostrovsky@oracle.com>, jgross@suse.com,
        gregkh@linuxfoundation.org
Cc:     xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org
References: <1523286216-26345-1-git-send-email-baijiaju1990@gmail.com>
 <b07f0a27-f09d-1617-ab9e-ebbc761cb3a4@oracle.com>
 <74fe5dd3-fb85-bed8-82b6-a9fb7a3a376d@gmail.com>
 <9703e77f-35e8-aa11-9ddb-fdc322efd6d2@oracle.com>
From:   Jia-Ju Bai <baijiaju1990@gmail.com>
Message-ID: <311acb17-1cab-bb1a-b612-23e7523f6709@gmail.com>
Date:   Wed, 11 Apr 2018 09:00:40 +0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.2.0
MIME-Version: 1.0
In-Reply-To: <9703e77f-35e8-aa11-9ddb-fdc322efd6d2@oracle.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


On 2018/4/10 23:01, Boris Ostrovsky wrote:
> 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@gmail.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?

Okay, I will send a patch for it soon.
You can have a look :)


Best wishes,
Jia-Ju Bai