sysfs lockdep complaint
Johannes Berg
[ 30.490674] =============================================
[ 30.490708] [ INFO: possible recursive locking detected ]
[ 30.490727] 2.6.33-rc8-wl-64012-g6917413 #160
[ 30.490744] ---------------------------------------------
[ 30.490763] powernowd/2577 is trying to acquire lock:
[ 30.490782] (s_active){++++.+}, at: [<c0000000001efa94>] .sysfs_addrm_finish+0x58/0xc0
[ 30.490831]
[ 30.490833] but task is already holding lock:
[ 30.490854] (s_active){++++.+}, at: [<c0000000001eff80>] .sysfs_get_active_two+0x3c/0x84
[ 30.490895]
[ 30.490896] other info that might help us debug this:
[ 30.490921] 4 locks held by powernowd/2577:
[ 30.490936] #0: (&buffer->mutex){+.+.+.}, at: [<c0000000001ed8d0>] .sysfs_write_file+0x60/0x1a4
[ 30.490983] #1: (s_active){++++.+}, at: [<c0000000001eff80>] .sysfs_get_active_two+0x3c/0x84
[ 30.491028] #2: (s_active){++++.+}, at: [<c0000000001eff98>] .sysfs_get_active_two+0x54/0x84
[ 30.491073] #3: (dbs_mutex){+.+.+.}, at: [<d000000002c9c6e8>] .cpufreq_governor_dbs+0x424/0x548 [cpufreq_ondemand]
[ 30.491128]
[ 30.491130] stack backtrace:
[ 30.491148] Call Trace:
[ 30.491166] [c00000021251af10] [c000000000012934] .show_stack+0xc0/0x200 (unreliable)
[ 30.491205] [c00000021251afe0] [c0000000005a74b0] .dump_stack+0x28/0x3c
[ 30.491234] [c00000021251b060] [c0000000000b88c8] .validate_chain+0x758/0x1044
[ 30.491265] [c00000021251b1a0] [c0000000000b9b94] .__lock_acquire+0x9e0/0xac4
[ 30.491294] [c00000021251b2d0] [c0000000000b9dc8] .lock_acquire+0x150/0x19c
[ 30.491324] [c00000021251b3a0] [c0000000001eeeb8] .sysfs_deactivate+0xd0/0x16c
[ 30.491354] [c00000021251b4f0] [c0000000001efa94] .sysfs_addrm_finish+0x58/0xc0
[ 30.491385] [c00000021251b590] [c0000000001ecb98] .sysfs_hash_and_remove+0x7c/0xb0
[ 30.491416] [c00000021251b640] [c0000000001f1710] .sysfs_remove_group+0xb4/0x138
[ 30.491450] [c00000021251b6e0] [d000000002c9c6f8] .cpufreq_governor_dbs+0x434/0x548 [cpufreq_ondemand]
[ 30.491487] [c00000021251b7e0] [c0000000004cc3e4] .__cpufreq_governor+0x1cc/0x250
[ 30.491520] [c00000021251b890] [c0000000004cdb90] .__cpufreq_set_policy+0x1f8/0x2a8
[ 30.491552] [c00000021251b940] [c0000000004ce1a0] .store_scaling_governor+0x1c0/0x21c
[ 30.491584] [c00000021251bb50] [c0000000004cd954] .store+0x98/0xdc
[ 30.491611] [c00000021251bc00] [c0000000001ed9a4] .sysfs_write_file+0x134/0x1a4
[ 30.491644] [c00000021251bcc0] [c000000000176ca0] .vfs_write+0xe8/0x1fc
[ 30.491672] [c00000021251bd70] [c000000000176ef0] .SyS_write+0x68/0xb0
[ 30.491700] [c00000021251be30] [c0000000000075d4] syscall_exit+0x0/0x40
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Américo Wang
<joha...@sipsolutions.net> wrote:
> Get this when powernowd starts on my G5:
>
> [ 30.490674] =============================================
> [ 30.490708] [ INFO: possible recursive locking detected ]
> [ 30.490727] 2.6.33-rc8-wl-64012-g6917413 #160
> [ 30.490744] ---------------------------------------------
> [ 30.490763] powernowd/2577 is trying to acquire lock:
> [ 30.490782] (s_active){++++.+}, at: [<c0000000001efa94>] .sysfs_addrm_finish+0x58/0xc0
> [ 30.490831]
> [ 30.490833] but task is already holding lock:
> [ 30.490854] (s_active){++++.+}, at: [<c0000000001eff80>] .sysfs_get_active_two+0x3c/0x84
> [ 30.490895]
This should be fixed by the patchset from Eric:
http://lkml.org/lkml/2010/2/11/334
Johannes Berg
> This should be fixed by the patchset from Eric:
>
> http://lkml.org/lkml/2010/2/11/334
That patchset doesn't even compile.
johannes
---
drivers/pci/pci-sysfs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- wireless-testing.orig/drivers/pci/pci-sysfs.c 2010-02-20 12:12:28.207979616 +0100
+++ wireless-testing/drivers/pci/pci-sysfs.c 2010-02-20 12:12:54.588603464 +0100
@@ -642,7 +642,7 @@ void pci_create_legacy_files(struct pci_
if (!b->legacy_io)
goto kzalloc_err;
- sysfs_bin_attr_init(&b->legacy_io);
+ sysfs_bin_attr_init(b->legacy_io);
b->legacy_io->attr.name = "legacy_io";
b->legacy_io->size = 0xffff;
b->legacy_io->attr.mode = S_IRUSR | S_IWUSR;
@@ -655,8 +655,8 @@ void pci_create_legacy_files(struct pci_
goto legacy_io_err;
/* Allocated above after the legacy_io struct */
- sysfs_bin_attr_init(&b->legacy_mem);
b->legacy_mem = b->legacy_io + 1;
+ sysfs_bin_attr_init(b->legacy_mem);
b->legacy_mem->attr.name = "legacy_mem";
b->legacy_mem->size = 1024*1024;
b->legacy_mem->attr.mode = S_IRUSR | S_IWUSR;
Johannes Berg
> <joha...@sipsolutions.net> wrote:
> > Get this when powernowd starts on my G5:
> >
> > [ 30.490674] =============================================
> > [ 30.490708] [ INFO: possible recursive locking detected ]
> > [ 30.490727] 2.6.33-rc8-wl-64012-g6917413 #160
> > [ 30.490744] ---------------------------------------------
> > [ 30.490763] powernowd/2577 is trying to acquire lock:
> > [ 30.490782] (s_active){++++.+}, at: [<c0000000001efa94>]
> .sysfs_addrm_finish+0x58/0xc0
> > [ 30.490831]
> > [ 30.490833] but task is already holding lock:
> > [ 30.490854] (s_active){++++.+}, at: [<c0000000001eff80>]
> .sysfs_get_active_two+0x3c/0x84
> > [ 30.490895]
>
> This should be fixed by the patchset from Eric:
>
> http://lkml.org/lkml/2010/2/11/334
Oh wow, well ..... I get like a thousand of these now:
BUG: key c0000002165eb478 not in .data!
instead of the lockdep complaint above.
johannes
Américo Wang
>On Sat, 2010-02-20 at 17:26 +0800, Américo Wang wrote:
>> On Thu, Feb 18, 2010 at 5:32 PM, Johannes Berg
>> <joha...@sipsolutions.net> wrote:
>> > Get this when powernowd starts on my G5:
>> >
>> > [ 30.490674] =============================================
>> > [ 30.490708] [ INFO: possible recursive locking detected ]
>> > [ 30.490727] 2.6.33-rc8-wl-64012-g6917413 #160
>> > [ 30.490744] ---------------------------------------------
>> > [ 30.490763] powernowd/2577 is trying to acquire lock:
>> > [ 30.490782] (s_active){++++.+}, at: [<c0000000001efa94>]
>> .sysfs_addrm_finish+0x58/0xc0
>> > [ 30.490831]
>> > [ 30.490833] but task is already holding lock:
>> > [ 30.490854] (s_active){++++.+}, at: [<c0000000001eff80>]
>> .sysfs_get_active_two+0x3c/0x84
>> > [ 30.490895]
>>
>> This should be fixed by the patchset from Eric:
>>
>> http://lkml.org/lkml/2010/2/11/334
>
>Oh wow, well ..... I get like a thousand of these now:
>
>BUG: key c0000002165eb478 not in .data!
>
>instead of the lockdep complaint above.
>
I am not surprised. :)
Please send us the backtraces you got, we could expect this.
Thank you.
Américo Wang
>On Sat, 2010-02-20 at 17:26 +0800, Américo Wang wrote:
>
>> This should be fixed by the patchset from Eric:
>>
>> http://lkml.org/lkml/2010/2/11/334
>
>That patchset doesn't even compile.
>
Wow. I didn't notice that.
Eric, could you fix your last patch? I mean your patch 4/4, probably.
Greg?
>johannes
>
>---
> drivers/pci/pci-sysfs.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
>--- wireless-testing.orig/drivers/pci/pci-sysfs.c 2010-02-20 12:12:28.207979616 +0100
>+++ wireless-testing/drivers/pci/pci-sysfs.c 2010-02-20 12:12:54.588603464 +0100
>@@ -642,7 +642,7 @@ void pci_create_legacy_files(struct pci_
> if (!b->legacy_io)
> goto kzalloc_err;
>
>- sysfs_bin_attr_init(&b->legacy_io);
>+ sysfs_bin_attr_init(b->legacy_io);
> b->legacy_io->attr.name = "legacy_io";
> b->legacy_io->size = 0xffff;
> b->legacy_io->attr.mode = S_IRUSR | S_IWUSR;
>@@ -655,8 +655,8 @@ void pci_create_legacy_files(struct pci_
> goto legacy_io_err;
>
> /* Allocated above after the legacy_io struct */
>- sysfs_bin_attr_init(&b->legacy_mem);
> b->legacy_mem = b->legacy_io + 1;
>+ sysfs_bin_attr_init(b->legacy_mem);
> b->legacy_mem->attr.name = "legacy_mem";
> b->legacy_mem->size = 1024*1024;
> b->legacy_mem->attr.mode = S_IRUSR | S_IWUSR;
>
>
--
Live like a child, think like the god.
Johannes Berg
> >BUG: key c0000002165eb478 not in .data!
> >
> >instead of the lockdep complaint above.
> >
>
> I am not surprised. :)
>
> Please send us the backtraces you got, we could expect this.
I hacked in dump_stack() but it overflowed my log buffer, here's an example:
[ 31.625411] BUG: key c0000002134f2ab0 not in .data!
[ 31.625414] Call Trace:
[ 31.625417] [c000000213b677c0] [c000000000012c1c] .show_stack+0xc0/0x200 (unreliable)
[ 31.625423] [c000000213b67890] [c0000000005ac968] .dump_stack+0x28/0x3c
[ 31.625428] [c000000213b67910] [c0000000000b6a3c] .lockdep_init_map+0x11c/0x674
[ 31.625433] [c000000213b67a10] [c0000000001efd90] .sysfs_add_file_mode+0x90/0x124
[ 31.625438] [c000000213b67ad0] [c0000000001efe60] .sysfs_add_file+0x3c/0x50
[ 31.625442] [c000000213b67b70] [c0000000001f2f40] .sysfs_create_bin_file+0x5c/0x78
[ 31.625448] [c000000213b67c10] [c0000000000cd0b0] .load_module+0x16a4/0x197c
[ 31.625452] [c000000213b67d80] [c0000000000cd424] .SyS_init_module+0x9c/0x2d4
[ 31.625457] [c000000213b67e30] [c0000000000075d4] syscall_exit+0x0/0x40
There's also
[ 34.776604] BUG: key c000000216265388 not in .data!
[ 34.776606] Call Trace:
[ 34.776609] [c000000213b5f7a0] [c000000000012c1c] .show_stack+0xc0/0x200 (unreliable)
[ 34.776615] [c000000213b5f870] [c0000000005ac968] .dump_stack+0x28/0x3c
[ 34.776620] [c000000213b5f8f0] [c0000000000b6a3c] .lockdep_init_map+0x11c/0x674
[ 34.776624] [c000000213b5f9f0] [c0000000001efd90] .sysfs_add_file_mode+0x90/0x124
[ 34.776629] [c000000213b5fab0] [c0000000001f32b4] .internal_create_group+0x168/0x24c
[ 34.776634] [c000000213b5fb70] [c0000000001f3420] .sysfs_create_group+0x38/0x50
[ 34.776639] [c000000213b5fc10] [c0000000000ccf20] .load_module+0x1514/0x197c
[ 34.776644] [c000000213b5fd80] [c0000000000cd424] .SyS_init_module+0x9c/0x2d4
[ 34.776649] [c000000213b5fe30] [c0000000000075d4] syscall_exit+0x0/0x40
and many many times...
Let me recompile with that dump_stack() removed.
johannes
Johannes Berg
> > /* Allocated above after the legacy_io struct */
> >- sysfs_bin_attr_init(&b->legacy_mem);
> > b->legacy_mem = b->legacy_io + 1;
> >+ sysfs_bin_attr_init(b->legacy_mem);
Also note the reordering to make it not crash ...
johannes
Johannes Berg
> Please send us the backtraces you got, we could expect this.
The first one is fun:
[ 1.576226] windfarm: initializing for dual-core desktop G5
[ 1.577182] BUG: key 6b6b6b6b6b6b6b6b not in .data!
[ 1.577190] ------------[ cut here ]------------
[ 1.577192] Badness at kernel/lockdep.c:2706
[ 1.577196] NIP: c0000000000b6a68 LR: c0000000000b6a4c CTR: c0000000003afedc
[ 1.577200] REGS: c000000216197620 TRAP: 0700 Not tainted (2.6.33-rc8-wl-64022-gcdee415-dirty)
[ 1.577203] MSR: 9000000000029032 <EE,ME,CE,IR,DR> CR: 28000082 XER: 200fffff
[ 1.577214] TASK = c000000216198000[1] 'swapper' THREAD: c000000216194000 CPU: 2
[ 1.577217] GPR00: 0000000000000000 c0000002161978a0 c000000000b10328 0000000000000001
[ 1.577223] GPR04: 0000000000000001 c000000000071638 0000000000000000 0000000000000002
[ 1.577229] GPR08: 0000000000000000 c0000000014320f0 0000000000000001 c000000000b27638
[ 1.577235] GPR12: 0000000000000041 c000000000b21880 0000000000000056 0000000001400000
[ 1.577241] GPR16: 0000000000240ee0 c000000000718923 c0000000007ff6ec 000000000000005e
[ 1.577247] GPR20: 00000000ffb30f40 c0000000007188b9 0000000000000000 0000000000240ed0
[ 1.577253] GPR24: 0000000000000108 0000000000000000 fffffffffffffff4 c00000021488b000
[ 1.577259] GPR28: 6b6b6b6b6b6b6b6b c00000021488bcc8 c000000000a77780 c0000002161978a0
[ 1.577271] NIP [c0000000000b6a68] .lockdep_init_map+0x148/0x66c
[ 1.577276] LR [c0000000000b6a4c] .lockdep_init_map+0x12c/0x66c
[ 1.577278] Call Trace:
[ 1.577282] [c0000002161978a0] [c0000000000b6a34] .lockdep_init_map+0x114/0x66c (unreliable)
[ 1.577289] [c0000002161979a0] [c0000000001efd88] .sysfs_add_file_mode+0x90/0x124
[ 1.577294] [c000000216197a60] [c0000000001efe58] .sysfs_add_file+0x3c/0x50
[ 1.577299] [c000000216197b00] [c0000000001effb4] .sysfs_create_file+0x5c/0x74
[ 1.577305] [c000000216197ba0] [c0000000004292b0] .device_create_file+0x40/0x5c
[ 1.577311] [c000000216197c40] [c000000000441178] .wf_register_control+0x108/0x178
[ 1.577316] [c000000216197cf0] [c0000000004440a4] .smu_fan_create+0x548/0x598
[ 1.577323] [c000000216197da0] [c0000000007e5e6c] .smu_controls_init+0xb0/0x1f4
[ 1.577329] [c000000216197e40] [c0000000000084e4] .do_one_initcall+0xac/0x204
[ 1.577335] [c000000216197ef0] [c0000000007b84b8] .kernel_init+0x1f0/0x270
[ 1.577340] [c000000216197f90] [c000000000028f8c] .kernel_thread+0x54/0x70
[ 1.577343] Instruction dump:
[ 1.577346] e93e81c8 80090000 2f800000 409e04f4 482fa5e9 60000000 2fa30000 419e04e4
[ 1.577355] e93e81d0 80090000 2f800000 409e04d4 <0fe00000> 480004cc fb9d0000 e93e8018
[ 1.577375] BUG: key 6b6b6b6b6b6b6b6b not in .data!
[ 1.577385] BUG: key 6b6b6b6b6b6b6b6b not in .data!
[ 1.577397] BUG: key 6b6b6b6b6b6b6b6b not in .data!
[ 1.577413] BUG: key 6b6b6b6b6b6b6b6b not in .data!
[ 1.577423] BUG: key 6b6b6b6b6b6b6b6b not in .data!
[ 1.577435] BUG: key 6b6b6b6b6b6b6b6b not in .data!
[ 1.577446] BUG: key 6b6b6b6b6b6b6b6b not in .data!
[ 1.839465] BUG: key 6b6b6b6b6b6b6b6b not in .data!
key pointing to something freed? wtf?
johannes
Johannes Berg
> fct->fan_type = pwm_fan;
> fct->ctrl.type = pwm_fan ? WF_CONTROL_PWM_FAN : WF_CONTROL_RPM_FAN;
> + sysfs_attr_init(&fct->ctrl.attr);
ah, needs to be "ctrl.attr.attr".
Américo Wang
This should be fixed by the following patch, it is based on the
4 patches from Eric.
Thanks.
Reported-by: Johannes Berg <joha...@sipsolutions.net>
Signed-off-by: WANG Cong <xiyou.w...@gmail.com>
---
diff --git a/drivers/macintosh/windfarm_smu_controls.c b/drivers/macintosh/windfarm_smu_controls.c
index 6c68b9e..5f4e5a0 100644
--- a/drivers/macintosh/windfarm_smu_controls.c
+++ b/drivers/macintosh/windfarm_smu_controls.c
@@ -173,6 +173,7 @@ static struct smu_fan_control *smu_fan_create(struct device_node *node,
fct->fan_type = pwm_fan;
fct->ctrl.type = pwm_fan ? WF_CONTROL_PWM_FAN : WF_CONTROL_RPM_FAN;
+ sysfs_attr_init(&fct->ctrl.attr);
/* We use the name & location here the same way we do for SMU sensors,
* see the comment in windfarm_smu_sensors.c. The locations are a bit
Johannes Berg
> +++ b/drivers/macintosh/windfarm_smu_controls.c
> @@ -173,6 +173,7 @@ static struct smu_fan_control
> *smu_fan_create(struct device_node *node,
>
> fct->fan_type = pwm_fan;
> fct->ctrl.type = pwm_fan ? WF_CONTROL_PWM_FAN : WF_CONTROL_RPM_FAN;
> + sysfs_attr_init(&fct->ctrl.attr);
hmm.
drivers/macintosh/windfarm_smu_controls.c: In function ‘smu_fan_create’:
drivers/macintosh/windfarm_smu_controls.c:176: error: ‘struct device_attribute’ has no member named ‘key’
johannes
Américo Wang
>On Sat, 2010-02-20 at 23:03 +0800, Américo Wang wrote:
>
>> fct->fan_type = pwm_fan;
>> fct->ctrl.type = pwm_fan ? WF_CONTROL_PWM_FAN : WF_CONTROL_RPM_FAN;
>> + sysfs_attr_init(&fct->ctrl.attr);
>
>ah, needs to be "ctrl.attr.attr".
>
Ouch, right... Updated.
Thank you!
---
diff --git a/drivers/macintosh/windfarm_smu_controls.c b/drivers/macintosh/windfarm_smu_controls.c
index 6c68b9e..5f4e5a0 100644
--- a/drivers/macintosh/windfarm_smu_controls.c
+++ b/drivers/macintosh/windfarm_smu_controls.c
@@ -173,6 +173,7 @@ static struct smu_fan_control *smu_fan_create(struct device_node *node,
fct->fan_type = pwm_fan;
fct->ctrl.type = pwm_fan ? WF_CONTROL_PWM_FAN : WF_CONTROL_RPM_FAN;
+ sysfs_attr_init(&fct->ctrl.attr.attr);
/* We use the name & location here the same way we do for SMU sensors,
* see the comment in windfarm_smu_sensors.c. The locations are a bit
Johannes Berg
> This should be fixed by the following patch, it is based on the
> 4 patches from Eric.
Thanks, one down.
[ 1.556276] windfarm: initializing for dual-core desktop G5
[ 1.822554] BUG: key 6b6b6b6b6b6b6b6b not in .data!
[ 1.827044] ------------[ cut here ]------------
[ 1.831498] Badness at kernel/lockdep.c:2706
[ 1.836013] NIP: c0000000000b6a3c LR: c0000000000b6a20 CTR: 0000000000000000
[ 1.840721] REGS: c0000002161976a0 TRAP: 0700 Not tainted (2.6.33-rc8-00140-g4ec62b2-dirty)
[ 1.845620] MSR: 9000000000029032 <EE,ME,CE,IR,DR> CR: 24000022 XER: 000fffff
[ 1.850679] TASK = c000000216198000[1] 'swapper' THREAD: c000000216194000 CPU: 1
[ 1.850884] GPR00: 0000000000000000 c000000216197920 c000000000b10328 0000000000000001
[ 1.856050] GPR04: 0000000000000001 c000000000070d0c 0000000000000000 0000000000000002
[ 1.861327] GPR08: 0000000000000000 c0000000014320f0 0000000000000001 c000000000b27638
[ 1.866640] GPR12: 0000000024000044 c000000000b21680 0000000000000056 0000000001400000
[ 1.871978] GPR16: 0000000000240ee0 c000000000718923 c0000000007ff6ec 000000000000005e
[ 1.877351] GPR20: c0000000007e6118 c000000002b74a58 c000000216194080 c000000002b74a70
[ 1.882770] GPR24: 0000000000000000 0000000000000000 fffffffffffffff4 c00000021643ee40
[ 1.888249] GPR28: 6b6b6b6b6b6b6b6b c00000021644b188 c000000000a77780 c000000216197920
[ 1.899228] NIP [c0000000000b6a3c] .lockdep_init_map+0x148/0x66c
[ 1.904944] LR [c0000000000b6a20] .lockdep_init_map+0x12c/0x66c
[ 1.910740] Call Trace:
[ 1.916549] [c000000216197920] [c0000000000b6a08] .lockdep_init_map+0x114/0x66c (unreliable)
[ 1.922686] [c000000216197a20] [c0000000001efd58] .sysfs_add_file_mode+0x90/0x124
[ 1.928883] [c000000216197ae0] [c0000000001efe28] .sysfs_add_file+0x3c/0x50
[ 1.935088] [c000000216197b80] [c0000000001eff84] .sysfs_create_file+0x5c/0x74
[ 1.941348] [c000000216197c20] [c000000000429284] .device_create_file+0x40/0x5c
[ 1.941356] [c000000216197cc0] [c000000000440fec] .wf_register_sensor+0x108/0x178
[ 1.941363] [c000000216197d70] [c0000000007e6368] .smu_sensors_init+0x3b8/0x690
[ 1.941369] [c000000216197e40] [c0000000000084e4] .do_one_initcall+0xac/0x204
[ 1.941374] [c000000216197ef0] [c0000000007b84b8] .kernel_init+0x1f0/0x270
[ 1.941380] [c000000216197f90] [c000000000028f8c] .kernel_thread+0x54/0x70
[ 1.941383] Instruction dump:
[ 1.941385] e93e81c8 80090000 2f800000 409e04f4 482fa5e5 60000000 2fa30000 419e04e4
[ 1.941395] e93e81d0 80090000 2f800000 409e04d4 <0fe00000> 480004cc fb9d0000 e93e8018
I think I get the point ... I'll go through myself.
johannes
Américo Wang
Thanks!
This could be fixed by the following.
Reported-by: Johannes Berg <joha...@sipsolutions.net>
Signed-off-by: WANG Cong <xiyou.w...@gmail.com>
---
diff --git a/kernel/module.c b/kernel/module.c
index f82386b..fa4d562 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -1085,6 +1085,7 @@ static void add_sect_attrs(struct module *mod, unsigned int nsect,
sect_attrs->nsections++;
sattr->mattr.show = module_sect_show;
sattr->mattr.store = NULL;
+ sysfs_attr_init(&sattr->mattr.attr);
sattr->mattr.attr.name = sattr->name;
sattr->mattr.attr.mode = S_IRUGO;
*(gattr++) = &(sattr++)->mattr.attr;
@@ -1178,6 +1179,7 @@ static void add_notes_attrs(struct module *mod, unsigned int nsect,
if (sect_empty(&sechdrs[i]))
continue;
if (sechdrs[i].sh_type == SHT_NOTE) {
+ sysfs_bin_attr_init(nattr);
nattr->attr.name = mod->sect_attrs->attrs[loaded].name;
nattr->attr.mode = S_IRUGO;
nattr->size = sechdrs[i].sh_size;
Johannes Berg
> On Sat, Feb 20, 2010 at 04:08:16PM +0100, Johannes Berg wrote:
> >On Sat, 2010-02-20 at 23:03 +0800, Américo Wang wrote:
> >
> >> fct->fan_type = pwm_fan;
> >> fct->ctrl.type = pwm_fan ? WF_CONTROL_PWM_FAN :
> WF_CONTROL_RPM_FAN;
> >> + sysfs_attr_init(&fct->ctrl.attr);
> >
> >ah, needs to be "ctrl.attr.attr".
> >
>
> Ouch, right... Updated.
I have this now, and that removed all the warnings:
---
drivers/macintosh/windfarm_core.c | 1 +
drivers/macintosh/windfarm_smu_controls.c | 1 +
kernel/module.c | 3 +++
3 files changed, 5 insertions(+)
--- wireless-testing.orig/drivers/macintosh/windfarm_smu_controls.c 2010-02-20 16:05:55.738721565 +0100
+++ wireless-testing/drivers/macintosh/windfarm_smu_controls.c 2010-02-20 16:07:51.996717974 +0100
@@ -173,6 +173,7 @@ static struct smu_fan_control *smu_fan_c
fct->fan_type = pwm_fan;
fct->ctrl.type = pwm_fan ? WF_CONTROL_PWM_FAN : WF_CONTROL_RPM_FAN;
+ sysfs_attr_init(&fct->ctrl.attr.attr);
/* We use the name & location here the same way we do for SMU sensors,
* see the comment in windfarm_smu_sensors.c. The locations are a bit
--- wireless-testing.orig/drivers/macintosh/windfarm_core.c 2010-02-20 16:15:14.701580166 +0100
+++ wireless-testing/drivers/macintosh/windfarm_core.c 2010-02-20 16:15:38.416369684 +0100
@@ -321,6 +321,7 @@ int wf_register_sensor(struct wf_sensor
kref_init(&new_sr->ref);
list_add(&new_sr->link, &wf_sensors);
+ sysfs_attr_init(&new_sr->attr.attr);
new_sr->attr.attr.name = new_sr->name;
new_sr->attr.attr.mode = 0444;
new_sr->attr.show = wf_show_sensor;
--- wireless-testing.orig/kernel/module.c 2010-02-20 16:16:52.740706797 +0100
+++ wireless-testing/kernel/module.c 2010-02-20 16:22:52.499698256 +0100
@@ -1085,6 +1085,7 @@ static void add_sect_attrs(struct module
sect_attrs->nsections++;
sattr->mattr.show = module_sect_show;
sattr->mattr.store = NULL;
+ sysfs_attr_init(&sattr->mattr.attr);
sattr->mattr.attr.name = sattr->name;
sattr->mattr.attr.mode = S_IRUGO;
*(gattr++) = &(sattr++)->mattr.attr;
@@ -1178,6 +1179,7 @@ static void add_notes_attrs(struct modul
if (sect_empty(&sechdrs[i]))
continue;
if (sechdrs[i].sh_type == SHT_NOTE) {
+ sysfs_bin_attr_init(nattr);
nattr->attr.name = mod->sect_attrs->attrs[loaded].name;
nattr->attr.mode = S_IRUGO;
nattr->size = sechdrs[i].sh_size;
@@ -1250,6 +1252,7 @@ int module_add_modinfo_attrs(struct modu
if (!attr->test ||
(attr->test && attr->test(mod))) {
memcpy(temp_attr, attr, sizeof(*temp_attr));
+ sysfs_attr_init(&temp_attr->attr);
error = sysfs_create_file(&mod->mkobj.kobj,&temp_attr->attr);
++temp_attr;
}
johannes
Américo Wang
Thank you!
For this case, you could add sysfs_attr_init() in wf_register_sensor().
Johannes Berg
> I have this now, and that removed all the warnings:
But I still don't get anything back wrt. the original problem ... still
hangs after printing "disabling non-boot CPUs"
:(
Américo Wang
>On Sat, 2010-02-20 at 23:20 +0800, Américo Wang wrote:
>> On Sat, Feb 20, 2010 at 04:08:16PM +0100, Johannes Berg wrote:
>> >On Sat, 2010-02-20 at 23:03 +0800, Américo Wang wrote:
>> >
>> >> fct->fan_type = pwm_fan;
>> >> fct->ctrl.type = pwm_fan ? WF_CONTROL_PWM_FAN :
>> WF_CONTROL_RPM_FAN;
>> >> + sysfs_attr_init(&fct->ctrl.attr);
>> >
>> >ah, needs to be "ctrl.attr.attr".
>> >
>>
>> Ouch, right... Updated.
>
>I have this now, and that removed all the warnings:
>
Excellent!
You can send this as a normal patch to Erich and Greg, with me Cc'ed. :)
Thanks much!
--
Live like a child, think like the god.
Johannes Berg
Signed-off-by: Johannes Berg <joha...@sipsolutions.net>
---
drivers/macintosh/windfarm_core.c | 1 +
drivers/macintosh/windfarm_smu_controls.c | 1 +
--- wireless-testing.orig/drivers/macintosh/windfarm_smu_controls.c 2010-02-20 16:05:55.738721565 +0100
+++ wireless-testing/drivers/macintosh/windfarm_smu_controls.c 2010-02-20 16:07:51.996717974 +0100
@@ -173,6 +173,7 @@ static struct smu_fan_control *smu_fan_c
fct->fan_type = pwm_fan;
fct->ctrl.type = pwm_fan ? WF_CONTROL_PWM_FAN : WF_CONTROL_RPM_FAN;
+ sysfs_attr_init(&fct->ctrl.attr.attr);
/* We use the name & location here the same way we do for SMU sensors,
* see the comment in windfarm_smu_sensors.c. The locations are a bit
--- wireless-testing.orig/drivers/macintosh/windfarm_core.c 2010-02-20 16:15:14.701580166 +0100
+++ wireless-testing/drivers/macintosh/windfarm_core.c 2010-02-20 16:15:38.416369684 +0100
@@ -321,6 +321,7 @@ int wf_register_sensor(struct wf_sensor
kref_init(&new_sr->ref);
list_add(&new_sr->link, &wf_sensors);
+ sysfs_attr_init(&new_sr->attr.attr);
new_sr->attr.attr.name = new_sr->name;
new_sr->attr.attr.mode = 0444;
new_sr->attr.show = wf_show_sensor;
Américo Wang
>On Sat, 2010-02-20 at 16:28 +0100, Johannes Berg wrote:
>
>> I have this now, and that removed all the warnings:
>
>But I still don't get anything back wrt. the original problem ... still
>hangs after printing "disabling non-boot CPUs"
>
Odd, it seems we still have some problem... maybe my quick patch is
broken, I will check it tomorrow, it's mid-night here. :)
Thanks.
Johannes Berg
Signed-off-by: Johannes Berg <joha...@sipsolutions.net>
---
kernel/module.c | 3 +++
Johannes Berg
> On Sat, Feb 20, 2010 at 04:31:23PM +0100, Johannes Berg wrote:
> >On Sat, 2010-02-20 at 16:28 +0100, Johannes Berg wrote:
> >
> >> I have this now, and that removed all the warnings:
> >
> >But I still don't get anything back wrt. the original problem ...
> still
> >hangs after printing "disabling non-boot CPUs"
> >
>
> Odd, it seems we still have some problem... maybe my quick patch is
> broken, I will check it tomorrow, it's mid-night here. :)
Oi! Thanks for all your help so far.
johannes
Benjamin Herrenschmidt
> This is required for lockdep.
Please CC linuxp...@ozlabs.org or it doesn't get caught by patchwork.
I'll fwd that one myself.
Cheers,
Ben.
Américo Wang
<joha...@sipsolutions.net> wrote:
> On Wed, 2010-02-24 at 13:49 +1100, Benjamin Herrenschmidt wrote:
>> On Sat, 2010-02-20 at 16:43 +0100, Johannes Berg wrote:
>> > This is required for lockdep.
>>
>> Please CC linuxp...@ozlabs.org or it doesn't get caught by
>> patchwork.
>
>
Yeah, that's why we are Cc'ing Greg, since he took Eric's patches already.
Greg?
Johannes Berg
> > This is required for lockdep.
>
> Please CC linuxp...@ozlabs.org or it doesn't get caught by
> patchwork.
Eh, sure, but I think it needs to be part of Eric's series?
> I'll fwd that one myself.
Thanks.
johannes
Johannes Berg
johannes
Greg KH
> On Wed, Feb 24, 2010 at 3:32 PM, Johannes Berg
> <joha...@sipsolutions.net> wrote:
> > On Wed, 2010-02-24 at 13:49 +1100, Benjamin Herrenschmidt wrote:
> >> On Sat, 2010-02-20 at 16:43 +0100, Johannes Berg wrote:
> >> > This is required for lockdep.
> >>
> >> Please CC linuxp...@ozlabs.org or it doesn't get caught by
> >> patchwork.
> >
> > Eh, sure, but I think it needs to be part of Eric's series?
> >
>
> Yeah, that's why we are Cc'ing Greg, since he took Eric's patches already.
>
> Greg?
I didn't take all of them yet, that will happen later today, and I'll
also queue this up, as it is then required.
thanks,
greg k-h
Américo Wang
<joha...@sipsolutions.net> wrote:
> Btw, request_firmware also needs annotation.
>
Oh, mind to send a patch for it? ;)
Américo Wang
> On Wed, Feb 24, 2010 at 03:34:52PM +0800, Am??rico Wang wrote:
>> On Wed, Feb 24, 2010 at 3:32 PM, Johannes Berg
>> <joha...@sipsolutions.net> wrote:
>> > On Wed, 2010-02-24 at 13:49 +1100, Benjamin Herrenschmidt wrote:
>> >> On Sat, 2010-02-20 at 16:43 +0100, Johannes Berg wrote:
>> >> > This is required for lockdep.
>> >>
>> >> Please CC linuxp...@ozlabs.org or it doesn't get caught by
>> >> patchwork.
>> >
>> > Eh, sure, but I think it needs to be part of Eric's series?
>> >
>>
>> Yeah, that's why we are Cc'ing Greg, since he took Eric's patches already.
>>
>> Greg?
>
> I didn't take all of them yet, that will happen later today, and I'll
> also queue this up, as it is then required.
Thanks, also this one:
http://lkml.org/lkml/2010/2/20/119
Johannes Berg
> Oh, mind to send a patch for it? ;)
I was going to, but can't now ... just returned from ski trip yesterday
and will be travelling again in less than 24 hours.
johannes