All of lore.kernel.org
 help / color / mirror / Atom feed
From: Larry Finger <Larry.Finger@lwfinger.net>
To: Ben Hutchings <ben@decadent.org.uk>
Cc: linville@tuxdriver.com, linux-wireless@vger.kernel.org,
	netdev@vger.kernel.org, Stable <stable@vger.kernel.org>
Subject: Re: [PATCH 2/3] b43: Fix oops if firmware is not available
Date: Sat, 11 Jan 2014 21:55:18 -0600	[thread overview]
Message-ID: <52D21226.4070306@lwfinger.net> (raw)
In-Reply-To: <1389497251.3720.40.camel@deadeye.wl.decadent.org.uk>

On 01/11/2014 09:27 PM, Ben Hutchings wrote:
> On Sat, 2014-01-11 at 13:48 -0600, Larry Finger wrote:
>> On openSUSE systems, the script that installs the firmware for b43 also
>> unloads and reloads the driver. When the firmware was not previously
>> available, the driver has stalled at a wait_for_completion(). When the
>> unload routine releases that hold, the driver encounters structures
>> that have already been deleted and generates a fatal condition. When
>> the user does a manual restart, the file system cleanup frequently
>> results in the firmware files being deleted and the user is never able
>> to install the firmware. The fix is to change the wait_for_completion()
>> with a wait_for_completion_timeout() with a 60 second wait period.
>>
>> There is a potential race condition; however, the chances that less
>> than a minute has elapsed between the initial driver load and a
>> subsequent unload is very unlikely.
>
> A minute-long race is 'unlikely' to be hit?  Seriously?!

Ben,

If you force a reboot before the minute expires, nothing weird happens. The only 
race condition happens when the user has to log in, open a terminal, run a 
script that downloads 13.5 MiB of files from the Internet, and then executes the 
firmware extraction program. On my 10 Mbps external line and a 2 GHz CPU, that 
takes 32 s, plus any time to enter the password for a sudo operation. That was 
the basis for my conclusion that a race is unlikely.

What is the minimum time that should be allowed for a request_firmware_nowait() 
to respond? I know we had to go to asynchronous fw loading because the 
synchronous  version would timeout at 30 s.

Larry



  reply	other threads:[~2014-01-12  3:55 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-11 19:48 [PATCH 0/3] Fixes for b43 and b43legacy Larry Finger
2014-01-11 19:48 ` Larry Finger
2014-01-11 19:48 ` [PATCH 2/3] b43: Fix oops if firmware is not available Larry Finger
2014-01-11 19:48   ` Larry Finger
2014-01-12  3:27   ` Ben Hutchings
2014-01-12  3:55     ` Larry Finger [this message]
2014-01-12  4:24       ` Ben Hutchings
2014-01-12  8:40         ` Johannes Berg
2014-01-12  8:40           ` Johannes Berg
2014-01-12 19:21         ` Larry Finger
2014-01-11 19:48 ` [PATCH 3/3] b43legacy: " Larry Finger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52D21226.4070306@lwfinger.net \
    --to=larry.finger@lwfinger.net \
    --cc=ben@decadent.org.uk \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linville@tuxdriver.com \
    --cc=netdev@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.