Bug 15494 - BUG: key ffff88013d4f4c70 not in .data! when loading microcode.ko
Summary: BUG: key ffff88013d4f4c70 not in .data! when loading microcode.ko
Status: CLOSED CODE_FIX
Alias: None
Product: Drivers
Classification: Unclassified
Component: Other (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: drivers_other
URL:
Keywords:
Depends on:
Blocks: 15310
  Show dependency tree
 
Reported: 2010-03-09 16:28 UTC by Alex Villacis Lasso
Modified: 2010-03-21 23:35 UTC (History)
3 users (show)

See Also:
Kernel Version: 2.6.34-rc1
Subsystem:
Regression: Yes
Bisected commit-id:


Attachments
Full dmesg output for 2.6.34-rc1 on my machine (52.70 KB, text/plain)
2010-03-09 16:28 UTC, Alex Villacis Lasso
Details
Configuration used to compile faulty kernel (94.26 KB, text/plain)
2010-03-09 16:29 UTC, Alex Villacis Lasso
Details
lspci -v output for my machine (5.91 KB, text/plain)
2010-03-09 16:30 UTC, Alex Villacis Lasso
Details
Contents of /proc/cpuinfo (1.49 KB, text/plain)
2010-03-09 16:31 UTC, Alex Villacis Lasso
Details
Contents of /proc/meminfo (1.09 KB, text/plain)
2010-03-09 16:31 UTC, Alex Villacis Lasso
Details

Description Alex Villacis Lasso 2010-03-09 16:28:17 UTC
Created attachment 25426 [details]
Full dmesg output for 2.6.34-rc1 on my machine

When loading the module microcode.ko on my 64-bit system, I get the following dump on the kernel log:

[   10.774690] ------------[ cut here ]------------
[   10.774726] WARNING: at kernel/lockdep.c:2706 lockdep_init_map+0x114/0x130()
[   10.774759] Hardware name:         
[   10.774774] Modules linked in: microcode(+) kvm_intel kvm uinput snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm snd_timer snd i2c_i801 soundcore iTCO_wdt snd_page_alloc iTCO_vendor_support ppdev parport_pc parport pcspkr r8169 mii dm_multipath i915 drm_kms_helper drm i2c_algo_bit i2c_core video output [last unloaded: scsi_wait_scan]
[   10.775026] Pid: 1939, comm: modprobe Not tainted 2.6.34-rc1 #9
[   10.775048] Call Trace:
[   10.775063]  [<ffffffff81048006>] warn_slowpath_common+0x76/0xb0
[   10.775087]  [<ffffffff8104804f>] warn_slowpath_null+0xf/0x20
[   10.775109]  [<ffffffff81073c34>] lockdep_init_map+0x114/0x130
[   10.775139]  [<ffffffff8115b3aa>] sysfs_add_file_mode+0x6a/0xc0
[   10.775163]  [<ffffffff8115b40c>] sysfs_add_file+0xc/0x10
[   10.775185]  [<ffffffff8115d8a1>] sysfs_create_bin_file+0x21/0x30
[   10.775209]  [<ffffffff812945bd>] _request_firmware+0x21d/0x4e0
[   10.775232]  [<ffffffff8129490e>] request_firmware+0xe/0x10
[   10.775256]  [<ffffffffa00f1bc1>] request_microcode_fw+0x61/0xa0 [microcode]
[   10.775283]  [<ffffffff8115db01>] ? internal_create_group+0xc1/0x1a0
[   10.775309]  [<ffffffffa00f13b8>] microcode_init_cpu+0xb8/0xd0 [microcode]
[   10.775336]  [<ffffffffa00f1426>] mc_sysdev_add+0x56/0x70 [microcode]
[   10.775361]  [<ffffffff8128a04e>] sysdev_driver_register+0x9e/0x130
[   10.775386]  [<ffffffffa0130000>] ? microcode_init+0x0/0x12b [microcode]
[   10.775412]  [<ffffffffa01300be>] microcode_init+0xbe/0x12b [microcode]
[   10.775438]  [<ffffffff810001d7>] do_one_initcall+0x37/0x190
[   10.775462]  [<ffffffff8107fe4b>] sys_init_module+0xdb/0x250
[   10.775485]  [<ffffffff81002e6b>] system_call_fastpath+0x16/0x1b
[   10.775508] ---[ end trace e0218cb5fc4c0bc8 ]---

This dump did not appear with vanilla 2.6.33.

Steps to reproduce:
1) compile 2.6.34-rc1 with attached configuration
2) run on 64-bit intel machine
3) load microcode.ko or make system configuration load it.

