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


Groups > linux.kernel > #1661851

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

From "Luis R. Rodriguez" <mcgrof@kernel.org>
Newsgroups linux.kernel
Subject Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback
Date 2017-06-09 03:20 +0200
Message-ID <tQgKJ-3le-11@gated-at.bofh.it> (permalink)
References (3 earlier) <tKN6F-8dQ-1@gated-at.bofh.it> <tKSpH-3gE-1@gated-at.bofh.it> <tKWjF-5Mt-27@gated-at.bofh.it> <tPMD1-11z-33@gated-at.bofh.it> <tPNpo-1jw-13@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Wed, Jun 7, 2017 at 10:54 AM, Martin Fuzzey <mfuzzey@parkeon.com> 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
>>> 3) The driver calls request_firmware()
>>> 4) request_firmware() sends the firmware load request to userspace and
>>> calls wait_for_completion_interruptible()
>>
>> Martin, just for completeness on documenting on the commit log of the next
>> swait proposed fix for this -- what signal did the process get from which
>> you
>> note the child dies below ? Exactly what in Android sent this signal ?
>
>
> 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 (pid=1) does a write() on a (driver custom) sysfs file which
> ends up calling request_firmware() kernel side
> 3) The firmware loading fallback mechanism is used, the request is sent to
> userspace and pid 1 waits in the kernel on wait_*
> 4) before firmware loading completes pid 42 dies (for any reason - in my
> case normal termination)

Interesting, could one interpretation here be that the process
successfully finishing + the signal being sent beats out the timing of
the firmware_class syfs code detecting that the write completed ?

> 5) Kernel delivers SIGCHLD to pid=1 to tell it a child has died, which
> causes -ERESTARTSYS to be returned from wait_*

  Luis

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on  fallback "Luis R. Rodriguez" <mcgrof@kernel.org> - 2017-06-07 19:10 +0200
  Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on  fallback Martin Fuzzey <mfuzzey@parkeon.com> - 2017-06-07 20:00 +0200
    Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback "Luis R. Rodriguez" <mcgrof@kernel.org> - 2017-06-09 03:20 +0200
      Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback "Luis R. Rodriguez" <mcgrof@kernel.org> - 2017-06-09 04:00 +0200
        Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on  fallback Martin Fuzzey <mfuzzey@parkeon.com> - 2017-06-09 09:50 +0200
          Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on  fallback "Luis R. Rodriguez" <mcgrof@kernel.org> - 2017-06-09 23:20 +0200
          Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on  fallback "Luis R. Rodriguez" <mcgrof@kernel.org> - 2017-06-10 01:00 +0200

csiph-web