[PATCH v3 0/4] firmware: few pending fixes

[PATCH v3 0/4] firmware: few pending fixes

[Luis R. Rodriguez]

Greg,

this v3 series brings together two pending set of of lingering fixes I had
queued up for the firmware API [0] [1] into one series to maker it clear
in what order things should be applied. In this v3 series we just jump
ship away from swait and revert back to the good 'ol wait/completion as
you have suggested.

These changes are available on my branch 20170629-fw-fixes-wait-v3 based on
linux-next tag next-20170629 [2]. I've also tested applying them on Linus'
tree and they apply cleanly there. I've gone ahead and re-tested this series
with all the firmware selftests at tools/testing/selftests/firmware/ and things
are peachy.

If there are any questions please let me know.

[0] https://lkml.kernel.org/r/20170614222017.14653-1-mcgrof@kernel.org
[1] https://lkml.kernel.org/r/20170626212312.31958-1-mcgrof@kernel.org
[2] https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux-next.git/log/?h=20170629-fw-fixes-wait-v3

Luis R. Rodriguez (4):
  firmware: fix batched requests - wake all waiters
  test_firmware: add test case for SIGCHLD on sync fallback
  firmware: avoid invalid fallback aborts by using killable wait
  firmware: send -EINTR on signal abort on fallback mechanism

 drivers/base/firmware_class.c                   | 20 ++++++++--------
 tools/testing/selftests/firmware/fw_fallback.sh | 31 +++++++++++++++++++++++++
 2 files changed, 41 insertions(+), 10 deletions(-)

-- 
2.11.0

[PATCH v3 1/4] firmware: fix batched requests - wake all waiters

[Luis R. Rodriguez]

The firmware cache mechanism serves two purposes, the secondary purpose is
not well documented nor understood. This fixes a regression with the secondary
purpose of the firmware cache mechanism: batched requests.

The firmware cache is used for:

1) Addressing races with file lookups during the suspend/resume cycle
   by keeping firmware in memory during the suspend/resume cycle

2) Batched requests for the same file rely only on work from the first file
   lookup, which keeps the firmware in memory until the last release_firmware()
   is called

Batched requests *only* take effect if secondary requests come in prior to the
first user calling release_firmware(). The devres name used for the internal
firmware cache is used as a hint other pending requests are ongoing, the
firmware buffer data is kept in memory until the last user of the buffer
calls release_firmware(), therefore serializing requests and delaying the
release until all requests are done.

Batched requests wait for a wakup or signal so we can rely on the first file
fetch to write to the pending secondary requests. Commit 5b029624948d
("firmware: do not use fw_lock for fw_state protection") ported the firmware
API to use swait, and in doing so failed to convert complete_all() to
swake_up_all() -- it used swake_up(), loosing the ability for *some* batched
requests to take effect.

