Messages in this thread | | | Date | Sat, 15 Jun 2013 16:08:47 +0800 | Subject | Re: BUG: unable to handle kernel NULL pointer dereference at 0000000000000040 | From | Ming Lei <> |
| |
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.
Thanks, -- Ming Lei
| |