| Message ID | 20170629205151.5329-5-mcgrof@kernel.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Thu, Jun 29, 2017 at 01:51:51PM -0700, Luis R. Rodriguez wrote: > Right now we send -EAGAIN to a syfs write which got interrupted. > Userspace can't tell what happened though, send -EINTR if we > were killed due to a signal so userspace can tell things apart. > > This is only applicable to the fallback mechanism. > > Reported-by: Martin Fuzzey <mfuzzey@parkeon.com> > Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org> > --- > drivers/base/firmware_class.c | 9 ++++++--- > 1 file changed, 6 insertions(+), 3 deletions(-) This doesn't need to go into 4.13-final, right? Can it wait for 4.14-rc1? thanks, greg k-h
On Mon, Jul 17, 2017 at 04:00:07PM +0200, Greg KH wrote: > On Thu, Jun 29, 2017 at 01:51:51PM -0700, Luis R. Rodriguez wrote: > > Right now we send -EAGAIN to a syfs write which got interrupted. > > Userspace can't tell what happened though, send -EINTR if we > > were killed due to a signal so userspace can tell things apart. > > > > This is only applicable to the fallback mechanism. > > > > Reported-by: Martin Fuzzey <mfuzzey@parkeon.com> > > Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org> > > --- > > drivers/base/firmware_class.c | 9 ++++++--- > > 1 file changed, 6 insertions(+), 3 deletions(-) > > This doesn't need to go into 4.13-final, right? Nope. > Can it wait for 4.14-rc1? Yes. The bigger issue was the unexpected signals causing interruption. This I consider a secondary and not critical issue so I did not Cc stable. Luis
On Mon, Jul 17, 2017 at 06:04:33PM +0200, Luis R. Rodriguez wrote: > On Mon, Jul 17, 2017 at 04:00:07PM +0200, Greg KH wrote: > > On Thu, Jun 29, 2017 at 01:51:51PM -0700, Luis R. Rodriguez wrote: > > > Right now we send -EAGAIN to a syfs write which got interrupted. > > > Userspace can't tell what happened though, send -EINTR if we > > > were killed due to a signal so userspace can tell things apart. > > > > > > This is only applicable to the fallback mechanism. > > > > > > Reported-by: Martin Fuzzey <mfuzzey@parkeon.com> > > > Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org> > > > --- > > > drivers/base/firmware_class.c | 9 ++++++--- > > > 1 file changed, 6 insertions(+), 3 deletions(-) > > > > This doesn't need to go into 4.13-final, right? > > Nope. > > > Can it wait for 4.14-rc1? > > Yes. The bigger issue was the unexpected signals causing interruption. > This I consider a secondary and not critical issue so I did not Cc stable. Ok, can you then take your two series of patches, and split them up into one for 4.13-final and one for 4.14-rc1 so that I know for sure which is which? As it is, I have to guess :( thanks, greg k-h
On Mon, Jul 17, 2017 at 06:20:37PM +0200, Greg KH wrote: > On Mon, Jul 17, 2017 at 06:04:33PM +0200, Luis R. Rodriguez wrote: > > On Mon, Jul 17, 2017 at 04:00:07PM +0200, Greg KH wrote: > > > On Thu, Jun 29, 2017 at 01:51:51PM -0700, Luis R. Rodriguez wrote: > > > > Right now we send -EAGAIN to a syfs write which got interrupted. > > > > Userspace can't tell what happened though, send -EINTR if we > > > > were killed due to a signal so userspace can tell things apart. > > > > > > > > This is only applicable to the fallback mechanism. > > > > > > > > Reported-by: Martin Fuzzey <mfuzzey@parkeon.com> > > > > Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org> > > > > --- > > > > drivers/base/firmware_class.c | 9 ++++++--- > > > > 1 file changed, 6 insertions(+), 3 deletions(-) > > > > > > This doesn't need to go into 4.13-final, right? > > > > Nope. > > > > > Can it wait for 4.14-rc1? > > > > Yes. The bigger issue was the unexpected signals causing interruption. > > This I consider a secondary and not critical issue so I did not Cc stable. > > Ok, can you then take your two series of patches, and split them up into > one for 4.13-final and one for 4.14-rc1 so that I know for sure which is > which? > > As it is, I have to guess :( Sure thing. Luis
diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c index cff33fb609e7..d3d071dbd2a5 100644 --- a/drivers/base/firmware_class.c +++ b/drivers/base/firmware_class.c @@ -1086,9 +1086,12 @@ static int _request_firmware_load(struct firmware_priv *fw_priv, mutex_unlock(&fw_lock); } - if (fw_state_is_aborted(&buf->fw_st)) - retval = -EAGAIN; - else if (buf->is_paged_buf && !buf->data) + if (fw_state_is_aborted(&buf->fw_st)) { + if (retval == -ERESTARTSYS) + retval = -EINTR; + else + retval = -EAGAIN; + } else if (buf->is_paged_buf && !buf->data) retval = -ENOMEM; device_del(f_dev);
Right now we send -EAGAIN to a syfs write which got interrupted. Userspace can't tell what happened though, send -EINTR if we were killed due to a signal so userspace can tell things apart. This is only applicable to the fallback mechanism. Reported-by: Martin Fuzzey <mfuzzey@parkeon.com> Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org> --- drivers/base/firmware_class.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-)