Thread (21 messages) 21 messages, 7 authors, 2017-06-09

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

From: Luis R. Rodriguez <hidden>
Date: 2017-06-09 21:29:09
Also in: linux-fsdevel, lkml

Possibly related (same subject, not in this thread)

On Thu, Jun 8, 2017 at 6:33 PM, Luis R. Rodriguez [off-list ref] wrote:
On Thu, Jun 8, 2017 at 6:14 PM, Andy Lutomirski [off-list ref] wrote:
quoted
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.
There are actually two audits worth evaluating if what we've concluded
is fair game:

  a) firmware sync calls on interruptible paths
  b) use of swait / old interruptible waits on sysfs paths
And as I noted in the other thread -- another possible issue could be
any swait / interruptable wait on init or probe. Provided any child
completes and the kernel code for wait handler does abort, that
request would be terminated. This could for instance happen at bootup
as modules load and any child from the loader terminates.

We already have Coccinelle grammar to hunt for "though shall not
request firmware on init or probe", such SmPL grammar could be in turn
be repruposed to hunt for these types of conditions.

  Luis
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help