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:
pgptg8VvjU5PL.pgp
Description: PGP signature
