Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1651591
| From | "Luis R. Rodriguez" <mcgrof@kernel.org> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback |
| Date | 2017-05-26 21:50 +0200 |
| Message-ID | <tLtpf-1zn-3@gated-at.bofh.it> (permalink) |
| References | (2 earlier) <tKMDD-84u-1@gated-at.bofh.it> <tKN6F-8dQ-1@gated-at.bofh.it> <tKSpH-3gE-1@gated-at.bofh.it> <tKWjF-5Mt-27@gated-at.bofh.it> <tLlrH-5bT-9@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Fri, May 26, 2017 at 06:09:29AM -0500, Eric W. Biederman wrote:
> "Fuzzey, Martin" <mfuzzey@parkeon.com> writes:
> >>>> Maybe SIGCHLD shouldn't interrupt firmware loading?
> >
> > I don't think there's a way of doing that without disabling all
> > signals (ie using the non interruptible wait variants).
> > It used to be that way (which is why I only ran into this after
> > updating from an ancient 3.16 kernel to a slightly less ancient 4.4)
> > But there are valid reasons for wanting to be able to interrupt
> > firmware loading (like being able to kill the userspace helper)
>
> Perhaps simply using a killable wait and not a fully interruptible
> wait would be better?
What do you mean by a killable wait BTW?
ret = swait_event_interruptible_timeout() is being used right now.
The problem is we have:
if (ret != 0 && fw_st->status == FW_STATUS_ABORTED)
return -ENOENT;
if (!ret)
return -ETIMEDOUT;
return ret < 0 ? ret : 0;
The (!ret) return -ETIMEDOUT ensures that if there was no time left
then we know we ran out of time.
The ret < 0 ? ret makes sure we send any errors
swait_event_interruptible_timeout() sent.
But the caller of this code has:
if (fw_state_is_aborted(&buf->fw_st))
retval = -EAGAIN;
else if (buf->is_paged_buf && !buf->data)
retval = -ENOMEM;
And this retval is used. so we mask all errors with -EAGAIN.
So Martin is asking us to let us send -ERESTARTSYS back down to drivers.
These potentially could send back down to probe, and so finit_module()
could get this.
Another use case is a custom syfs knob which triggers a request_firmware(),
in such case this is a simple write(), but Anroid is configured to retry
if -ERESTARTSYS so I gather it will *retry* writing again to this file
if -ERESTARTSYS was sent and therefore triggering another firmware request.
> It sounds like the code really is not prepared for an truly
> interruptible wait here.
Can you clarify what you mean?
Luis
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll 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