linux-kernel - Re: [PATCH v4 2/2] virtiofs: use GFP_NOFS when enqueuing request through kworker

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <8264705a-1dc0-45a7-92d9-7395e1aa99db@linux.alibaba.com>
Date: Wed, 4 Sep 2024 20:12:11 +0800
From: Jingbo Xu <jefflexu@...ux.alibaba.com>
To: Hou Tao <houtao@...weicloud.com>, linux-fsdevel@...r.kernel.org
Cc: Miklos Szeredi <miklos@...redi.hu>, Vivek Goyal <vgoyal@...hat.com>,
 Stefan Hajnoczi <stefanha@...hat.com>,
 Bernd Schubert <bernd.schubert@...tmail.fm>,
 "Michael S . Tsirkin" <mst@...hat.com>, Matthew Wilcox
 <willy@...radead.org>, Benjamin Coddington <bcodding@...hat.com>,
 linux-kernel@...r.kernel.org, virtualization@...ts.linux.dev,
 houtao1@...wei.com
Subject: Re: [PATCH v4 2/2] virtiofs: use GFP_NOFS when enqueuing request
 through kworker

On 9/4/24 11:53 AM, Hou Tao wrote:
> 
> 
> On 9/3/2024 5:34 PM, Jingbo Xu wrote:
>>
>> On 8/31/24 5:37 PM, Hou Tao wrote:
>>> From: Hou Tao <houtao1@...wei.com>
>>>
>>> When invoking virtio_fs_enqueue_req() through kworker, both the
>>> allocation of the sg array and the bounce buffer still use GFP_ATOMIC.
>>> Considering the size of the sg array may be greater than PAGE_SIZE, use
>>> GFP_NOFS instead of GFP_ATOMIC to lower the possibility of memory
>>> allocation failure and to avoid unnecessarily depleting the atomic
>>> reserves. GFP_NOFS is not passed to virtio_fs_enqueue_req() directly,
>>> GFP_KERNEL and memalloc_nofs_{save|restore} helpers are used instead.
>>>
>>> It may seem OK to pass GFP_NOFS to virtio_fs_enqueue_req() as well when
>>> queuing the request for the first time, but this is not the case. The
>>> reason is that fuse_request_queue_background() may call
>>> ->queue_request_and_unlock() while holding fc->bg_lock, which is a
>>> spin-lock. Therefore, still use GFP_ATOMIC for it.
>> Actually, .wake_pending_and_unlock() is called under fiq->lock and
>> GFP_ATOMIC is requisite.
> 
> Er, but virtio_fs_wake_pending_and_unlock() unlocks fiq->lock before
> queuing the request.

Alright, I missed that :(

-- 
Thanks,
Jingbo