linux-kernel - Re: [RFC v2 1/1] fs/namespace: defer RCU sync for MNT

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] [day] [month] [year] [list]

Date: Wed, 1 May 2024 21:41:53 +0800
From: Ian Kent <raven@...maw.net>
To: Lucas Karpinski <lkarpins@...hat.com>, Al Viro <viro@...iv.linux.org.uk>
Cc: brauner@...nel.org, jack@...e.cz, linux-fsdevel@...r.kernel.org,
 linux-kernel@...r.kernel.org, alexl@...hat.com, echanude@...hat.com,
 ikent@...hat.com, ahalaney@...hat.com
Subject: Re: [RFC v2 1/1] fs/namespace: defer RCU sync for MNT_DETACH umount

On 30/4/24 21:25, Lucas Karpinski wrote:
> On Fri, Apr 26, 2024 at 09:09:41PM +0100, Al Viro wrote:
>>> +		call_rcu(&drelease->rcu, delayed_mount_release);
>> ... which is a bad idea, since call_rcu() callbacks are run
>> from interrupt context.  Which makes blocking in them a problem.
>>
> Thanks for the quick review.
>
> Documentation/RCU/checklist.rst suggests switching to queue_rcu_work()
> function in scenarios where the callback function can block. This seems
> like it would fix the issue you found, while still providing similar
> performance improvements.

You know I've been looking at this and you can see that mntput() will 
just call

mntput_no_expire() which queues work to do the bulk of the work and returns.


So I'm wondering what would happen to the timing if you simply didn't 
call the

rcu wait for the lazy umount case and left everything else as it is.


Ian