From: ebiederm@xmission.com (Eric W. Biederman)
To: "Fuzzey, Martin" <mfuzzey@parkeon.com>
Cc: Andy Lutomirski <luto@kernel.org>,
"Luis R. Rodriguez" <mcgrof@kernel.org>,
"Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>,
Linux API <linux-api@vger.kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Greg KH <gregkh@linuxfoundation.org>,
Daniel Wagner <wagi@monom.org>,
David Woodhouse <dwmw2@infradead.org>,
jewalt@lgsinnovations.com, rafal@milecki.pl,
Arend Van Spriel <arend.vanspriel@broadcom.com>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
"Li, Yi" <yi1.li@linux.intel.com>,
atull@opensource.altera.com,
Moritz Fischer <moritz.fischer@ettus.com>,
Petr Mladek <pmladek@suse.com>,
Johannes Berg <johannes.berg@intel.com>,
Emmanuel Grumbach <emmanuel.grumbach@intel.com>,
Luca Coelho <luciano.coelho@intel.com>,
Kalle Valo <kvalo@codeaurora.org>
Subject: Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback
Date: Fri, 26 May 2017 06:09:29 -0500 [thread overview]
Message-ID: <87fufr3mdy.fsf@xmission.com> (raw)
In-Reply-To: <CANh8QzwPb_+RKs5QVt7mdFk8h_rOMVS3j9m0OADgvzBtNqBBLg@mail.gmail.com> (Martin Fuzzey's message of "Thu, 25 May 2017 10:28:38 +0200")
"Fuzzey, Martin" <mfuzzey@parkeon.com> writes:
> On 25 May 2017 at 06:13, Andy Lutomirski <luto@kernel.org> wrote:
>>>>
>>>> Can you give a simple example of what's going on and why it matters?
>>>>
>
>
> Here is the use case in which I ran into this problem.
>
> I have a driver which does request_firmware() when a write() is done
> to a sysfs file.
>
> The write() was being done by an android init script (with the init
> interpreter "write" command).
> init, of course, forks lots of processes and some of the children die.
>
> So the scenario was the following:
>
> 1) Android init calls write() on the sysfs file
> 2) The sysfs .store() callback registered by a driver is called
> 3) The driver calls request_firmware()
> 4) request_firmware() sends the firmware load request to userspace and
> calls wait_for_completion_interruptible()
> 5) A child dies and raises SIGCHLD
> 6) wait_for_completion_interruptible() returns -ERESTARTSYS due to the signal
> 7) request_firmware() [before this patch] translated that to -EAGAIN
> 8) The driver (in my case) ignored this [because the firmware was not
> critical - it was for checking if a microcontroler was up to date]
> (but it could have returned it to userspace, same problem)
>
> The point being that, due to a signal (SIGCHLD) which has nothing to
> do with the firmware loading process, the firmware load was not done.
> Also EAGAIN is the same error used if the load request times out so it
> was impossible to distinguish the two cases.
>
> ERESTARTSYS is an internal error and is not returned to userspace.
> Instead it is handled by the linux syscall machinery which, after
> processing the signal either restarts (transpently to userspace) the
> syscall or returns EINTR to userspace (depending if the signal handler
> users SA_RESTART - see man 7 signal)
>
>
> With this patch here is what happens:
>
> 1) Android init calls write() on the sysfs file
> 2) The sysfs .store() callback registered by a driver is called
> 3) The driver calls request_firmware()
> 4) request_firmware() sends the firmware load request to userspace and
> calls wait_for_completion_interruptible()
> 5) A child dies and raises SIGCHLD
> 6) wait_for_completion_interruptible() returns -ERESTARTSYS due to the signal
> 7) request_firmware() [with this patch] returns -ERESTARTSYS
> 8) The driver returns -ERSTARTSYS from its sysfs .store method
> 9) The system call machinery invokes the signal handler
> 10) The signal handler does its stuff
> 11) Because SA_RESTART was set the system call is restarted (calling
> the sysfs .store) and we try it all again from step 2
>
> Note that, on the the userspace side write() is only called once (the
> restart is transparent to userspace which is oblivious to all this)
> The kernel side write() (which calls .store() is called multiple times
> (so that code does need to know about this)
>
>
>>>> ERESTARTSYS and friends are highly magical, and I'm not convinced that
>>>> allowing _request_firmware_load to return -ERESTARTSYS is actually a
>>>> good idea. What if there are system calls that can't handle this
>>>> style of restart that start being restarted as a result?
>>>
>
> If the caller is unable to restart (for example if the driver's
> .store() callback had already done lots of stuff that couldn't be
> undone) it is free to translate -ERSTARTSYS to -EINTR before
> returning.
> But request_frimware() can't know about that.
>
>
>>>> 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?
It sounds like the code really is not prepared for an truly
interruptible wait here.
Eric
next prev parent reply other threads:[~2017-05-26 11:09 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20170524205658.GK8951@wotan.suse.de>
[not found] ` <20170524214027.7775-1-mcgrof@kernel.org>
[not found] ` <CALCETrXUrirO-vg3M+MGhn=0gZTwx0phsRDS4TCwWWgNYC6RsA@mail.gmail.com>
2017-05-24 22:38 ` [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback Luis R. Rodriguez
2017-05-25 4:13 ` Andy Lutomirski
[not found] ` <CALCETrU4__YUGk36PN=FbuEf0SBaTrxQQqm4sWs2NrZ+6WN7jA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-05-25 8:28 ` Fuzzey, Martin
2017-05-26 11:09 ` Eric W. Biederman [this message]
[not found] ` <87fufr3mdy.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2017-05-26 19:46 ` Luis R. Rodriguez
2017-05-26 21:26 ` Dmitry Torokhov
[not found] ` <CAKdAkRTrcTVOAP5GK-R=Au_tL5WqSn5UkQEzNe5NcCWXS8mbtA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-05-26 21:32 ` Luis R. Rodriguez
2017-05-26 21:55 ` Dmitry Torokhov
2017-06-05 20:24 ` Luis R. Rodriguez
[not found] ` <20170605202410.GQ8951-B4tOwbsTzaBolqkO4TVVkw@public.gmane.org>
2017-06-06 9:04 ` Martin Fuzzey
[not found] ` <59367025.3020901-mB3Nsq4MPf1BDgjK7y7TUQ@public.gmane.org>
2017-06-06 16:34 ` Luis R. Rodriguez
[not found] ` <20170606163401.GA27288-B4tOwbsTzaBolqkO4TVVkw@public.gmane.org>
2017-06-06 17:52 ` Luis R. Rodriguez
2017-06-06 14:53 ` Alan Cox
[not found] ` <1496760796.5682.48.camel-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2017-06-06 16:47 ` Luis R. Rodriguez
[not found] ` <20170606164734.GB27288-B4tOwbsTzaBolqkO4TVVkw@public.gmane.org>
2017-06-06 17:54 ` Luis R. Rodriguez
2017-06-06 22:11 ` Theodore Ts'o
[not found] ` <20170606221151.ygoxqkwhhjsqw632-AKGzg7BKzIDYtjvyW6yDsg@public.gmane.org>
2017-06-07 0:22 ` Luis R. Rodriguez
[not found] ` <20170607002237.GJ27288-B4tOwbsTzaBolqkO4TVVkw@public.gmane.org>
2017-06-07 4:56 ` Andy Lutomirski
2017-06-07 6:25 ` Dmitry Torokhov
2017-06-07 12:25 ` Alan Cox
2017-06-07 17:15 ` Luis R. Rodriguez
2017-06-09 1:14 ` Andy Lutomirski
[not found] ` <CALCETrXbHpkN9Pujj=U1VpAR9MTOyCAqCtL0=7-vb1EdpEwCMg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-06-09 1:33 ` Luis R. Rodriguez
[not found] ` <CAB=NE6USSj0sBzJSFOyyRQu=0rQXdbHc2+GNk1fse+Y8H6TrgQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-06-09 21:29 ` Luis R. Rodriguez
[not found] ` <CANh8QzwPb_+RKs5QVt7mdFk8h_rOMVS3j9m0OADgvzBtNqBBLg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-05-26 19:40 ` Luis R. Rodriguez
[not found] ` <20170526194001.GR8951-B4tOwbsTzaBolqkO4TVVkw@public.gmane.org>
2017-05-26 20:23 ` Fuzzey, Martin
[not found] ` <CANh8QzyqQ5hubWJvWYxgoQ3baL6sgoQPSzEHMY0tu8WNGS2gZA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-05-26 20:52 ` Luis R. Rodriguez
2017-06-07 17:08 ` Luis R. Rodriguez
2017-06-07 17:54 ` Martin Fuzzey
[not found] ` <59383DDA.3040702-mB3Nsq4MPf1BDgjK7y7TUQ@public.gmane.org>
2017-06-09 1:10 ` Luis R. Rodriguez
2017-06-09 1:57 ` Luis R. Rodriguez
[not found] ` <CAB=NE6UQZMmLvxTu7RcFHh3neAh+RFpTTFCSwJ8_EsmmtEq94Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-06-09 7:40 ` Martin Fuzzey
[not found] ` <593A50FF.40604-mB3Nsq4MPf1BDgjK7y7TUQ@public.gmane.org>
2017-06-09 21:12 ` Luis R. Rodriguez
2017-06-09 22:55 ` Luis R. Rodriguez
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87fufr3mdy.fsf@xmission.com \
--to=ebiederm@xmission.com \
--cc=arend.vanspriel@broadcom.com \
--cc=atull@opensource.altera.com \
--cc=dwmw2@infradead.org \
--cc=emmanuel.grumbach@intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=jewalt@lgsinnovations.com \
--cc=johannes.berg@intel.com \
--cc=kvalo@codeaurora.org \
--cc=linux-api@vger.kernel.org \
--cc=luciano.coelho@intel.com \
--cc=luto@kernel.org \
--cc=mcgrof@kernel.org \
--cc=mfuzzey@parkeon.com \
--cc=moritz.fischer@ettus.com \
--cc=mtk.manpages@gmail.com \
--cc=peterz@infradead.org \
--cc=pmladek@suse.com \
--cc=rafal@milecki.pl \
--cc=rjw@rjwysocki.net \
--cc=wagi@monom.org \
--cc=yi1.li@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).