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

Groups > linux.kernel > #1675113 > unrolled thread

[PATCH v2] firmware: fix batched requests - wake all waiters

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [PATCH v2] firmware: fix batched requests - wake all waiters "Luis R. Rodriguez" <mcgrof@kernel.org> - 2017-06-26 23:30 +0200
    Re: [PATCH v2] firmware: fix batched requests - wake all waiters Greg KH <gregkh@linuxfoundation.org> - 2017-06-29 17:20 +0200
      Re: [PATCH v2] firmware: fix batched requests - wake all waiters Greg KH <gregkh@linuxfoundation.org> - 2017-06-29 17:20 +0200
        Re: [PATCH v2] firmware: fix batched requests - wake all waiters "Luis R. Rodriguez" <mcgrof@kernel.org> - 2017-06-29 19:40 +0200

#1675113 — [PATCH v2] firmware: fix batched requests - wake all waiters

From: Jakub Kicinski <jakub.kicinski@netronome.com>

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 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 (we only accept SIGKILL now) 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.

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 two devices, however,
*if more than two cards are used* the swake_up() would not suffice. 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

Fixes: 5b029624948d ("firmware: do not use fw_lock for fw_state protection")
CC: <stable@vger.kernel.org>    [4.10+]
Cc: Ming Lei <ming.lei@redhat.com>
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
[mcgrof: expanded on impact on commit log]
Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
---

Greg, I think it would make sense to queue this in after the signal stable
fixes [1].

[1] https://lkml.kernel.org/r/20170614222017.14653-1-mcgrof@kernel.org

 drivers/base/firmware_class.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index b9f907eedbf7..686381a621a0 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -148,7 +148,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);
+		swake_up_all(&fw_st->wq);
 }
 
 #define fw_state_start(fw_st)					\
-- 
2.11.0

[toc] | [next] | [standalone]

#1677859

On Mon, Jun 26, 2017 at 02:23:12PM -0700, Luis R. Rodriguez wrote:
> From: Jakub Kicinski <jakub.kicinski@netronome.com>
> 
> 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 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 (we only accept SIGKILL now) 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.
> 
> 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 two devices, however,
> *if more than two cards are used* the swake_up() would not suffice. 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
> 
> Fixes: 5b029624948d ("firmware: do not use fw_lock for fw_state protection")
> CC: <stable@vger.kernel.org>    [4.10+]
> Cc: Ming Lei <ming.lei@redhat.com>
> Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> [mcgrof: expanded on impact on commit log]
> Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
> ---
> 
> Greg, I think it would make sense to queue this in after the signal stable
> fixes [1].

As I just dropped them, can you redo this based on Linus's tree now?

thanks,

greg k-h

[toc] | [prev] | [next] | [standalone]

#1677861

On Thu, Jun 29, 2017 at 05:16:41PM +0200, Greg KH wrote:
> On Mon, Jun 26, 2017 at 02:23:12PM -0700, Luis R. Rodriguez wrote:
> > From: Jakub Kicinski <jakub.kicinski@netronome.com>
> > 
> > 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 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 (we only accept SIGKILL now) 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.
> > 
> > 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 two devices, however,
> > *if more than two cards are used* the swake_up() would not suffice. 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
> > 
> > Fixes: 5b029624948d ("firmware: do not use fw_lock for fw_state protection")
> > CC: <stable@vger.kernel.org>    [4.10+]
> > Cc: Ming Lei <ming.lei@redhat.com>
> > Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> > [mcgrof: expanded on impact on commit log]
> > Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
> > ---
> > 
> > Greg, I think it would make sense to queue this in after the signal stable
> > fixes [1].
> 
> As I just dropped them, can you redo this based on Linus's tree now?

Oh nevermind, it does apply to that tree now.  Wait, what am I supposed
to do here?

confused,

greg k-h

[toc] | [prev] | [next] | [standalone]

#1677998

On Thu, Jun 29, 2017 at 05:17:15PM +0200, Greg KH wrote:
> On Thu, Jun 29, 2017 at 05:16:41PM +0200, Greg KH wrote:
> > On Mon, Jun 26, 2017 at 02:23:12PM -0700, Luis R. Rodriguez wrote:
> > > From: Jakub Kicinski <jakub.kicinski@netronome.com>
> > > 
> > > 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 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 (we only accept SIGKILL now) 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.
> > > 
> > > 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 two devices, however,
> > > *if more than two cards are used* the swake_up() would not suffice. 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
> > > 
> > > Fixes: 5b029624948d ("firmware: do not use fw_lock for fw_state protection")
> > > CC: <stable@vger.kernel.org>    [4.10+]
> > > Cc: Ming Lei <ming.lei@redhat.com>
> > > Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> > > [mcgrof: expanded on impact on commit log]
> > > Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
> > > ---
> > > 
> > > Greg, I think it would make sense to queue this in after the signal stable
> > > fixes [1].
> > 
> > As I just dropped them, can you redo this based on Linus's tree now?
> 
> Oh nevermind, it does apply to that tree now.  Wait, what am I supposed
> to do here?
> 
> confused,

Yea..  and moving way from swait actually means this should be applied first,
just that this patch becomes a port back away from swait. The signal series of
fixes are patches which should be applied even before swait.

Since this can be confusing I'm just going to fold this patch into the other larger
series. That should make order clear.

  Luis

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web