Messages in this thread | | | Date | Tue, 2 Mar 1999 12:31:29 -0500 (EST) | From | Alexander Viro <> | Subject | Re: [Real fix] Re: Kernel panic: can't push onto full stack |
| |
On Tue, 2 Mar 1999 kuznet@ms2.inr.ac.ru wrote:
> 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/
| |