Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback

On Fri, Jun 09, 2017 at 09:40:47AM +0200, Martin Fuzzey wrote: > On 09/06/17 03:57, Luis R. Rodriguez wrote: > > On Thu, Jun 8, 2017 at 6:10 PM, Luis R. Rodriguez wrote: > > > > Android didn't send the signal, the kernel did (SIGCHLD). > > > > > > > > Like this: > > > > > > >

Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback

On Fri, Jun 09, 2017 at 09:40:47AM +0200, Martin Fuzzey wrote: > On 09/06/17 03:57, Luis R. Rodriguez wrote: > > On Thu, Jun 8, 2017 at 6:10 PM, Luis R. Rodriguez wrote: > > > > Android didn't send the signal, the kernel did (SIGCHLD). > > > > > > > > Like this: > > > > > > > > 1) Android init

Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback

On Thu, Jun 8, 2017 at 6:33 PM, Luis R. Rodriguez wrote: > On Thu, Jun 8, 2017 at 6:14 PM, Andy Lutomirski wrote: >> That's what I meant, but I said it unclearly. I meant that, if we're >> going to start allowing interruption, we would need to audit all the

Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback

On Thu, Jun 8, 2017 at 6:33 PM, Luis R. Rodriguez wrote: > On Thu, Jun 8, 2017 at 6:14 PM, Andy Lutomirski wrote: >> That's what I meant, but I said it unclearly. I meant that, if we're >> going to start allowing interruption, we would need to audit all the >> callers. Ugh. > > There are

Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback

On Fri, Jun 09, 2017 at 09:40:47AM +0200, Martin Fuzzey wrote: > On 09/06/17 03:57, Luis R. Rodriguez wrote: > > On Thu, Jun 8, 2017 at 6:10 PM, Luis R. Rodriguez wrote: > > > > Android didn't send the signal, the kernel did (SIGCHLD). > > > > > > > > Like this: > > > > > > >

Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback

On Fri, Jun 09, 2017 at 09:40:47AM +0200, Martin Fuzzey wrote: > On 09/06/17 03:57, Luis R. Rodriguez wrote: > > On Thu, Jun 8, 2017 at 6:10 PM, Luis R. Rodriguez wrote: > > > > Android didn't send the signal, the kernel did (SIGCHLD). > > > > > > > > Like this: > > > > > > > > 1) Android init

Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback

On 09/06/17 03:57, Luis R. Rodriguez wrote: On Thu, Jun 8, 2017 at 6:10 PM, Luis R. Rodriguez wrote: Android didn't send the signal, the kernel did (SIGCHLD). Like this: 1) Android init (pid=1) fork()s (say pid=42) [this child process is totally unrelated to firmware

Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback

On 09/06/17 03:57, Luis R. Rodriguez wrote: On Thu, Jun 8, 2017 at 6:10 PM, Luis R. Rodriguez wrote: Android didn't send the signal, the kernel did (SIGCHLD). Like this: 1) Android init (pid=1) fork()s (say pid=42) [this child process is totally unrelated to firmware loading] 2) Android init

Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback

On Thu, Jun 8, 2017 at 6:10 PM, Luis R. Rodriguez wrote: > On Wed, Jun 7, 2017 at 10:54 AM, Martin Fuzzey wrote: >> On 07/06/17 19:08, Luis R. Rodriguez wrote: >>> >>> On Thu, May 25, 2017 at 10:28:38AM +0200, Fuzzey, Martin wrote: 1) Android

Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback

On Thu, Jun 8, 2017 at 6:10 PM, Luis R. Rodriguez wrote: > On Wed, Jun 7, 2017 at 10:54 AM, Martin Fuzzey wrote: >> On 07/06/17 19:08, Luis R. Rodriguez wrote: >>> >>> On Thu, May 25, 2017 at 10:28:38AM +0200, Fuzzey, Martin wrote: 1) Android init calls write() on the sysfs file

Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback

On Thu, Jun 8, 2017 at 6:14 PM, Andy Lutomirski wrote: > On Tue, Jun 6, 2017 at 11:25 PM, Dmitry Torokhov > wrote: >> On Tue, Jun 06, 2017 at 09:56:47PM -0700, Andy Lutomirski wrote: >>> On Tue, Jun 6, 2017 at 5:22 PM, Luis R. Rodriguez

Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback

On Thu, Jun 8, 2017 at 6:14 PM, Andy Lutomirski wrote: > On Tue, Jun 6, 2017 at 11:25 PM, Dmitry Torokhov > wrote: >> On Tue, Jun 06, 2017 at 09:56:47PM -0700, Andy Lutomirski wrote: >>> On Tue, Jun 6, 2017 at 5:22 PM, Luis R. Rodriguez wrote: >>> > On Tue, Jun 06, 2017 at 06:11:51PM -0400,

Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback

