Messages in this thread | | | Subject | Re: BUG: unable to handle kernel NULL pointer dereference at 0000000000000040 | Date | Sat, 15 Jun 2013 19:43:10 +0300 | From | nirinA raseliarison <> |
| |
on Sat, 15 Jun 2013 11:08:47 +0300, Ming Lei <ming.lei@canonical.com> wrote:
> On Sat, Jun 15, 2013 at 2:30 PM, Guenter Roeck <linux@roeck-us.net> > wrote: >> 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. > > OK, thanks for your reply. > > I will post out one version for merge, and this one moves the > "fw_priv->buf = NULL;" into fw_load_abort() for simplifying change.
this is just to let you know that i've tested Ming Lei's latest patch. thank you very much for the fix and the explanation.
-- nirinA
| |