* Ingo Molnar <mingo@elte.hu> wrote:

> temporary solution to turn off slock related false positives: the 
> slock is pretty much the only lock type in the kernel that is half 
> spinlock, half waitqueue. "Process level" and "softirq level" uses of 
> slock are excluded - albeit the spinlock itself is not permanently 
> held in process context.
> 
> The right solution will be to annotate slock uses with 
> acquire()/release(). (i.e. to treat sock_owned_by_user() flagged areas 
> as an exclusion area too)

i've got the right solution coded up too - it was a fairly 
straightforward process of teaching a new lock type (sk_lock) to the 
validator.

Miles, do the two attached patches (ontop of -mm4) fix your problem too? 
[you should unapply the previous lockdep_off()/on() patch i sent)

Andrew, i'd suggest to not apply the two attached patches yet - while 
they work fine for me we first should see whether they fix Miles' 
problem too.

Herbert, do the acquire/release semantics as expressed in the 
lockdep-annotate-slock.patch match sk_lock semantics?

the patch also makes the slock names more readable:

 neptune:/home/mingo> cat /proc/lockdep | grep AF
 c07f7088 OPS:    4125 FD:    1 BD:    2 -...: slock-AF_UNIX
 c07f7188 OPS:    1375 FD:    2 BD:    1 --..: sk_lock-AF_UNIX
 c07f7100 OPS:     252 FD:    1 BD:    2 -...: slock-AF_NETLINK
 c07f7200 OPS:      84 FD:    2 BD:    1 --..: sk_lock-AF_NETLINK
 c07f7090 OPS:    2641 FD:   20 BD:    4 -+..: slock-AF_INET
 c07f7190 OPS:     851 FD:   64 BD:    1 --..: sk_lock-AF_INET
 c07f7108 OPS:      27 FD:    1 BD:    2 -...: slock-AF_PACKET
 c07f7208 OPS:       9 FD:    4 BD:    1 --..: sk_lock-AF_PACKET
 c07f7091 OPS:     285 FD:   44 BD:    2 -+..: slock-AF_INET/1

(that should make it easier to tell which sk_lock class is mentioned in 
a validator message, instead of the current slock#2/slock#3 
enumeration.)

	Ingo