public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Matheus Izvekov <mizvekov@gmail.com>, linux-kernel@vger.kernel.org
Subject: Re: [BUG] parport issue on 2.6.29
Date: Tue, 26 May 2009 18:00:12 -0700	[thread overview]
Message-ID: <m1zlczbbs3.fsf@fess.ebiederm.org> (raw)
In-Reply-To: <20090526165416.9078d218.akpm@linux-foundation.org> (Andrew Morton's message of "Tue\, 26 May 2009 16\:54\:16 -0700")

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

> On Thu, 21 May 2009 17:26:55 -0300
> Matheus Izvekov <mizvekov@gmail.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

      reply	other threads:[~2009-05-27  1:00 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-21 20:26 [BUG] parport issue on 2.6.29 Matheus Izvekov
2009-05-26 23:54 ` Andrew Morton
2009-05-27  1:00   ` Eric W. Biederman [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m1zlczbbs3.fsf@fess.ebiederm.org \
    --to=ebiederm@xmission.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mizvekov@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox