linux-kernel - Re: [BUG] parport issue on 2.6.29

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <m1zlczbbs3.fsf@fess.ebiederm.org>
Date:	Tue, 26 May 2009 18:00:12 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Matheus Izvekov <mizvekov@...il.com>, linux-kernel@...r.kernel.org
Subject: Re: [BUG] parport issue on 2.6.29

Andrew Morton <akpm@...ux-foundation.org> writes:

> On Thu, 21 May 2009 17:26:55 -0300
> Matheus Izvekov <mizvekov@...il.com> wrote:
>
>> This warning happens whenever a specific parallel port control app is run 
>> without a device attached to it. After the first timeout, the app hangs,
>> and needs SIGKILL to exit.
>> 
>> WARNING: at kernel/sysctl.c:2021 unregister_sysctl_table+0xa3/0x110()
>
> I guess this is
>
> void unregister_sysctl_table(struct ctl_table_header * header)
> {
> 	might_sleep();
>
> 	if (header == NULL)
> 		return;
>
> 	spin_lock(&sysctl_lock);
> 	start_unregistering(header);
> 	if (!--header->parent->count) {
> 		WARN_ON(1);
>
>> Hardware name:         
>> Modules linked in:
>> Pid: 12161, comm: x-killer.exe Not tainted 2.6.29.4 #14
>> Call Trace:
>> [<ffffffff8024c910>] warn_slowpath+0xd0/0x130
>> [<ffffffff80269859>] ? sched_clock_cpu+0xb9/0x190
>> [<ffffffff802484b4>] ? try_to_wake_up+0x174/0x330
>> [<ffffffff80268554>] ? up+0x34/0x50
>> [<ffffffff8024d1cd>] ? release_console_sem+0x1bd/0x210
>> [<ffffffff80aaa4d4>] ? printk+0x67/0x69
>> [<ffffffff80254ec3>] unregister_sysctl_table+0xa3/0x110
>> [<ffffffff806b3128>] parport_device_proc_unregister+0x28/0x40
>> [<ffffffff806b05f5>] parport_unregister_device+0x15/0x180
>> [<ffffffff806a0acc>] pp_release+0xbc/0x1f0
>> [<ffffffff802d3883>] __fput+0xc3/0x1e0
>> [<ffffffff802d39bd>] fput+0x1d/0x30
>> [<ffffffff802d0220>] filp_close+0x50/0x80
>> [<ffffffff8024ec74>] put_files_struct+0x84/0xe0
>> [<ffffffff8024ed1e>] exit_files+0x4e/0x60
>> [<ffffffff80250696>] do_exit+0x196/0x930
>> [<ffffffff80250e6e>] do_group_exit+0x3e/0xb0
>> [<ffffffff8025bda4>] get_signal_to_deliver+0x2a4/0x420
>> [<ffffffff8020b7aa>] do_notify_resume+0xba/0x900
>> [<ffffffff8023c16e>] ? __wake_up+0x4e/0x70
>> [<ffffffff8026c4a9>] ? getnstimeofday+0x59/0xe0
>> [<ffffffff80267a09>] ? ktime_get_ts+0x59/0x60
>> [<ffffffff80274314>] ? compat_sys_futex+0xb4/0x140
>> [<ffffffff8020c8b5>] int_signal+0x12/0x17
>> --[ end trace ff1bd583c825c0c5 ]---
>> pdev0: unregistered pardevice
>
> <looks for explanatory code comments, gets disappointed>
>
> Eric, can you please help decode the reason for this kernel warning?

Looks like fallout from when Al changed the semantics of sysctl.  Requiring
sysctl tables to hang off of empty parent directories.

It looks the parent directory was already been unregistered by the
time we are unregistered.

I'm not current enough on the parport code to have a better clue.

As far as sysctl goes that condition should be essentially harmless, wrong
but harmless.

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/