Messages in this thread | | | Date | Fri, 14 Jun 2013 23:30:56 -0700 | From | Guenter Roeck <> | Subject | Re: BUG: unable to handle kernel NULL pointer dereference at 0000000000000040 |
| |
On Sat, Jun 15, 2013 at 10:32:14AM +0800, Ming Lei wrote: > On Sat, Jun 15, 2013 at 1:07 AM, nirinA raseliarison > <nirina.raseliarison@gmail.com> wrote: > > > patch applied and no longer have the bug message when i > > reboot and wake up the ethernet controller. > > I am wondering if Guenter's patch can fix the race really, but I'd like to > see Guenter's explanation on his patch. > > The race should be caused by below: > > - request timeout triggered by internal timer > > - user space aborts the requests before the line in _request_firmware_load() > > fw_priv->buf = NULL > > which is run in timeout path > > - then the abort() called from firmware_loading_store() may use a freed fw buf > since the timeout path will free the fw buffer. > > Considered clearing 'fw_priv->buf' in _request_firmware_load()() isn't protected > by fw_lock now, so Guenter's patch can't avoid the race entirely. > I agree; my patch only protects one specific path, and was based on the observation that access to fw_priv->buf is protected elsewhwere in the code. My suspicion was that fw_priv->buf was freed while waiting for the mutex in firmware_loading_store().
Your patch is more comprehensive.
Guenter
| |