Re: nfs4_do_reclaim lockdep pop in v3.15.0-rc1

[Peter Zijlstra]

On Mon, Jun 02, 2014 at 08:19:00PM -0700, John Stultz wrote:
> On Mon, Jun 2, 2014 at 5:59 PM, Trond Myklebust
> <trond.myklebust@xxxxxxxxxxxxxxx> wrote:
> > On Mon, Jun 2, 2014 at 6:49 PM, John Stultz <john.stultz@xxxxxxxxxx> wrote:
> >> On Mon, Jun 2, 2014 at 3:42 PM, Trond Myklebust
> >> <trond.myklebust@xxxxxxxxxxxxxxx> wrote:
> >>> The so_reclaim_seqcount only exists in order to tell the other threads
> >>> that they may need to replay file open or file lock requests that have
> >>> raced with state recovery (because those threads got scheduled out
> >>> after their RPC calls ran, but before they managed to set up the
> >>> tracking of the new state). It is basically an edge condition
> >>> killer...
> >>
> >> Would then swapping the acquisition order, so the seqcount is taken
> >> before the so_lock at the top of nfs4_reclaim_open_state() avoid this
> >> then, without having to disable lockdep?
> >>
> >
> > I can change the write seqcount to use raw_write_seqcount(), but that
> 
> So this doesn't address my suggestion to change the locking order...
> is that solution not feasible?
> 
> > doesn't answer the question of why raw_seqcount_begin() is the _only_
> > object out there with a "raw_" prefix, that doesn't explicitly disable
> > lockdep checking.
> >
> > What justifies the inconsistency?
> 
> Here's the naming discussion...
> https://lkml.org/lkml/2014/1/2/404
> 

Ah, I think I see what Trond means; so raw_write_seqcount_{begin,end}()
are without lockdep, _however_ raw_seqcount_begin() is with lockdep.

This is inconsistent within the same API (seqcount/seqlock).

Yes, we should fix that.

raw_seqcount_begin() is a variant of read_seqcount_begin() but without
the spin loop in. Maybe we should find a new name for this.

Attachment: pgpRupo62cJMv.pgp
Description: PGP signature