On Fri, May 26, 2017 at 2:26 PM, Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> wrote: > On Fri, May 26, 2017 at 12:46 PM, Luis R. Rodriguez <mcgrof@xxxxxxxxxx> wrote: >> On Fri, May 26, 2017 at 06:09:29AM -0500, Eric W. Biederman wrote: >>> "Fuzzey, Martin" <mfuzzey@xxxxxxxxxxx> 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? > > https://lwn.net/Articles/288056/ > > I think only interrupting firmware loading with fatal signals would > make a lot of sense. > >> >> ret = swait_event_interruptible_timeout() is being used right now. > > It looks like we are missing swait_event_killable*(), but I do not > think it would be hard to add. What should we do for stable ? Is this a *stable* issue ? Luis -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