On Tue, Jun 6, 2017 at 11:25 PM, Dmitry Torokhov wrote: > On Tue, Jun 06, 2017 at 09:56:47PM -0700, Andy Lutomirski wrote: >> On Tue, Jun 6, 2017 at 5:22 PM, Luis R. Rodriguez wrote: >> > On Tue, Jun 06, 2017 at 06:11:51PM -0400, Theodore Ts'o wrote:

Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback

On Tue, Jun 6, 2017 at 11:25 PM, Dmitry Torokhov wrote: > On Tue, Jun 06, 2017 at 09:56:47PM -0700, Andy Lutomirski wrote: >> On Tue, Jun 6, 2017 at 5:22 PM, Luis R. Rodriguez wrote: >> > On Tue, Jun 06, 2017 at 06:11:51PM -0400, Theodore Ts'o wrote: >> >> On Tue, Jun 06, 2017 at 06:47:34PM

Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback

On Wed, Jun 7, 2017 at 10:54 AM, Martin Fuzzey wrote: > On 07/06/17 19:08, Luis R. Rodriguez wrote: >> >> On Thu, May 25, 2017 at 10:28:38AM +0200, Fuzzey, Martin wrote: >>> >>> 1) Android init calls write() on the sysfs file >>> 2) The sysfs .store() callback registered by a

Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback

On Wed, Jun 7, 2017 at 10:54 AM, Martin Fuzzey wrote: > On 07/06/17 19:08, Luis R. Rodriguez wrote: >> >> On Thu, May 25, 2017 at 10:28:38AM +0200, Fuzzey, Martin wrote: >>> >>> 1) Android init calls write() on the sysfs file >>> 2) The sysfs .store() callback registered by a driver is called >>>

Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback

On 07/06/17 19:08, Luis R. Rodriguez wrote: On Thu, May 25, 2017 at 10:28:38AM +0200, Fuzzey, Martin wrote: 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

Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback

On 07/06/17 19:08, Luis R. Rodriguez wrote: On Thu, May 25, 2017 at 10:28:38AM +0200, Fuzzey, Martin wrote: 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

Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback

On Wed, Jun 07, 2017 at 01:25:51PM +0100, Alan Cox wrote: > > What's wrong with saying that the only way to interrupt firmware > > loading is to kill the process? So ctrl-c will no longer interrupt > > it, but I do not think that ease of aborting firmware update is > > primary goal here. I

Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback

On Wed, Jun 07, 2017 at 01:25:51PM +0100, Alan Cox wrote: > > What's wrong with saying that the only way to interrupt firmware > > loading is to kill the process? So ctrl-c will no longer interrupt > > it, but I do not think that ease of aborting firmware update is > > primary goal here. I

Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback

On Thu, May 25, 2017 at 10:28:38AM +0200, Fuzzey, Martin wrote: > 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 >

Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback

On Thu, May 25, 2017 at 10:28:38AM +0200, Fuzzey, Martin wrote: > 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 >

Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback

> What's wrong with saying that the only way to interrupt firmware > loading is to kill the process? So ctrl-c will no longer interrupt > it, but I do not think that ease of aborting firmware update is > primary goal here. I consider simple is good here. Agreed 100%. The user process did not ask

Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback

> What's wrong with saying that the only way to interrupt firmware > loading is to kill the process? So ctrl-c will no longer interrupt > it, but I do not think that ease of aborting firmware update is > primary goal here. I consider simple is good here. Agreed 100%. The user process did not ask

Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback

On Tue, Jun 06, 2017 at 09:56:47PM -0700, Andy Lutomirski wrote: > On Tue, Jun 6, 2017 at 5:22 PM, Luis R. Rodriguez wrote: > > On Tue, Jun 06, 2017 at 06:11:51PM -0400, Theodore Ts'o wrote: > >> On Tue, Jun 06, 2017 at 06:47:34PM +0200, Luis R. Rodriguez wrote: > >> > On Tue,

Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback

On Tue, Jun 06, 2017 at 09:56:47PM -0700, Andy Lutomirski wrote: > On Tue, Jun 6, 2017 at 5:22 PM, Luis R. Rodriguez wrote: > > On Tue, Jun 06, 2017 at 06:11:51PM -0400, Theodore Ts'o wrote: > >> On Tue, Jun 06, 2017 at 06:47:34PM +0200, Luis R. Rodriguez wrote: > >> > On Tue, Jun 06, 2017 at

Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback

