Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1659259

Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback

From Theodore Ts'o <tytso@mit.edu>
Newsgroups linux.kernel
Subject Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback
Date 2017-06-07 00:20 +0200
Message-ID <tPuZs-6kh-9@gated-at.bofh.it> (permalink)
References (5 earlier) <tLyIj-4Vw-61@gated-at.bofh.it> <tLyIj-4Vw-59@gated-at.bofh.it> <tP6Nr-7zW-1@gated-at.bofh.it> <tPo7D-1Hh-1@gated-at.bofh.it> <tPpQ5-2QG-11@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Tue, Jun 06, 2017 at 06:47:34PM +0200, Luis R. Rodriguez wrote:
> On Tue, Jun 06, 2017 at 03:53:16PM +0100, Alan Cox wrote:
> > Yep everyone codes
> > 
> > 	write(disk_file, "foo", 3);
> > 
> > not while(..) blah around it.

In general I/O to tty devices and other character mode devices was
where you definitely needed to check for EINTR/EAGAIN because that was
the place where historically Unix systems would interrupt system calls
--- e.g., a user typing control-Z, for example.

And in general writes to file systems and block devices in *general*
were never interrupted by signals, although that was always a
non-portable assumption.

So I've always subscribed to the "be liberal in what you accept,
conservative in what you send" rule of thumb.  Which is to say, any
programs *I* write I'll in general always check for EINTR/EAGAIN and
check for partial writes, but in general, as a kernel program I try to
adhere to the long-standing Unix trandition for disk based files.

This does beg the question about whether firmware devices are more
like tty devices or block devices or files, though.  If before signals
never caused them to return EINTR/EAGAIN, then it's probably best to
not break backwards compatbility.

That being said, not that you also have the option of using
-ERESTARTNOINTR (always restart the system call, regardless of how the
sighandle flags were set), and -ERESTARTNOHAND (restart the system
call always if there was no signal handler and the process was not
killed), in addition to -ERESTARTSYS.  So that might be another option
that's fairly easy to implement or experiment with.

       	      	      		   - Ted

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback "Luis R. Rodriguez" <mcgrof@kernel.org> - 2017-05-25 00:40 +0200
  Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback Andy Lutomirski <luto@kernel.org> - 2017-05-25 06:20 +0200
    Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback "Fuzzey, Martin" <mfuzzey@parkeon.com> - 2017-05-25 10:30 +0200
      Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback ebiederm@xmission.com (Eric W. Biederman) - 2017-05-26 13:20 +0200
        Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on  fallback "Luis R. Rodriguez" <mcgrof@kernel.org> - 2017-05-26 21:50 +0200
          Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback Dmitry Torokhov <dmitry.torokhov@gmail.com> - 2017-05-27 03:30 +0200
            Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on  fallback Dmitry Torokhov <dmitry.torokhov@gmail.com> - 2017-05-27 03:30 +0200
              Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on  fallback "Luis R. Rodriguez" <mcgrof@kernel.org> - 2017-06-05 22:30 +0200
                Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on  fallback Martin Fuzzey <mfuzzey@parkeon.com> - 2017-06-06 11:10 +0200
                Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on  fallback "Luis R. Rodriguez" <mcgrof@kernel.org> - 2017-06-06 18:40 +0200
                Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on  fallback "Luis R. Rodriguez" <mcgrof@kernel.org> - 2017-06-06 20:00 +0200
                Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on  fallback Alan Cox <alan@linux.intel.com> - 2017-06-06 17:00 +0200
                Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on  fallback "Luis R. Rodriguez" <mcgrof@kernel.org> - 2017-06-06 18:50 +0200
                Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on  fallback "Luis R. Rodriguez" <mcgrof@kernel.org> - 2017-06-06 20:00 +0200
                Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on  fallback Theodore Ts'o <tytso@mit.edu> - 2017-06-07 00:20 +0200
                Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on  fallback "Luis R. Rodriguez" <mcgrof@kernel.org> - 2017-06-07 02:30 +0200
                Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback Andy Lutomirski <luto@kernel.org> - 2017-06-07 07:00 +0200
                Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on  fallback Dmitry Torokhov <dmitry.torokhov@gmail.com> - 2017-06-07 08:30 +0200
                Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on  fallback Alan Cox <alan@linux.intel.com> - 2017-06-07 14:30 +0200
            Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback "Luis R. Rodriguez" <mcgrof@kernel.org> - 2017-05-27 03:30 +0200
      Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on  fallback "Luis R. Rodriguez" <mcgrof@kernel.org> - 2017-05-26 21:50 +0200
        Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on  fallback "Luis R. Rodriguez" <mcgrof@kernel.org> - 2017-05-27 03:30 +0200
        Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback "Fuzzey, Martin" <mfuzzey@parkeon.com> - 2017-05-27 03:50 +0200

csiph-web