Re: [lock validator] inet6_destroy_sock(): soft-safe -> soft-unsafe lock dependency

["David S. Miller" <davem@davemloft.net>]

From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Tue, 31 Jan 2006 21:27:58 +1100

> tcp_close is only called from process context.  The rule for sk_dst_lock
> is that it must also only be obtained in process context.  On the other
> hand, it is true that sk_lock can be obtained in softirq context.
> 
> In this particular case, sk_dst_lock is obtained by tcp_close with
> softirqs disabled.  This is not a problem in itself since we're not
> trying to get sk_dst_lock from a real softirq context (as opposed to
> process context with softirq disabled).
> 
> I believe this warning comes about because the validator creates a
> dependency between sk_lock and sk_dst_lock.  It then infers from this
> dependency that in softirq contexts where sk_lock is obtained the code
> may also attempt to obtain sk_dst_lock.
> 
> This inference is where the validator errs.  sk_dst_lock is never
> (or should never be, and as far as I can see none of the traces show
> it to do so) obtained in a real softirq context.

Herbert's analysis is correct.  This unique locking strategy
is used by tcp_close() because at this point it knows that
every single reference to this socket in the system is gone
once it takes the socket lock with BH disabled.

And that known invariant is why this is correct, and the locking
validator has no way to figure this out.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/