Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751642AbdFIHky (ORCPT ); Fri, 9 Jun 2017 03:40:54 -0400 Received: from mail-wm0-f42.google.com ([74.125.82.42]:37101 "EHLO mail-wm0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751553AbdFIHkw (ORCPT ); Fri, 9 Jun 2017 03:40:52 -0400 Subject: Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback To: "Luis R. Rodriguez" References: <20170524205658.GK8951@wotan.suse.de> <20170524214027.7775-1-mcgrof@kernel.org> <20170607170858.GK27288@wotan.suse.de> <59383DDA.3040702@parkeon.com> Cc: Linux FS Devel , Alan Cox , "Ted Ts'o" , Andy Lutomirski , Dmitry Torokhov , "Michael Kerrisk (man-pages)" , Linux API , Peter Zijlstra , Greg KH , Daniel Wagner , David Woodhouse , jewalt@lgsinnovations.com, rafal@milecki.pl, Arend Van Spriel , "Rafael J. Wysocki" , "Li, Yi" , atull@opensource.altera.com, Moritz Fischer , Petr Mladek , Johannes Berg , Emmanuel Grumbach , Luca Coelho , Kalle Valo , Linus Torvalds , Kees Cook , AKASHI Takahiro , David Howells , Peter Jones , Hans de Goede , "linux-kernel@vger.kernel.org" From: Martin Fuzzey Message-ID: <593A50FF.40604@parkeon.com> Date: Fri, 9 Jun 2017 09:40:47 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2074 Lines: 61 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 (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) > Martin just to be clear, by "normal case termination" do you mean > completing successfully ?? Ie the firmware actually did make it onto > the device ? The firmware did *not* make it onto the device since the request_firmware() call returned an error (the code that would have transfered it to the device is only executed following a successful request_firmware) The process that terminates normally is unrelated to firmware loading as I said above. The only things that matter are: - It is a child process of the process that calls request_firmware() - It terminates *while* the the wait_ is still in progress Here is a way of reproducing the problem using the test_firmware module (which I only just saw) on normal linux with no Android or custom driver #!/bin/sh set -e # Make sure the system firmware loader doesn't get in the way /etc/init.d/udev stop modprobe test_firmware DIR=/sys/devices/virtual/misc/test_firmware echo 10 >/sys/class/firmware/timeout; sleep 2 & echo -n "/some/non/existing/file.bin" > "$DIR"/trigger_request; If run with the "sleep 2 &" it terminates after 2 seconds If the sleep is commented it runs for the expected 10 seconds (the firmware loading timeout) Since the sleep process is a child of the script process requesting a firmware load its death causes a SIGCHLD causing request_firmware() to abort prematurely. Martin