Messages in this thread | | | Date | Fri, 26 May 2017 21:46:40 +0200 | From | "Luis R. Rodriguez" <> | Subject | Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback |
| |
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
| |