[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHQdGtTotdPj9ijyCqnAcZeK=vmUe3R1pFaTzXwzQ3pu0Q8WPA@mail.gmail.com>
Date: Tue, 3 Jun 2014 10:25:23 -0400
From: Trond Myklebust <trond.myklebust@...marydata.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: John Stultz <john.stultz@...aro.org>,
Jeff Layton <jeff.layton@...marydata.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Linux NFS Mailing List <linux-nfs@...r.kernel.org>,
Linux Kernel mailing list <linux-kernel@...r.kernel.org>,
Ingo Molnar <mingo@...e.hu>
Subject: Re: nfs4_do_reclaim lockdep pop in v3.15.0-rc1
On Tue, Jun 3, 2014 at 6:55 AM, Peter Zijlstra <peterz@...radead.org> wrote:
> 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.
As far as I can see, there are 2 users of raw_seqcount_begin outside
the NFS code: __d_lookup_rcu and netdev_get_name. Neither one of them
are using it as part of a lock (no waiting), but rather as a notifier
of conflicting events. As far as I can tell, there are therefore no
users that benefit from lockdep checking here.
So is there any reason why we shouldn't just revert that part of
commit 1ca7d67cf5d5a, and leave it to future generations to add a
lockdep-enabled version if and when they need it?
--
Trond Myklebust
Linux NFS client maintainer, PrimaryData
trond.myklebust@...marydata.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists