Julian Anastasov (uli@linux.tu-varna.acad.bg) wrote:
> 2. accept() the connection
> 3. fcntl(connected_socket,F_SETFL,O_NONBLOCK|O_ASYNC|O_RDWR)
> 4. fcntl(connected_socket,F_SETSIG,sig)
> 5. fcntl(connected_socket,F_SETOWN,again_my_pid)
> 6. read(connected_socket...), sigwaitinfo()
>[has possible races, so]
> My proposal: is it possible to add SO_INHERITOWN or other
> socket/file (F_COPYOWN) option suitable for listening sockets
> with the main goal to let sys_accept() to copy the fd owner after
> get_fd(2.2.x) or sock_map_fd(2.3.x) in net/socket.c.
Yep. You're not the first to notice this.
Zach Brown has been finding and working around races just
like this while writing phhttpd. In email to Zach and me,
sct@redhat.com proposed:
> One thing we can do to deal with some of this is to have a new fcntl to
> augment F_SETOWN, FASYNC and F_SETSIG. A F_SETFAST() would perform a
> setsig and a setown at once, _and_ would accept a poll struct into which
> it would fill the current state of the socket. That would provide a
> single-syscall socket setup mechanism which guarantees not to lose any
> events (events that happened before the SETFAST would be returned in the
> poll struct).
Here's another possible race:
User closes fd 5. Events for fd 5 are still in the signal queue.
User does accept(), which returns a new fd 5.
Your proposed new ioctl could eliminate both the race you're worried about
*and* the one I just pointed out if it also delivered a signal that said
"fd 5 created". The user would then discard any events for fd 5
received after the close() but before the "fd 5 created" signal.
That "fd 5 created" signal would tell the user code to reset its
"fd 5 poll status" variable, which would then be updated by the sigio
signals whenever fd 5's poll status changed. No need for an initial
call to poll() or a poll struct * in F_SETFAST then.
- Dan
-
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/
This archive was generated by hypermail 2b29 : Wed Feb 23 2000 - 21:00:25 EST