On Tue, Jun 3, 2014 at 6:55 AM, Peter Zijlstra <[email protected]> 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 [email protected] -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
