Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 17 Feb 2022 21:31:20 -0800
From:   "Paul E. McKenney" <paulmck@kernel.org>
To:     Al Viro <viro@zeniv.linux.org.uk>
Cc:     Rik van Riel <riel@surriel.com>, linux-kernel@vger.kernel.org,
        kernel-team@fb.com, Chris Mason <clm@fb.com>,
        linux-fsdevel@vger.kernel.org,
        Giuseppe Scrivano <gscrivan@redhat.com>
Subject: Re: [PATCH][RFC] ipc,fs: use rcu_work to free struct ipc_namespace
Message-ID: <20220218053120.GV4285@paulmck-ThinkPad-P17-Gen-1>
Reply-To: paulmck@kernel.org
References: <20220217153620.4607bc28@imladris.surriel.com>
 <Yg8StKzTWh+7FLuA@zeniv-ca.linux.org.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Yg8StKzTWh+7FLuA@zeniv-ca.linux.org.uk>
Precedence: bulk

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.