Actual results:
kernel dump as shown above

Expected results: 
no dump, microcode should load normally
Comment 1 Alex Villacis Lasso 2010-03-09 16:29:14 UTC
Created attachment 25427 [details]
Configuration used to compile faulty kernel
Comment 2 Alex Villacis Lasso 2010-03-09 16:30:31 UTC
Created attachment 25428 [details]
lspci -v output for my machine
Comment 3 Alex Villacis Lasso 2010-03-09 16:31:14 UTC
Created attachment 25429 [details]
Contents of /proc/cpuinfo
Comment 4 Alex Villacis Lasso 2010-03-09 16:31:47 UTC
Created attachment 25430 [details]
Contents of /proc/meminfo
Comment 5 Andrew Morton 2010-03-18 21:36:29 UTC
(switched to email.  Please respond via emailed reply-to-all, not via the
bugzilla web interface).

On Tue, 9 Mar 2010 16:28:21 GMT
bugzilla-daemon@bugzilla.kernel.org wrote:

> http://bugzilla.kernel.org/show_bug.cgi?id=15494

Seems to be a post-2.6.33 regression.

>            Summary: BUG: key ffff88013d4f4c70 not in .data! when loading
>                     microcode.ko
>            Product: Drivers
>            Version: 2.5
>     Kernel Version: 2.6.34-rc1
>           Platform: All
>         OS/Version: Linux
>               Tree: Mainline
>             Status: NEW
>           Severity: normal
>           Priority: P1
>          Component: Other
>         AssignedTo: drivers_other@kernel-bugs.osdl.org
>         ReportedBy: avillaci@ceibo.fiec.espol.edu.ec
>         Regression: Yes
> 
> 
> Created an attachment (id=25426)
>  --> (http://bugzilla.kernel.org/attachment.cgi?id=25426)
> Full dmesg output for 2.6.34-rc1 on my machine
> 
> When loading the module microcode.ko on my 64-bit system, I get the following
> dump on the kernel log:
> 
> [   10.774690] ------------[ cut here ]------------
> [   10.774726] WARNING: at kernel/lockdep.c:2706
> lockdep_init_map+0x114/0x130()
> [   10.774759] Hardware name:         
> [   10.774774] Modules linked in: microcode(+) kvm_intel kvm uinput
> snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_seq
> snd_seq_device snd_pcm snd_timer snd i2c_i801 soundcore iTCO_wdt
> snd_page_alloc
> iTCO_vendor_support ppdev parport_pc parport pcspkr r8169 mii dm_multipath
> i915
> drm_kms_helper drm i2c_algo_bit i2c_core video output [last unloaded:
> scsi_wait_scan]
> [   10.775026] Pid: 1939, comm: modprobe Not tainted 2.6.34-rc1 #9
> [   10.775048] Call Trace:
> [   10.775063]  [<ffffffff81048006>] warn_slowpath_common+0x76/0xb0
> [   10.775087]  [<ffffffff8104804f>] warn_slowpath_null+0xf/0x20
> [   10.775109]  [<ffffffff81073c34>] lockdep_init_map+0x114/0x130
> [   10.775139]  [<ffffffff8115b3aa>] sysfs_add_file_mode+0x6a/0xc0
> [   10.775163]  [<ffffffff8115b40c>] sysfs_add_file+0xc/0x10
> [   10.775185]  [<ffffffff8115d8a1>] sysfs_create_bin_file+0x21/0x30
> [   10.775209]  [<ffffffff812945bd>] _request_firmware+0x21d/0x4e0
> [   10.775232]  [<ffffffff8129490e>] request_firmware+0xe/0x10
> [   10.775256]  [<ffffffffa00f1bc1>] request_microcode_fw+0x61/0xa0
> [microcode]
> [   10.775283]  [<ffffffff8115db01>] ? internal_create_group+0xc1/0x1a0
> [   10.775309]  [<ffffffffa00f13b8>] microcode_init_cpu+0xb8/0xd0 [microcode]
> [   10.775336]  [<ffffffffa00f1426>] mc_sysdev_add+0x56/0x70 [microcode]
> [   10.775361]  [<ffffffff8128a04e>] sysdev_driver_register+0x9e/0x130
> [   10.775386]  [<ffffffffa0130000>] ? microcode_init+0x0/0x12b [microcode]
> [   10.775412]  [<ffffffffa01300be>] microcode_init+0xbe/0x12b [microcode]
> [   10.775438]  [<ffffffff810001d7>] do_one_initcall+0x37/0x190
> [   10.775462]  [<ffffffff8107fe4b>] sys_init_module+0xdb/0x250
> [   10.775485]  [<ffffffff81002e6b>] system_call_fastpath+0x16/0x1b
> [   10.775508] ---[ end trace e0218cb5fc4c0bc8 ]---
> 
> This dump did not appear with vanilla 2.6.33.
> 
> Steps to reproduce:
> 1) compile 2.6.34-rc1 with attached configuration
> 2) run on 64-bit intel machine
> 3) load microcode.ko or make system configuration load it.
> 
> Actual results:
> kernel dump as shown above
> 
> Expected results: 
> no dump, microcode should load normally
> 

Methinks 6992f5334995af474c2b58d010d08bc597f0f2fe ("sysfs: Use one
lockdep class per sysfs attribute") is implicated.
Comment 6 Greg Kroah-Hartman 2010-03-18 21:57:41 UTC
Known issue.  It's not a "bug", but a warning.

And the microcode should have loaded normally.

I have a set of patches queued up to go to Linus later today to resolve this.
Comment 7 Anonymous Emailer 2010-03-19 01:09:26 UTC
Reply-To: peterz@infradead.org

On Thu, 2010-03-18 at 14:35 -0700, Andrew Morton wrote:
> (switched to email.  Please respond via emailed reply-to-all, not via the
> bugzilla web interface).
> 
> On Tue, 9 Mar 2010 16:28:21 GMT
> bugzilla-daemon@bugzilla.kernel.org wrote:
> 
> > http://bugzilla.kernel.org/show_bug.cgi?id=15494
> 
> Seems to be a post-2.6.33 regression.
> 
> >            Summary: BUG: key ffff88013d4f4c70 not in .data! when loading
> >                     microcode.ko
> >            Product: Drivers
> >            Version: 2.5
> >     Kernel Version: 2.6.34-rc1
> >           Platform: All
> >         OS/Version: Linux
> >               Tree: Mainline
> >             Status: NEW
> >           Severity: normal
> >           Priority: P1
> >          Component: Other
> >         AssignedTo: drivers_other@kernel-bugs.osdl.org
> >         ReportedBy: avillaci@ceibo.fiec.espol.edu.ec
> >         Regression: Yes
> > 
> > 
> > Created an attachment (id=25426)
> >  --> (http://bugzilla.kernel.org/attachment.cgi?id=25426)
> > Full dmesg output for 2.6.34-rc1 on my machine
> > 
> > When loading the module microcode.ko on my 64-bit system, I get the
> following
> > dump on the kernel log:
> > 
> > [   10.774690] ------------[ cut here ]------------
> > [   10.774726] WARNING: at kernel/lockdep.c:2706
> lockdep_init_map+0x114/0x130()
> > [   10.774759] Hardware name:         
> > [   10.774774] Modules linked in: microcode(+) kvm_intel kvm uinput
> > snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_seq
> > snd_seq_device snd_pcm snd_timer snd i2c_i801 soundcore iTCO_wdt
> snd_page_alloc
> > iTCO_vendor_support ppdev parport_pc parport pcspkr r8169 mii dm_multipath
> i915
> > drm_kms_helper drm i2c_algo_bit i2c_core video output [last unloaded:
> > scsi_wait_scan]
> > [   10.775026] Pid: 1939, comm: modprobe Not tainted 2.6.34-rc1 #9
> > [   10.775048] Call Trace:
> > [   10.775063]  [<ffffffff81048006>] warn_slowpath_common+0x76/0xb0
> > [   10.775087]  [<ffffffff8104804f>] warn_slowpath_null+0xf/0x20
> > [   10.775109]  [<ffffffff81073c34>] lockdep_init_map+0x114/0x130
> > [   10.775139]  [<ffffffff8115b3aa>] sysfs_add_file_mode+0x6a/0xc0
> > [   10.775163]  [<ffffffff8115b40c>] sysfs_add_file+0xc/0x10
> > [   10.775185]  [<ffffffff8115d8a1>] sysfs_create_bin_file+0x21/0x30
> > [   10.775209]  [<ffffffff812945bd>] _request_firmware+0x21d/0x4e0
> > [   10.775232]  [<ffffffff8129490e>] request_firmware+0xe/0x10
> > [   10.775256]  [<ffffffffa00f1bc1>] request_microcode_fw+0x61/0xa0
> [microcode]
> > [   10.775283]  [<ffffffff8115db01>] ? internal_create_group+0xc1/0x1a0
> > [   10.775309]  [<ffffffffa00f13b8>] microcode_init_cpu+0xb8/0xd0
> [microcode]
> > [   10.775336]  [<ffffffffa00f1426>] mc_sysdev_add+0x56/0x70 [microcode]
> > [   10.775361]  [<ffffffff8128a04e>] sysdev_driver_register+0x9e/0x130
> > [   10.775386]  [<ffffffffa0130000>] ? microcode_init+0x0/0x12b [microcode]
> > [   10.775412]  [<ffffffffa01300be>] microcode_init+0xbe/0x12b [microcode]
> > [   10.775438]  [<ffffffff810001d7>] do_one_initcall+0x37/0x190
> > [   10.775462]  [<ffffffff8107fe4b>] sys_init_module+0xdb/0x250
> > [   10.775485]  [<ffffffff81002e6b>] system_call_fastpath+0x16/0x1b
> > [   10.775508] ---[ end trace e0218cb5fc4c0bc8 ]---
> > 
> > This dump did not appear with vanilla 2.6.33.
> > 
> > Steps to reproduce:
> > 1) compile 2.6.34-rc1 with attached configuration
> > 2) run on 64-bit intel machine
> > 3) load microcode.ko or make system configuration load it.
> > 
> > Actual results:
> > kernel dump as shown above
> > 
> > Expected results: 
> > no dump, microcode should load normally
> > 
> 
> Methinks 6992f5334995af474c2b58d010d08bc597f0f2fe ("sysfs: Use one
> lockdep class per sysfs attribute") is implicated.  

You're right, that patch adds a key to struct attribute, and the
firmware stuff seems to dynamically allocate these things in
firmware_priv::bin_attribute::attr.

The allocation seems to happen in fw_register_device().

So yes, that patch is incompatible with the firmware usage, as struct
lock_class_key's are required to be in static storage.
Comment 8 Anonymous Emailer 2010-03-19 01:15:19 UTC
Reply-To: peterz@infradead.org

On Thu, 2010-03-18 at 14:35 -0700, Andrew Morton wrote:
> (switched to email.  Please respond via emailed reply-to-all, not via the
> bugzilla web interface).
> 
> On Tue, 9 Mar 2010 16:28:21 GMT
> bugzilla-daemon@bugzilla.kernel.org wrote:
> 
> > http://bugzilla.kernel.org/show_bug.cgi?id=15494
> 
> Seems to be a post-2.6.33 regression.
> 
> >            Summary: BUG: key ffff88013d4f4c70 not in .data! when loading
> >                     microcode.ko
> >            Product: Drivers
> >            Version: 2.5
> >     Kernel Version: 2.6.34-rc1
> >           Platform: All
> >         OS/Version: Linux
> >               Tree: Mainline
> >             Status: NEW
> >           Severity: normal
> >           Priority: P1
> >          Component: Other
> >         AssignedTo: drivers_other@kernel-bugs.osdl.org
> >         ReportedBy: avillaci@ceibo.fiec.espol.edu.ec
> >         Regression: Yes
> > 
> > 
> > Created an attachment (id=25426)
> >  --> (http://bugzilla.kernel.org/attachment.cgi?id=25426)
> > Full dmesg output for 2.6.34-rc1 on my machine
> > 
> > When loading the module microcode.ko on my 64-bit system, I get the
> following
> > dump on the kernel log:
> > 
> > [   10.774690] ------------[ cut here ]------------
> > [   10.774726] WARNING: at kernel/lockdep.c:2706
> lockdep_init_map+0x114/0x130()
> > [   10.774759] Hardware name:         
> > [   10.774774] Modules linked in: microcode(+) kvm_intel kvm uinput
> > snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_seq
> > snd_seq_device snd_pcm snd_timer snd i2c_i801 soundcore iTCO_wdt
> snd_page_alloc
> > iTCO_vendor_support ppdev parport_pc parport pcspkr r8169 mii dm_multipath
> i915
> > drm_kms_helper drm i2c_algo_bit i2c_core video output [last unloaded:
> > scsi_wait_scan]
> > [   10.775026] Pid: 1939, comm: modprobe Not tainted 2.6.34-rc1 #9
> > [   10.775048] Call Trace:
> > [   10.775063]  [<ffffffff81048006>] warn_slowpath_common+0x76/0xb0
> > [   10.775087]  [<ffffffff8104804f>] warn_slowpath_null+0xf/0x20
> > [   10.775109]  [<ffffffff81073c34>] lockdep_init_map+0x114/0x130
> > [   10.775139]  [<ffffffff8115b3aa>] sysfs_add_file_mode+0x6a/0xc0
> > [   10.775163]  [<ffffffff8115b40c>] sysfs_add_file+0xc/0x10
> > [   10.775185]  [<ffffffff8115d8a1>] sysfs_create_bin_file+0x21/0x30
> > [   10.775209]  [<ffffffff812945bd>] _request_firmware+0x21d/0x4e0
> > [   10.775232]  [<ffffffff8129490e>] request_firmware+0xe/0x10
> > [   10.775256]  [<ffffffffa00f1bc1>] request_microcode_fw+0x61/0xa0
> [microcode]
> > [   10.775283]  [<ffffffff8115db01>] ? internal_create_group+0xc1/0x1a0
> > [   10.775309]  [<ffffffffa00f13b8>] microcode_init_cpu+0xb8/0xd0
> [microcode]
> > [   10.775336]  [<ffffffffa00f1426>] mc_sysdev_add+0x56/0x70 [microcode]
> > [   10.775361]  [<ffffffff8128a04e>] sysdev_driver_register+0x9e/0x130
> > [   10.775386]  [<ffffffffa0130000>] ? microcode_init+0x0/0x12b [microcode]
> > [   10.775412]  [<ffffffffa01300be>] microcode_init+0xbe/0x12b [microcode]
> > [   10.775438]  [<ffffffff810001d7>] do_one_initcall+0x37/0x190
> > [   10.775462]  [<ffffffff8107fe4b>] sys_init_module+0xdb/0x250
> > [   10.775485]  [<ffffffff81002e6b>] system_call_fastpath+0x16/0x1b
> > [   10.775508] ---[ end trace e0218cb5fc4c0bc8 ]---
> > 
> > This dump did not appear with vanilla 2.6.33.
> > 
> > Steps to reproduce:
> > 1) compile 2.6.34-rc1 with attached configuration
> > 2) run on 64-bit intel machine
> > 3) load microcode.ko or make system configuration load it.
> > 
> > Actual results:
> > kernel dump as shown above
> > 
> > Expected results: 
> > no dump, microcode should load normally
> > 
> 
> Methinks 6992f5334995af474c2b58d010d08bc597f0f2fe ("sysfs: Use one
> lockdep class per sysfs attribute") is implicated.  

You're right, that patch adds a key to struct attribute, and the
firmware stuff seems to dynamically allocate these things in
firmware_priv::bin_attribute::attr.

The allocation seems to happen in fw_register_device().

So yes, that patch is incompatible with the firmware usage, as struct
lock_class_key's are required to be in static storage.
Comment 9 Eric W. Biederman 2010-03-19 02:00:44 UTC
Peter Zijlstra <peterz@infradead.org> writes:

> On Thu, 2010-03-18 at 14:35 -0700, Andrew Morton wrote:
>> (switched to email.  Please respond via emailed reply-to-all, not via the
>> bugzilla web interface).
>> 
>> On Tue, 9 Mar 2010 16:28:21 GMT
>> bugzilla-daemon@bugzilla.kernel.org wrote:
>> 
>> > http://bugzilla.kernel.org/show_bug.cgi?id=15494
>> 
>> Seems to be a post-2.6.33 regression.
>> 
>> >            Summary: BUG: key ffff88013d4f4c70 not in .data! when loading
>> >                     microcode.ko
>> >            Product: Drivers
>> >            Version: 2.5
>> >     Kernel Version: 2.6.34-rc1
>> >           Platform: All
>> >         OS/Version: Linux
>> >               Tree: Mainline
>> >             Status: NEW
>> >           Severity: normal
>> >           Priority: P1
>> >          Component: Other
>> >         AssignedTo: drivers_other@kernel-bugs.osdl.org
>> >         ReportedBy: avillaci@ceibo.fiec.espol.edu.ec
>> >         Regression: Yes
>> > 
>> > 
>> > Created an attachment (id=25426)
>> >  --> (http://bugzilla.kernel.org/attachment.cgi?id=25426)
>> > Full dmesg output for 2.6.34-rc1 on my machine
>> > 
>> > When loading the module microcode.ko on my 64-bit system, I get the
>> following
>> > dump on the kernel log:
>> > 
>> > [   10.774690] ------------[ cut here ]------------
>> > [   10.774726] WARNING: at kernel/lockdep.c:2706
>> lockdep_init_map+0x114/0x130()
>> > [   10.774759] Hardware name:         
>> > [   10.774774] Modules linked in: microcode(+) kvm_intel kvm uinput
>> > snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_seq
>> > snd_seq_device snd_pcm snd_timer snd i2c_i801 soundcore iTCO_wdt
>> snd_page_alloc
>> > iTCO_vendor_support ppdev parport_pc parport pcspkr r8169 mii dm_multipath
>> i915
>> > drm_kms_helper drm i2c_algo_bit i2c_core video output [last unloaded:
>> > scsi_wait_scan]
>> > [   10.775026] Pid: 1939, comm: modprobe Not tainted 2.6.34-rc1 #9
>> > [   10.775048] Call Trace:
>> > [   10.775063]  [<ffffffff81048006>] warn_slowpath_common+0x76/0xb0
>> > [   10.775087]  [<ffffffff8104804f>] warn_slowpath_null+0xf/0x20
>> > [   10.775109]  [<ffffffff81073c34>] lockdep_init_map+0x114/0x130
>> > [   10.775139]  [<ffffffff8115b3aa>] sysfs_add_file_mode+0x6a/0xc0
>> > [   10.775163]  [<ffffffff8115b40c>] sysfs_add_file+0xc/0x10
>> > [   10.775185]  [<ffffffff8115d8a1>] sysfs_create_bin_file+0x21/0x30
>> > [   10.775209]  [<ffffffff812945bd>] _request_firmware+0x21d/0x4e0
>> > [   10.775232]  [<ffffffff8129490e>] request_firmware+0xe/0x10
>> > [   10.775256]  [<ffffffffa00f1bc1>] request_microcode_fw+0x61/0xa0
>> [microcode]
>> > [   10.775283]  [<ffffffff8115db01>] ? internal_create_group+0xc1/0x1a0
>> > [   10.775309]  [<ffffffffa00f13b8>] microcode_init_cpu+0xb8/0xd0
>> [microcode]
>> > [   10.775336]  [<ffffffffa00f1426>] mc_sysdev_add+0x56/0x70 [microcode]
>> > [   10.775361]  [<ffffffff8128a04e>] sysdev_driver_register+0x9e/0x130
>> > [   10.775386]  [<ffffffffa0130000>] ? microcode_init+0x0/0x12b
>> [microcode]
>> > [   10.775412]  [<ffffffffa01300be>] microcode_init+0xbe/0x12b [microcode]
>> > [   10.775438]  [<ffffffff810001d7>] do_one_initcall+0x37/0x190
>> > [   10.775462]  [<ffffffff8107fe4b>] sys_init_module+0xdb/0x250
>> > [   10.775485]  [<ffffffff81002e6b>] system_call_fastpath+0x16/0x1b
>> > [   10.775508] ---[ end trace e0218cb5fc4c0bc8 ]---
>> > 
>> > This dump did not appear with vanilla 2.6.33.
>> > 
>> > Steps to reproduce:
>> > 1) compile 2.6.34-rc1 with attached configuration
>> > 2) run on 64-bit intel machine
>> > 3) load microcode.ko or make system configuration load it.
>> > 
>> > Actual results:
>> > kernel dump as shown above
>> > 
>> > Expected results: 
>> > no dump, microcode should load normally
>> > 
>> 
>> Methinks 6992f5334995af474c2b58d010d08bc597f0f2fe ("sysfs: Use one
>> lockdep class per sysfs attribute") is implicated.  
>
> You're right, that patch adds a key to struct attribute, and the
> firmware stuff seems to dynamically allocate these things in
> firmware_priv::bin_attribute::attr.
>
> The allocation seems to happen in fw_register_device().
>
> So yes, that patch is incompatible with the firmware usage, as struct
> lock_class_key's are required to be in static storage.

Greg already has a patch for this one queued in his tree.
Essentially it is just sysfs_attr_init.

99% of the sysfs attributes are static so it made sense to optimize
that case and only require explicit initialization on the handful
of dynamically allocated sysfs attributes.

Eric
Comment 10 Rafael J. Wysocki 2010-03-21 23:34:44 UTC
On Monday 22 March 2010, Wolfram Sang wrote:
> On Sun, Mar 21, 2010 at 09:30:51PM +0100, Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of regressions introduced between 2.6.32 and 2.6.33.
> > 
> > The following bug entry is on the current list of known regressions
> > introduced between 2.6.32 and 2.6.33.  Please verify if it still should
> > be listed and let the tracking team know (either way).
> 
> This is actually a regression from 2.6.33. It should haven been fixed
> in rc2 with e1955ca0ee55286cbc65a8ed7471d540ae83dac8.

Note You need to log in before you can comment on or make changes to this bug.