On Tue, Jun 6, 2017 at 5:22 PM, Luis R. Rodriguez wrote: > On Tue, Jun 06, 2017 at 06:11:51PM -0400, Theodore Ts'o wrote: >> On Tue, Jun 06, 2017 at 06:47:34PM +0200, Luis R. Rodriguez wrote: >> > On Tue, Jun 06, 2017 at 03:53:16PM +0100, Alan Cox wrote: > > We rely on swait,

Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback

On Tue, Jun 6, 2017 at 5:22 PM, Luis R. Rodriguez wrote: > On Tue, Jun 06, 2017 at 06:11:51PM -0400, Theodore Ts'o wrote: >> On Tue, Jun 06, 2017 at 06:47:34PM +0200, Luis R. Rodriguez wrote: >> > On Tue, Jun 06, 2017 at 03:53:16PM +0100, Alan Cox wrote: > > We rely on swait, and swait right now

Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback

On Tue, Jun 06, 2017 at 06:11:51PM -0400, Theodore Ts'o wrote: > On Tue, Jun 06, 2017 at 06:47:34PM +0200, Luis R. Rodriguez wrote: > > On Tue, Jun 06, 2017 at 03:53:16PM +0100, Alan Cox wrote: > > > Yep everyone codes > > > > > > write(disk_file, "foo", 3); > > > > > > not while(..) blah

Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback

On Tue, Jun 06, 2017 at 06:11:51PM -0400, Theodore Ts'o wrote: > On Tue, Jun 06, 2017 at 06:47:34PM +0200, Luis R. Rodriguez wrote: > > On Tue, Jun 06, 2017 at 03:53:16PM +0100, Alan Cox wrote: > > > Yep everyone codes > > > > > > write(disk_file, "foo", 3); > > > > > > not while(..) blah

Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback

On Tue, Jun 06, 2017 at 06:47:34PM +0200, Luis R. Rodriguez wrote: > On Tue, Jun 06, 2017 at 03:53:16PM +0100, Alan Cox wrote: > > Yep everyone codes > > > > write(disk_file, "foo", 3); > > > > not while(..) blah around it. In general I/O to tty devices and other character mode devices was

Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback

On Tue, Jun 06, 2017 at 06:47:34PM +0200, Luis R. Rodriguez wrote: > On Tue, Jun 06, 2017 at 03:53:16PM +0100, Alan Cox wrote: > > Yep everyone codes > > > > write(disk_file, "foo", 3); > > > > not while(..) blah around it. In general I/O to tty devices and other character mode devices was

Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback

Using the right linux-fsdevel this time also, this was the second reply. Luis On Tue, Jun 06, 2017 at 06:47:34PM +0200, Luis R. Rodriguez wrote: > Adding fsdevel folks. > > On Tue, Jun 06, 2017 at 03:53:16PM +0100, Alan Cox wrote: > > > "Unix tradition (and thus almost all applications)

Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback

Using the right linux-fsdevel this time also, this was the second reply. Luis On Tue, Jun 06, 2017 at 06:47:34PM +0200, Luis R. Rodriguez wrote: > Adding fsdevel folks. > > On Tue, Jun 06, 2017 at 03:53:16PM +0100, Alan Cox wrote: > > > "Unix tradition (and thus almost all applications)

Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback

Used wrong alias for fsdevel now, its linux-fsdevel ... Luis On Tue, Jun 06, 2017 at 06:34:01PM +0200, Luis R. Rodriguez wrote: > Adding fsdevel for review on the correct semantics of handling signals on > write(), in this case a sysfs write which triggered a sync request firmware > call and

Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback

Used wrong alias for fsdevel now, its linux-fsdevel ... Luis On Tue, Jun 06, 2017 at 06:34:01PM +0200, Luis R. Rodriguez wrote: > Adding fsdevel for review on the correct semantics of handling signals on > write(), in this case a sysfs write which triggered a sync request firmware > call and

Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback

Adding fsdevel folks. On Tue, Jun 06, 2017 at 03:53:16PM +0100, Alan Cox wrote: > > "Unix tradition (and thus almost all applications) believe file store > > writes to > > be non signal interruptible. It would not be safe or practical to > > change that > > guarantee." > > Yep everyone codes >

Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback

Adding fsdevel folks. On Tue, Jun 06, 2017 at 03:53:16PM +0100, Alan Cox wrote: > > "Unix tradition (and thus almost all applications) believe file store > > writes to > > be non signal interruptible. It would not be safe or practical to > > change that > > guarantee." > > Yep everyone codes >

Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback

