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
next prev parent 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.