> Hello!
>
> > Alexey, could you comment on test for tsk->dead in unix_accept()?
> > Just what is tested there? It had been added in 2.1.124 and AFAICS there
> > is no way to ->dead on a passed sock to be set. Was it just-in-case test
> > or should it be unix_peer(tsk)->dead? IOW, if somebody did connect()
> > and then close() before we accept() should we return this (hung)
> > connection on accept()?
>
> Yes, it is crap. Apparently, I meaned unix_peer(tsk)->dead,
> but, luckily, did mistake.
>
> Why luckily? 8) Because we have to pass even dead connection request
> to accept(), otherwise blocking accept() may hang after select().
>
> I do not see any graceful solution now. I have to think.
>
> Possible ways are:
>
> - to purge not yet accepted conns on close of connecting socket
> and to set a flag in succesful select() and to return some error
> to blocking accept(), if queue contains only dead socks or empty.
> - to purge not yet accepted conns on close of connecting socket,
> except for the last one.
- block on close() after select(). Even uglier.
- make unix_gc() sweep such skb's and call it on select() (OK, on
corresponding method).
Notice that either way we are handling a nasty race to
applications: if all you are going to do is to connect, write something
and close the connection there is no way to know if the data we've passed
will not be eaten by close() - it may happen before accept() on server
end. I'm at loss here - looks like we *have* to do it to avoid DoS found
by Andrea. Are there any other protocol families with non-blocking
connect()? Kstati, interesno chto po etomu powodu skazhet Katelbrunner ;-)
I.e. WTF does 4.4BSD do? Hmm... time to look into FreeBSD kernel. Their GC
misses listen queues, but it's an unrelated exploit, so...
-
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/