Netdev List
 help / color / mirror / Atom feed
* The mess that is SIGPIPE
@ 2007-08-19 12:00 linux
  0 siblings, 0 replies; only message in thread
From: linux @ 2007-08-19 12:00 UTC (permalink / raw)
  To: netdev

I noticed that FreeBSD has a useful SOL_SOCKET option, SO_NOSIGPIPE, which
is a "sticky" version of MSG_NOSIGNAL.  Particularly useful for libraries,
it disables SIGPIPE on a particular socket without disabling it globally.

Anyway, this led me to look at the implementation of SIGPIPE and
MSG_NOSIGNAL and...  it's a bit of a mess.  Some places honor
MSG_NOSIGNAL, but there are a lot of code paths that don't appear to.

So I started thinking about a cleanup...

Currently, SIGPIPE is sent from dozens of places that return EPIPE.
What if they could all be deleted and just a few system calls: write(),
writev(), send(), sendto() and sendmsg() (oh, yes, and sendfile())
could check for EPIPE from the VFS calls they make and generate SIGPIPE
appropriately?

The only thing is figuring out where in the call chain to put it.

sys_send()
-> sys_sendto()
   -> sock_sendmsg()
      -> __sock_sendmsg()
         -> sock->ops->sendmsg

sys_write()
-> vfs_write()
   -> do_sync_write
      -> filp->f_op->aio_write
         -> sock_aio_write()
            -> do_sock_write()
               -> __sock_(sendmsg()

sys_writev()
-> vfs_writev()
   -> do_readv_writev()
      -> do_loop_readv_writev()
         -> file->f_op->write
            -> ????
               -> sock_aio_write()
                  -> do_sock_write()
                     -> __sock_(sendmsg()

kernel_sendmsg() also calls sock_sendmsg(), and it would save a bunch
of fiddling with MSG_NOSIGNAL if kernel_sendmsg() never generated signals.

That implies that the check should be at the sys_sendto() layer or higher.


Anyway, looking into implementing this, I found a zillion places where
the logic looked a little unclear, such as OCFS2 code.  I'm not convinced
that a bug there can't generate SIGPIPE unexpectedly.


Anyway, before I tackle this rewrite, I'd like to ask if someone knows
what the code is *supposed* to be doing, and can confirm that SIGPIPE
should be generated if and only if the write is done by a user-level
system call that can return EPIPE.  So all the buried network file
systems should never generate it.  Is that right?

Thanks for the insights.

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2007-08-19 12:06 UTC | newest]

Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-08-19 12:00 The mess that is SIGPIPE linux

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox