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

On Tue, Jun 6, 2017 at 11:25 PM, Dmitry Torokhov
[off-list ref] wrote:

On Tue, Jun 06, 2017 at 09:56:47PM -0700, Andy Lutomirski wrote:

quoted

On Tue, Jun 6, 2017 at 5:22 PM, Luis R. Rodriguez [off-list ref] wrote:

quoted

On Tue, Jun 06, 2017 at 06:11:51PM -0400, Theodore Ts'o wrote:

quoted

On Tue, Jun 06, 2017 at 06:47:34PM +0200, Luis R. Rodriguez wrote:

quoted

On Tue, Jun 06, 2017 at 03:53:16PM +0100, Alan Cox wrote:

We rely on swait, and swait right now only uses -ERESTARTSYS. Are
you saying we could mask out -ERESTARTSYS and map it to -ERESTARTNOINTR
or -ERESTARTNOHAND if we see fit for some future functionality / need ?

I think that has essentially nothing to do with swait.  User code does
some syscall.  That syscall triggers a firmware load.  The caller gets
a signal.  If you're going to let firmware load get interrupted, you
need to consider what the syscall is.

I think it is way too complicated and I do not think driver writers will
stand a chance of implementing this correctly, given that often firmware
load might be triggered indirectly and by multitude of syscalls.

That's what I meant, but I said it unclearly.  I meant that, if we're
going to start allowing interruption, we would need to audit all the
callers.  Ugh.

I suppose we could have request_firmware_interruptable(), but that
seems like it's barely worth it.

--Andy