On Wed, Jun 7, 2017 at 10:54 AM, Martin Fuzzey <mfuzzey@xxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
