On Thu, Jul 9, 2015 at 1:29 AM, Linus Torvalds <torva...@linux-foundation.org> wrote: > On Wed, Jul 8, 2015 at 10:17 AM, Linus Torvalds > <torva...@linux-foundation.org> wrote: >> >> Decoding the "Code:" line shows that this is the "->fw_id" dereference in >> >> if (add_uevent_var(env, "FIRMWARE=%s", fw_priv->buf->fw_id)) >> return -ENOMEM; >> >> and that "fw_priv->buf" pointer is NULL. >> >> However, I don't see anything that looks like it should have changed >> any of this since 4.1. > > Looking at the otehr uses of "fw_priv->buf", they all check that > pointer for NULL. I see code like > > fw_buf = fw_priv->buf; > if (!fw_buf) > goto out; > > etc. > > Also, it looks like you need to hold the "fw_lock" to even look at > that pointer, since the buffer can get reallocated etc.
Yes, the above code with holding 'fw_lock' is right fix for the issue since sysfs read can happen anytime, and there is one race between firmware request abort and reading uevent of sysfs. > So that uevent code really looks buggy. It just doesn't look like a > *new* bug to me. That code looks old, going back to 2012 and commit > 1244691c73b2. Exactly. Thanks, Ming -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
