Messages in this thread | | | Date | Tue, 2 Mar 1999 12:55:41 -0500 (EST) | From | Alexander Viro <> | Subject | Re: [Real fix] Re: Kernel panic: can't push onto full stack |
| |
On Tue, 2 Mar 1999, Alexander Viro wrote:
> > > 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).
Darn. Screw #4 - it doesn't solve anything. Add #5: block on close() (maybe make it an setsockopt()-controllable). BTW, from my reading of kern/uipc_userreq.c it looks like freebsd-hackers folks might be also interested in situation - I'm not on FreeBSD box, but from what I see in source they are also vulnerable...
- 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/
| |