From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: "Luis R. Rodriguez" <mcgrof@kernel.org>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
"Fuzzey, Martin" <mfuzzey@parkeon.com>,
Andy Lutomirski <luto@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>
Subject: Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback
Date: Fri, 26 May 2017 14:55:18 -0700 [thread overview]
Message-ID: <20170526215518.GB40877@dtor-ws> (raw)
In-Reply-To: <CAB=NE6Wh9inuA-R9-zegnvJV=s_6o_doMNDOhBVhYn4ZQ_Ku5Q@mail.gmail.com>
On Fri, May 26, 2017 at 02:32:31PM -0700, Luis R. Rodriguez wrote:
> On Fri, May 26, 2017 at 2:26 PM, Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
> > On Fri, May 26, 2017 at 12:46 PM, Luis R. Rodriguez <mcgrof@kernel.org> wrote:
> >> 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?
> >
> > 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 ?
I think it is, as you have users complaining about behavior. I do not
think we need to make their lives harder than needed by requiring
handling signals.
I do not see why we could not introduce wait_event_killable_timeout()
and swait_event_killable_timeout() into -stables.
Thanks.
--
Dmitry
WARNING: multiple messages have this Message-ID (diff)
From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: "Luis R. Rodriguez" <mcgrof@kernel.org>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
"Fuzzey, Martin" <mfuzzey@parkeon.com>,
Andy Lutomirski <luto@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>,
Linus Torvalds <torvalds@linux-foundation.org>,
Kees Cook <keescook@chromium.org>,
AKASHI Takahiro <takahiro.akashi@linaro.org>,
David Howells <dhowells@redhat.com>,
Peter Jones <pjones@redhat.com>,
Hans de G oede <hdegoede@redhat.com>,
Alan Cox <alan@linux.intel.com>, "Ted Ts'o" <tytso@mit.edu>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback
Date: Fri, 26 May 2017 14:55:18 -0700 [thread overview]
Message-ID: <20170526215518.GB40877@dtor-ws> (raw)
In-Reply-To: <CAB=NE6Wh9inuA-R9-zegnvJV=s_6o_doMNDOhBVhYn4ZQ_Ku5Q@mail.gmail.com>
On Fri, May 26, 2017 at 02:32:31PM -0700, Luis R. Rodriguez wrote:
> On Fri, May 26, 2017 at 2:26 PM, Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
> > On Fri, May 26, 2017 at 12:46 PM, Luis R. Rodriguez <mcgrof@kernel.org> wrote:
> >> 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?
> >
> > 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 ?
I think it is, as you have users complaining about behavior. I do not
think we need to make their lives harder than needed by requiring
handling signals.
I do not see why we could not introduce wait_event_killable_timeout()
and swait_event_killable_timeout() into -stables.
Thanks.
--
Dmitry
next prev parent reply other threads:[~2017-05-26 21:55 UTC|newest]
Thread overview: 75+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-23 13:16 [PATCH] firmware: request_firmware() should propagate -ERESTARTSYS Martin Fuzzey
2017-05-23 13:31 ` Greg Kroah-Hartman
2017-05-23 14:32 ` Martin Fuzzey
2017-05-23 19:55 ` Luis R. Rodriguez
2017-05-24 20:56 ` Luis R. Rodriguez
2017-05-24 21:40 ` [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback Luis R. Rodriguez
2017-05-24 22:00 ` Andy Lutomirski
2017-05-24 22:38 ` Luis R. Rodriguez
2017-05-24 22:38 ` Luis R. Rodriguez
2017-05-25 4:13 ` Andy Lutomirski
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-25 8:28 ` Fuzzey, Martin
2017-05-26 11:09 ` Eric W. Biederman
2017-05-26 11:09 ` Eric W. Biederman
[not found] ` <87fufr3mdy.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2017-05-26 19:46 ` Luis R. Rodriguez
2017-05-26 19:46 ` Luis R. Rodriguez
2017-05-26 21:26 ` Dmitry Torokhov
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:32 ` Luis R. Rodriguez
2017-05-26 21:55 ` Dmitry Torokhov [this message]
2017-05-26 21:55 ` Dmitry Torokhov
2017-06-05 20:24 ` Luis R. Rodriguez
2017-06-05 20:24 ` Luis R. Rodriguez
[not found] ` <20170605202410.GQ8951-B4tOwbsTzaBolqkO4TVVkw@public.gmane.org>
2017-06-06 9:04 ` Martin Fuzzey
2017-06-06 9:04 ` Martin Fuzzey
[not found] ` <59367025.3020901-mB3Nsq4MPf1BDgjK7y7TUQ@public.gmane.org>
2017-06-06 16:34 ` Luis R. Rodriguez
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 17:52 ` Luis R. Rodriguez
2017-06-06 14:53 ` Alan Cox
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
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 17:54 ` Luis R. Rodriguez
2017-06-06 22:11 ` Theodore Ts'o
2017-06-06 22:11 ` Theodore Ts'o
[not found] ` <20170606221151.ygoxqkwhhjsqw632-AKGzg7BKzIDYtjvyW6yDsg@public.gmane.org>
2017-06-07 0:22 ` Luis R. Rodriguez
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 4:56 ` Andy Lutomirski
2017-06-07 6:25 ` Dmitry Torokhov
2017-06-07 6:25 ` Dmitry Torokhov
2017-06-07 12:25 ` Alan Cox
2017-06-07 12:25 ` Alan Cox
2017-06-07 17:15 ` Luis R. Rodriguez
2017-06-07 17:15 ` Luis R. Rodriguez
2017-06-09 1:14 ` Andy Lutomirski
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
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
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
2017-05-26 19:40 ` Luis R. Rodriguez
[not found] ` <20170526194001.GR8951-B4tOwbsTzaBolqkO4TVVkw@public.gmane.org>
2017-05-26 20:23 ` Fuzzey, Martin
2017-05-26 20:23 ` Fuzzey, Martin
[not found] ` <CANh8QzyqQ5hubWJvWYxgoQ3baL6sgoQPSzEHMY0tu8WNGS2gZA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-05-26 20:52 ` Luis R. Rodriguez
2017-05-26 20:52 ` Luis R. Rodriguez
2017-06-07 17:08 ` Luis R. Rodriguez
2017-06-07 17:08 ` Luis R. Rodriguez
2017-06-07 17:54 ` Martin Fuzzey
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:10 ` Luis R. Rodriguez
2017-06-09 1:57 ` 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
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 21:12 ` Luis R. Rodriguez
2017-06-09 22:55 ` 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=20170526215518.GB40877@dtor-ws \
--to=dmitry.torokhov@gmail.com \
--cc=arend.vanspriel@broadcom.com \
--cc=atull@opensource.altera.com \
--cc=dwmw2@infradead.org \
--cc=ebiederm@xmission.com \
--cc=emmanuel.grumbach@intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=jewalt@lgsinnovations.com \
--cc=johannes.berg@intel.com \
--cc=linux-api@vger.kernel.org \
--cc=luciano.coelho@intel \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.