Adding fsdevel for review on the correct semantics of handling signals on write(), in this case a sysfs write which triggered a sync request firmware call and what the firmware API should return in such case of a signal (I gather this should be -EINTR and not -ERESTARTSYS). Also whether or not

Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback

Adding fsdevel for review on the correct semantics of handling signals on write(), in this case a sysfs write which triggered a sync request firmware call and what the firmware API should return in such case of a signal (I gather this should be -EINTR and not -ERESTARTSYS). Also whether or not

Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback

> "Unix tradition (and thus almost all applications) believe file store > writes to > be non signal interruptible. It would not be safe or practical to > change that > guarantee." Yep everyone codes write(disk_file, "foo", 3); not while(..) blah around it. > For these two reasons then

Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback

> "Unix tradition (and thus almost all applications) believe file store > writes to > be non signal interruptible. It would not be safe or practical to > change that > guarantee." Yep everyone codes write(disk_file, "foo", 3); not while(..) blah around it. > For these two reasons then

Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback

On 05/06/17 22:24, Luis R. Rodriguez wrote: For these two reasons then it would seem best we do two things actually: 1) return -EINTR instead of -EAGAIN when we detect swait_event_interruptible_timeout() got interrupted by a signal (it returns -ERESTARTSYS) I disagree. That would force

Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback

On 05/06/17 22:24, Luis R. Rodriguez wrote: For these two reasons then it would seem best we do two things actually: 1) return -EINTR instead of -EAGAIN when we detect swait_event_interruptible_timeout() got interrupted by a signal (it returns -ERESTARTSYS) I disagree. That would force

Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback

On Fri, May 26, 2017 at 02:55:18PM -0700, Dmitry Torokhov wrote: > 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 > > wrote: > > > On Fri, May 26, 2017 at 12:46 PM, Luis R. Rodriguez

Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback

On Fri, May 26, 2017 at 02:55:18PM -0700, Dmitry Torokhov wrote: > 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 > > wrote: > > > On Fri, May 26, 2017 at 12:46 PM, Luis R. Rodriguez > > > wrote: > > >> On Fri, May 26,

Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback

On 26 May 2017 at 21:40, Luis R. Rodriguez wrote: > On Thu, May 25, 2017 at 10:28:38AM +0200, Fuzzey, Martin wrote: >> On 25 May 2017 at 06:13, Andy Lutomirski wrote: >> >>> >> >>> Can you give a simple example of what's going on and why it matters? >> >>> >>

Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback

On 26 May 2017 at 21:40, Luis R. Rodriguez wrote: > On Thu, May 25, 2017 at 10:28:38AM +0200, Fuzzey, Martin wrote: >> On 25 May 2017 at 06:13, Andy Lutomirski wrote: >> >>> >> >>> Can you give a simple example of what's going on and why it matters? >> >>> >> >> >> Here is the use case in which

Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback

On Fri, May 26, 2017 at 10:23:03PM +0200, Fuzzey, Martin wrote: > On 26 May 2017 at 21:40, Luis R. Rodriguez wrote: > > > > No no, this is not how the fallback system works. > > The sysfs file I was talking about is *not* the sysfs file involved in > the firmware loading

Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback

On Fri, May 26, 2017 at 10:23:03PM +0200, Fuzzey, Martin wrote: > On 26 May 2017 at 21:40, Luis R. Rodriguez wrote: > > > > No no, this is not how the fallback system works. > > The sysfs file I was talking about is *not* the sysfs file involved in > the firmware loading mechanism > but a

Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback

On Fri, May 26, 2017 at 12:46 PM, Luis R. Rodriguez wrote: > On Fri, May 26, 2017 at 06:09:29AM -0500, Eric W. Biederman wrote: >> "Fuzzey, Martin" writes: >> Maybe SIGCHLD shouldn't interrupt firmware loading? >> > >> > I don't think there's a way of

Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback

On Fri, May 26, 2017 at 12:46 PM, Luis R. Rodriguez wrote: > On Fri, May 26, 2017 at 06:09:29AM -0500, Eric W. Biederman wrote: >> "Fuzzey, Martin" writes: >> Maybe SIGCHLD shouldn't interrupt firmware loading? >> > >> > I don't think there's a way of doing that without disabling all >> >

Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback

On Fri, May 26, 2017 at 2:26 PM, Dmitry Torokhov wrote: > On Fri, May 26, 2017 at 12:46 PM, Luis R. Rodriguez wrote: >> On Fri, May 26, 2017 at 06:09:29AM -0500, Eric W. Biederman wrote: >>> "Fuzzey, Martin" writes: >>>

Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback

