>limit. And if I read the unix_release_sock() right we do not remove
>corresponding skb's from the listen queue. Oh, fsck! It may explain the
Hmm unix_release_sock(sk) should destroy all skb queued to sk sock (see
unix_destroy_sock()).
>unix_gc() breakage - we may end up doing funny things to dead sockets.
>
>What about
>257c257
>< if (UNIXCB(skb).attr & MSG_SYN) {
>---
>> if ((UNIXCB(skb).attr & MSG_SYN) && !skb->sk->dead) {
If you use `!' you are allowing a dead socket to be shrunk from the
garbage collector. So in the garbage collector we are just not touching
peer-dead-socks awaiting for an accept().
And if the sock is dead I can't see major problems in playing with it as
far as the code has the big kernel lock held and unix_gc() doesn't sleep.
Andrea Arcangeli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/