>
>
> 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/