Re: [PATCH 0/6 v2] nfs_localio: fixes for races and errors from older compilers

Paul E. McKenney
2025-05-10T00:16:42Z

On Fri, May 09, 2025 at 05:02:29PM -0400, Mike Snitzer wrote:
> On Fri, May 09, 2025 at 12:01:19PM -0400, Chuck Lever wrote:
> > [ adding Paul McK ]
> >
> > On 5/8/25 8:46 PM, NeilBrown wrote:
> > > This is a revised version a the earlier series. I've actually tested
> > > this time and fixed a few issues including the one that Mike found.
> >
> > As Mike mentioned in a previous thread, at this point, any fix for this
> > issue will need to be applied to recent stable kernels as well. This
> > series looks a bit too complicated for that.
> >
> > I expect that other subsystems will encounter this issue eventually,
> > so it would be beneficial to address the root cause. For that purpose, I
> > think I like Vincent's proposal the best:
> >
> > https://lore.kernel.org/linux-nfs/8c67a295-8caa-4e53-a764-f691657bbe62@wanadoo.fr/raw
> >
> > None of this is to say that Neil's patches shouldn't be applied. But
> > perhaps these are not a broad solution to the RCU compilation issue.
>
> I agree with your suggested approach. Hopefully Paul agrees and
> Vincent can polish a patch for near-term inclusion.

The main issue that I see with Vincent's patch is that we need the
asterisks ("*") to remain in order to mesh with the definition of __rcu
and to work correctly with the "sparse" tool. The __rcu address space
applies to the pointed-to data, not the pointer. So removing the
asterisks from __rcu_access_pointer() and friends would require the
various uses of __rcu to move to the other side of the asterisk,
right? For example, this:

struct pci_dev __rcu *pdev;

would need to become this:

struct pci_dev *__rcu pdev

And the same for the more than 1,000 other uses of __rcu.

Or am I missing something here? In particular, did it turn out that
sparse and the other tools were all happy with this change?

Thanx, Paul

> It'll be at least a week before I can put adequate time to reviewing
> and testing Neil's patchset.
>
> Thanks,
> Mike