We *could* fix this by just using swake_up_all() *but* swait is now known
to be very special use case, so its best to just move away from it. So we
just go back to using completions as before commit 5b029624948d ("firmware:
do not use fw_lock for fw_state protection") given this was using
complete_all().

Without this fix it has been reported plugging in two Intel 6260 Wifi cards
on a system will end up enumerating the two devices only 50% of the time
[0]. The ported swake_up() should have actually handled the case with two
devices, however, *if more than two cards are used* the swake_up() would
not have sufficed. This change is only part of the required fixes for
batched requests. Subsequent fixes will follow.

This particular change should fix the cases where more than three requests
with the same firmware name is used, otherwise batched requests will wait for
MAX_SCHEDULE_TIMEOUT and just timeout eventually.

[0] https://bugzilla.kernel.org/show_bug.cgi?id=195477

CC: <stable@vger.kernel.org>    [4.10+]
Cc: Ming Lei <ming.lei@redhat.com>
Fixes: 5b029624948d ("firmware: do not use fw_lock for fw_state protection")
Reported-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
---
 drivers/base/firmware_class.c | 12 +++++-------
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index b9f907eedbf7..f50ec6e367bd 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -30,7 +30,6 @@
 #include <linux/syscore_ops.h>
 #include <linux/reboot.h>
 #include <linux/security.h>
-#include <linux/swait.h>
 
 #include <generated/utsrelease.h>
 
@@ -112,13 +111,13 @@ static inline long firmware_loading_timeout(void)
  * state of the firmware loading.
  */
 struct fw_state {
-	struct swait_queue_head wq;
+	struct completion completion;
 	enum fw_status status;
 };
 
 static void fw_state_init(struct fw_state *fw_st)
 {
-	init_swait_queue_head(&fw_st->wq);
+	init_completion(&fw_st->completion);
 	fw_st->status = FW_STATUS_UNKNOWN;
 }
 
@@ -131,9 +130,8 @@ static int __fw_state_wait_common(struct fw_state *fw_st, long timeout)
 {
 	long ret;
 
-	ret = swait_event_interruptible_timeout(fw_st->wq,
-				__fw_state_is_done(READ_ONCE(fw_st->status)),
-				timeout);
+	ret = wait_for_completion_interruptible_timeout(&fw_st->completion,
+							timeout);
 	if (ret != 0 && fw_st->status == FW_STATUS_ABORTED)
 		return -ENOENT;
 	if (!ret)
@@ -148,7 +146,7 @@ static void __fw_state_set(struct fw_state *fw_st,
 	WRITE_ONCE(fw_st->status, status);
 
 	if (status == FW_STATUS_DONE || status == FW_STATUS_ABORTED)
-		swake_up(&fw_st->wq);
+		complete_all(&fw_st->completion);
 }
 
 #define fw_state_start(fw_st)					\
-- 
2.11.0

[PATCH v3 2/4] test_firmware: add test case for SIGCHLD on sync fallback

[Luis R. Rodriguez]

It has been reported that SIGCHLD will trigger an immediate abort
on sync firmware requests which rely on the sysfs interface for a
trigger. This is unexpected behaviour, this reproduces this issue.

This test case currenty fails.

Reported-by: Martin Fuzzey <mfuzzey@parkeon.com>
Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
---
 tools/testing/selftests/firmware/fw_fallback.sh | 31 +++++++++++++++++++++++++
 1 file changed, 31 insertions(+)

diff --git a/tools/testing/selftests/firmware/fw_fallback.sh b/tools/testing/selftests/firmware/fw_fallback.sh
index 2e4c22d5abf7..8f511035f783 100755
--- a/tools/testing/selftests/firmware/fw_fallback.sh
+++ b/tools/testing/selftests/firmware/fw_fallback.sh
@@ -134,6 +134,27 @@ load_fw_custom_cancel()
 	wait
 }
 
+load_fw_fallback_with_child()
+{
+	local name="$1"
+	local file="$2"
+
+	# This is the value already set but we want to be explicit
+	echo 4 >/sys/class/firmware/timeout
+
+	sleep 1 &
+	SECONDS_BEFORE=$(date +%s)
+	echo -n "$name" >"$DIR"/trigger_request 2>/dev/null
+	SECONDS_AFTER=$(date +%s)
+	SECONDS_DELTA=$(($SECONDS_AFTER - $SECONDS_BEFORE))
+	if [ "$SECONDS_DELTA" -lt 4 ]; then
+		RET=1
+	else
+		RET=0
+	fi
+	wait
+	return $RET
+}
 
 trap "test_finish" EXIT
 
@@ -221,4 +242,14 @@ else
 	echo "$0: cancelling custom fallback mechanism works"
 fi
 
+set +e
+load_fw_fallback_with_child "nope-signal-$NAME" "$FW"
+if [ "$?" -eq 0 ]; then
+	echo "$0: SIGCHLD on sync ignored as expected" >&2
+else
+	echo "$0: error - sync firmware request cancelled due to SIGCHLD" >&2
+	exit 1
+fi
+set -e
+
 exit 0
-- 
2.11.0

Re: [PATCH v3 2/4] test_firmware: add test case for SIGCHLD on sync fallback

[Greg KH]

On Thu, Jun 29, 2017 at 01:51:49PM -0700, Luis R. Rodriguez wrote:
> It has been reported that SIGCHLD will trigger an immediate abort
> on sync firmware requests which rely on the sysfs interface for a
> trigger. This is unexpected behaviour, this reproduces this issue.
> 
> This test case currenty fails.

/me hands mcgrof a spell checker...

[PATCH v3 3/4] firmware: avoid invalid fallback aborts by using killable wait

[Luis R. Rodriguez]

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 -- for instance when a user hits CTRL-C. The abort was overly
*too* effective.

When a child process terminates (successful or not) the signal SIGCHLD can
be sent to the parent process which ran the child in the background and
later triggered a sync request for firmware through a sysfs interface which
relies on the fallback mechanism. This signal in turn can be recieved by the
interruptible wait we constructed on firmware_class and detects it as an
abort *before* userspace could get a chance to write the firmware. Upon
failure -EAGAIN is returned, so userspace is also kept in the dark about
exactly what happened.

We can reproduce the issue with the fw_fallback.sh selftest:

Before this patch:
$ sudo tools/testing/selftests/firmware/fw_fallback.sh
...
tools/testing/selftests/firmware/fw_fallback.sh: error - sync firmware request cancelled due to SIGCHLD

After this patch:
$ sudo tools/testing/selftests/firmware/fw_fallback.sh
...
tools/testing/selftests/firmware/fw_fallback.sh: SIGCHLD on sync ignored as expected

Fix this by making the wait killable -- only killable by SIGKILL (kill -9).
We loose the ability to allow userspace to cancel a write with CTRL-C
(SIGINT), however its been decided the compromise to require SIGKILL is
worth the gains.

Chances of this issue occuring are low due to the number of drivers upstream
exclusively relying on the fallback mechanism for firmware (2 drivers),
however this is observed in the field with custom drivers with sysfs
triggers to load firmware. Only distributions relying on the fallback
mechanism are impacted as well. An example reported issue was on Android,
as follows:

1) Android init (pid=1) fork()s (say pid=42) [this child process is totally
   unrelated to firmware loading, it could be sleep 2; for all we care ]
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, even
   normal termination)
