Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1689082 > unrolled thread

Re: [PATCH v3 4/4] firmware: send -EINTR on signal abort on fallback mechanism

Started byGreg KH <gregkh@linuxfoundation.org>
First post2017-07-17 16:10 +0200
Last post2017-07-18 02:30 +0200
Articles 4 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: [PATCH v3 4/4] firmware: send -EINTR on signal abort on fallback  mechanism Greg KH <gregkh@linuxfoundation.org> - 2017-07-17 16:10 +0200
    Re: [PATCH v3 4/4] firmware: send -EINTR on signal abort on fallback  mechanism "Luis R. Rodriguez" <mcgrof@kernel.org> - 2017-07-17 18:10 +0200
      Re: [PATCH v3 4/4] firmware: send -EINTR on signal abort on fallback  mechanism Greg KH <gregkh@linuxfoundation.org> - 2017-07-17 18:30 +0200
        Re: [PATCH v3 4/4] firmware: send -EINTR on signal abort on fallback  mechanism "Luis R. Rodriguez" <mcgrof@kernel.org> - 2017-07-18 02:30 +0200

#1689082 — Re: [PATCH v3 4/4] firmware: send -EINTR on signal abort on fallback mechanism

FromGreg KH <gregkh@linuxfoundation.org>
Date2017-07-17 16:10 +0200
SubjectRe: [PATCH v3 4/4] firmware: send -EINTR on signal abort on fallback mechanism
Message-ID<u4eSJ-65Z-15@gated-at.bofh.it>
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

[toc] | [next] | [standalone]


#1689201

From"Luis R. Rodriguez" <mcgrof@kernel.org>
Date2017-07-17 18:10 +0200
Message-ID<u4gKS-7hy-17@gated-at.bofh.it>
In reply to#1689082
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

[toc] | [prev] | [next] | [standalone]


#1689229

FromGreg KH <gregkh@linuxfoundation.org>
Date2017-07-17 18:30 +0200
Message-ID<u4h4e-7oe-11@gated-at.bofh.it>
In reply to#1689201
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

[toc] | [prev] | [next] | [standalone]


#1689577

From"Luis R. Rodriguez" <mcgrof@kernel.org>
Date2017-07-18 02:30 +0200
Message-ID<u4oyJ-3E1-3@gated-at.bofh.it>
In reply to#1689229
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

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web