On Fri, May 26, 2017 at 2:26 PM, Dmitry Torokhov wrote: > On Fri, May 26, 2017 at 12:46 PM, Luis R. Rodriguez wrote: >> On Fri, May 26, 2017 at 06:09:29AM -0500, Eric W. Biederman wrote: >>> "Fuzzey, Martin" writes: >>> Maybe SIGCHLD shouldn't interrupt firmware loading? >>> > >>> > I

Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback

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 > wrote: > > On Fri, May 26, 2017 at 12:46 PM, Luis R. Rodriguez > > wrote: > >> On Fri, May 26, 2017 at 06:09:29AM -0500, Eric W.

Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback

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 > wrote: > > On Fri, May 26, 2017 at 12:46 PM, Luis R. Rodriguez > > wrote: > >> On Fri, May 26, 2017 at 06:09:29AM -0500, Eric W. Biederman wrote: > >>> "Fuzzey, Martin"

Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback

On Fri, May 26, 2017 at 06:09:29AM -0500, Eric W. Biederman wrote: > "Fuzzey, Martin" 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

Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback

On Fri, May 26, 2017 at 06:09:29AM -0500, Eric W. Biederman wrote: > "Fuzzey, Martin" 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

Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback

On Thu, May 25, 2017 at 10:28:38AM +0200, Fuzzey, Martin wrote: > On 25 May 2017 at 06:13, Andy Lutomirski 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

Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback

On Thu, May 25, 2017 at 10:28:38AM +0200, Fuzzey, Martin wrote: > On 25 May 2017 at 06:13, Andy Lutomirski 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

Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback

"Fuzzey, Martin" writes: > On 25 May 2017 at 06:13, Andy Lutomirski 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

Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback

"Fuzzey, Martin" writes: > On 25 May 2017 at 06:13, Andy Lutomirski 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 >

Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback

On 25 May 2017 at 06:13, Andy Lutomirski 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

Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback

On 25 May 2017 at 06:13, Andy Lutomirski 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

Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback

On Wed, May 24, 2017 at 3:38 PM, Luis R. Rodriguez wrote: > On Wed, May 24, 2017 at 3:00 PM, Andy Lutomirski wrote: >> On Wed, May 24, 2017 at 2:40 PM, Luis R. Rodriguez wrote: >>> From: Martin Fuzzey >>> >>> Commit

Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback

On Wed, May 24, 2017 at 3:38 PM, Luis R. Rodriguez wrote: > On Wed, May 24, 2017 at 3:00 PM, Andy Lutomirski wrote: >> On Wed, May 24, 2017 at 2:40 PM, Luis R. Rodriguez wrote: >>> From: Martin Fuzzey >>> >>> Commit 0cb64249ca500 ("firmware_loader: abort request if wait_for_completion >>> is

Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback

On Wed, May 24, 2017 at 3:00 PM, Andy Lutomirski wrote: > On Wed, May 24, 2017 at 2:40 PM, Luis R. Rodriguez wrote: >> From: Martin Fuzzey >> >> Commit 0cb64249ca500 ("firmware_loader: abort request if wait_for_completion >> is

Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback

On Wed, May 24, 2017 at 3:00 PM, Andy Lutomirski wrote: > On Wed, May 24, 2017 at 2:40 PM, Luis R. Rodriguez wrote: >> From: Martin Fuzzey >> >> Commit 0cb64249ca500 ("firmware_loader: abort request if wait_for_completion >> is interrupted") added via 4.0 added support to abort the fallback

Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback

On Wed, May 24, 2017 at 2:40 PM, Luis R. Rodriguez wrote: > From: Martin Fuzzey > > Commit 0cb64249ca500 ("firmware_loader: abort request if wait_for_completion > is interrupted") added via 4.0 added support to abort the fallback mechanism > when a signal

Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback

On Wed, May 24, 2017 at 2:40 PM, Luis R. Rodriguez wrote: > From: Martin Fuzzey > > Commit 0cb64249ca500 ("firmware_loader: abort request if wait_for_completion > is interrupted") added via 4.0 added support to abort the fallback mechanism > when a signal was detected and

[PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback

From: Martin Fuzzey Commit 0cb64249ca500 ("firmware_loader: abort request if wait_for_completion is interrupted") added via 4.0 added support to abort the fallback mechanism when a signal was detected and wait_for_completion_interruptible() returned -ERESTARTSYS. Although

[PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback

From: Martin Fuzzey Commit 0cb64249ca500 ("firmware_loader: abort request if wait_for_completion is interrupted") added via 4.0 added support to abort the fallback mechanism when a signal was detected and wait_for_completion_interruptible() returned -ERESTARTSYS. Although the abort was effective