linux-kernel - Re: [PATCH RFC] fs,ipc: batch RCU synchronization in free

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]

Date:   Mon, 15 Aug 2022 22:40:26 +0100
From:   Al Viro <viro@...iv.linux.org.uk>
To:     Rik van Riel <riel@...riel.com>
Cc:     linux-kernel@...r.kernel.org,
        "Eric W. Biederman" <ebiederm@...ssion.com>,
        Alexey Gladkov <legion@...nel.org>, linux-fs@...r.kernel.org,
        kernel-team@...com
Subject: Re: [PATCH RFC] fs,ipc: batch RCU synchronization in free_ipc

On Mon, Aug 15, 2022 at 05:26:20PM -0400, Rik van Riel wrote:
> TL;DR: it runs better than it looks, and I am looking for ideas on how to make it look better

> Unfortunately there seems to be a tradeoff between temporarily
> allocating things on the stack, and having slightly uglier code,
> or adding a struct rcu_work to the struct vfsmount.
> 
> I am not entirely happy with the way this code looks, and hoping
> for suggestions on how to improve it.
> 
> However, I am quite happy with how this code runs. Between batching
> the kern_unmount RCU synchronization, moving to the expedited RCU
> grace period in kern_unmount_array, and grabbing things off the
> llist that were added after the work item started, freeing ipc
> namespaces is 2-3 orders of magnitude faster than before, and
> able to keep up with the test case above.

IMO you are going in wrong direction with that; it's a long story,
and I've partial writeup on that, but I won't have it ready for
posting until the end of the week.  Put it that way - there's
a possibility of reorganizing the way mount refcounts work,
eliminating this synchronize_rcu().  RCU delay still has to happen
in some form, but we get smarter ways to wait for it.

Anyway, it's about 15 pages of writeup right now, and it's going
to be a major massage, part for the coming cycle, part for the
next one.  I'll post it to fsdevel later this week, will make sure
to Cc you.