5) Kernel delivers SIGCHLD to pid=1 to tell it a child has died, which
   causes -ERESTARTSYS to be returned from wait_*
6) The kernel's wait aborts and return -EAGAIN for the
   request_firmware() caller.

Cc: stable <stable@vger.kernel.org> # 4.0
Fixes: 0cb64249ca500 ("firmware_loader: abort request if wait_for_completion is interrupted")
Suggested-by: "Eric W. Biederman" <ebiederm@xmission.com>
Suggested-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Tested-by: Martin Fuzzey <mfuzzey@parkeon.com>
Reported-by: Martin Fuzzey <mfuzzey@parkeon.com>
Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
---
 drivers/base/firmware_class.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index f50ec6e367bd..cff33fb609e7 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -130,8 +130,7 @@ static int __fw_state_wait_common(struct fw_state *fw_st, long timeout)
 {
 	long ret;
 
-	ret = wait_for_completion_interruptible_timeout(&fw_st->completion,
-							timeout);
+	ret = wait_for_completion_killable_timeout(&fw_st->completion, timeout);
 	if (ret != 0 && fw_st->status == FW_STATUS_ABORTED)
 		return -ENOENT;
 	if (!ret)
-- 
2.11.0

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

[Luis R. Rodriguez]

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(-)

diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index cff33fb609e7..d3d071dbd2a5 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -1086,9 +1086,12 @@ static int _request_firmware_load(struct firmware_priv *fw_priv,
 		mutex_unlock(&fw_lock);
 	}
 
-	if (fw_state_is_aborted(&buf->fw_st))
-		retval = -EAGAIN;
-	else if (buf->is_paged_buf && !buf->data)
+	if (fw_state_is_aborted(&buf->fw_st)) {
+		if (retval == -ERESTARTSYS)
+			retval = -EINTR;
+		else
+			retval = -EAGAIN;
+	} else if (buf->is_paged_buf && !buf->data)
 		retval = -ENOMEM;
 
 	device_del(f_dev);
-- 
2.11.0

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

[Greg KH]

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

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

[Luis R. Rodriguez]

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

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

[Greg KH]

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

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

[Luis R. Rodriguez]

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