linux-kernel - Re: [PATCH][RFC] ipc,fs: use rcu_work to free struct ipc

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: <20220218053120.GV4285@paulmck-ThinkPad-P17-Gen-1>
Date:   Thu, 17 Feb 2022 21:31:20 -0800
From:   "Paul E. McKenney" <paulmck@...nel.org>
To:     Al Viro <viro@...iv.linux.org.uk>
Cc:     Rik van Riel <riel@...riel.com>, linux-kernel@...r.kernel.org,
        kernel-team@...com, Chris Mason <clm@...com>,
        linux-fsdevel@...r.kernel.org,
        Giuseppe Scrivano <gscrivan@...hat.com>
Subject: Re: [PATCH][RFC] ipc,fs: use rcu_work to free struct ipc_namespace

On Fri, Feb 18, 2022 at 03:29:56AM +0000, Al Viro wrote:
> On Thu, Feb 17, 2022 at 03:36:20PM -0500, Rik van Riel wrote:
> > The patch works, but a cleanup question for Al Viro:
> > 
> > How do we get rid of #include "../fs/mount.h" and the raw ->mnt_ns = NULL thing
> > in the cleanest way?
> 
> Hell knows...  mnt_make_shortterm(mnt) with big, fat warning along the lines of
> "YOU MUST HAVE AN RCU GRACE PERIOD BEFORE YOU DROP THAT REFERENCE!!!", perhaps?

Rik's patch uses queue_rcu_work(), which always uses a normal grace
period.  Therefore, one way of checking that an RCU grace period has
elapsed is as follows:

Step 1: Get a snapshot of the normal grace-period state:

	rcuseq = get_state_synchronize_rcu(); // In mainline

Step 2: Verify that a normal grace period has elapsed since step 1:

	WARN_ON_ONCE(!poll_state_synchronize_rcu(rcuseq));

These functions are both in mainline.

And apologies for my answer on IRC being unhelpful.  Here is hoping that
this is more to the point.

							Thanx, Paul

------------------------------------------------------------------------

PS.  Just in case it ever becomes relevant, if Rik's patch were instead
     to use synchronize_rcu() or synchronize_rcu_expedited() to wait for
     the grace period, it would be necessary to capture both the normal
     and expedited grace-period state:

Step 1: Get a snapshot of both the normal and the expedited state:

	rcuseq = get_state_synchronize_rcu();
	rcuxseq = get_state_synchronize_rcu_expedited();

Step 2: Verify that either a normal or expedited grace period has
	elapsed since step 1:

	WARN_ON_ONCE(!poll_state_synchronize_rcu(rcuseq) &&
		     !poll_state_synchronize_rcu_expedited(rcuxseq));

The reason for doing both is that synchronize_rcu_expedited() and
synchronize_rcu() can both be switched between using normal and expedited
grace periods.  Not just at boot time, but also at runtime.  Fun.

The two expedited functions are in -rcu rather than mainline, so if
someone does ever need them, please let me know.