Re: Warning in net/ipv4/af_inet.c:154

Eric Dumazet
2010-05-27T04:21:20Z

Le mercredi 26 mai 2010 à 21:06 -0700, David Miller a écrit :
> From: Anton Blanchard <anton@samba.org>
> Date: Thu, 27 May 2010 13:56:17 +1000
>
> > I'm somewhat confused by the two stage locking in the socket lock
> > (ie sk_lock.slock and sk_lock.owned).
> >
> > What state should the socket lock be in for serialising updates of
> > sk_forward_alloc? In some cases we appear to update it with sk_lock.slock =
> > unlocked, sk_lock.owned = 1:
>
> If sh_lock.owned=1 the user has grabbed exclusive sleepable lock on the
> socket, it does this via something approximating:
>
> retry:
> spin_lock(&sk_lock.slock);
> was_locked = sk_lock.owned;
> if (!was_locked)
> sk_lock.owned = 1;
> spin_unlock(&sk_lock.slock);
> if (was_locked) {
> sleep_on(condition(sk_lock.owned));
> goto retry;
> }
>
> This allows user context code to sleep with exclusive access to the
> socket.
>
> Code that cannot sleep takes the spinlock, and queues the work if the
> owner field if non-zero. Else, it keeps the spinlock held and does
> the work.
>
> In either case, socket modifications are thus done completely protected
> from other contexts.
>
>

Yes, but not on the case one user context uses the 'slow locking', and
another uses the 'fast locking'.

I am working on a patch now.