Hi, I have discovered a Oops in the firmware_loading_store function. At first it looks like a timing issue but after adding a BUG_ON test, it fails every time. drivers\base\firmware_class: ------------------------------ 541 01c0 F6463401 testb $1,52(%esi) 542 01c4 0F843FFF je .L38 542 FFFF 543 .loc 1 174 0 544 01ca 8B4630 movl 48(%esi),%eax 545 01cd 8B4004 movl 4(%eax),%eax <---- Oops 546 01d0 E8FCFFFF call vfree 546 FF The code that fails was introduced in commit 6e03a201bbe8137487f340d26aa662110e324b20 Attached you will find the: - Oops with the vanilla 2.6.31 - The BUG_ON patch - Oops with the patched 2.6.31 /Lars
Created attachment 23111 [details] Vanilla_Opps.txt
Created attachment 23112 [details] BUG_ON_firmware_class.c.patch
Created attachment 23113 [details] BUG_ON_Oops.txt
First-Bad-Commit : 6e03a201bbe8137487f340d26aa662110e324b20 Notify-Also : David Woodhouse <dwmw2@infradead.org>
Notify-Also : Frederik Deweerdt <frederik.deweerdt@xprog.eu>
Created attachment 23237 [details] Proposed fix: mutex accesses to fw_priv->fw The patch to be found on the above URL should fix the race between _request_firmware and firmware_loading_store by protecting the accesses to fw_priv->fw.
*** This bug has been marked as a duplicate of bug 14253 ***