> On Mon, 1 Mar 1999, Alexander Viro wrote:
>
> >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().
Don't trace their queues.
> 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.
Except that unix_destroy_timer() can kfree() it at any moment. And
*that* is not protected by kernel_lock.
Proper behaviour would be to take those skb's to a separate list
and then kill them on reap phase. Or simply kill the peer skb immediately
on unix_release_sock().
-
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/