Re: 2.6.24-rc7 to 2.6.24-rc8 possible regression

[Stefan Richter]

(adding Cc: Davide and akpm)

On 22 Jan, Peter Zijlstra wrote:
> 
> On Tue, 2008-01-22 at 17:23 +0100, Stefan Richter wrote:
>> Denys Fedoryshchenko wrote:
>> > No, i am using vanilla kernel. It is one of production machines, and as i 
>> > know screen is not using epoll.
>> 
>> OK, but the trace shows that it is the epoll recursion again.
>> 
>> > I will try to apply on all my production machines this patch. Sorry if it is 
>> > related.
>> 
>> Well, let's hope that the lockdep annotation or whatever other fix gets
>> into mainline sooner than later.  Which reminds me to test my setup
>> again which appeared to be able to reproduce the __wake_up recursion on
>> my command...
> 
> Would be appreciated, I have been waiting on testing feedback because
> I'm not fully certain here.
> 
> Curious though that this gets reported frequently the last few weeks,
> afaics this problem is way old.

Here is a report against Fedora's 2.6.23-0.222.rc9.git4.fc8, filed in
October:  https://bugzilla.redhat.com/show_bug.cgi?id=323411

I did several tests with a pristine 2.6.24-rc8 now.  The lockdep warning
below is 100% reliably triggered by grabbing video from a DV camcorder
with dvgrab v3 via firewire-core's character device file ABI.

Also, this warning is 100% reliably suppressed by your annotation patch.
I will reply to this message with this patch for kind consideration by
those concerned. :-)


=============================================
[ INFO: possible recursive locking detected ]
2.6.24-rc8 #1
---------------------------------------------
swapper/0 is trying to acquire lock:
 (&q->lock){++..}, at: [<ffffffff8022aef7>] __wake_up+0x22/0x4e

but task is already holding lock:
 (&q->lock){++..}, at: [<ffffffff8022aef7>] __wake_up+0x22/0x4e

other info that might help us debug this:
1 lock held by swapper/0:
 #0:  (&q->lock){++..}, at: [<ffffffff8022aef7>] __wake_up+0x22/0x4e

stack backtrace:
Pid: 0, comm: swapper Not tainted 2.6.24-rc8 #1

Call Trace:
 <IRQ>  [<ffffffff8024ec38>] __lock_acquire+0x1c5/0xc68
 [<ffffffff8024faa1>] lock_acquire+0x51/0x6c
 [<ffffffff8022aef7>] __wake_up+0x22/0x4e
 [<ffffffff8041499b>] _spin_lock_irqsave+0x37/0x47
 [<ffffffff8022aef7>] __wake_up+0x22/0x4e
 [<ffffffff802a926e>] ep_poll_safewake+0x86/0xc5
 [<ffffffff802aa15a>] ep_poll_callback+0xc1/0xcb
 [<ffffffff80228d4d>] __wake_up_common+0x41/0x74
 [<ffffffff8022af0d>] __wake_up+0x38/0x4e
 [<ffffffff8806888c>] :firewire_core:fw_core_handle_request+0x1b0/0x1eb
 [<ffffffff8807301f>] :firewire_ohci:handle_ar_packet+0xfb/0x10f
 [<ffffffff88073f01>] :firewire_ohci:ar_context_tasklet+0xd6/0xe7
 [<ffffffff80236328>] tasklet_action+0x5d/0xb0
 [<ffffffff80236229>] __do_softirq+0x5d/0xe0
 [<ffffffff8021dc2f>] ack_apic_level+0x10/0xdc
 [<ffffffff8020c9fc>] call_softirq+0x1c/0x28
 [<ffffffff8020e839>] do_softirq+0x31/0x94
 [<ffffffff8023616c>] irq_exit+0x45/0x51
 [<ffffffff8020e954>] do_IRQ+0xb8/0xd8
 [<ffffffff8020bcc6>] ret_from_intr+0x0/0xf
 <EOI>  [<ffffffff8021c2da>] lapic_next_event+0x0/0xa
 [<ffffffff8022cde9>] sched_clock_idle_wakeup_event+0x46/0x63
 [<ffffffff8805a746>] :processor:acpi_idle_enter_simple+0x179/0x1df
 [<ffffffff8805a73c>] :processor:acpi_idle_enter_simple+0x16f/0x1df
 [<ffffffff803b4608>] cpuidle_idle_call+0x79/0xad
 [<ffffffff803b458f>] cpuidle_idle_call+0x0/0xad
 [<ffffffff8020a5e4>] cpu_idle+0x95/0xcc
 [<ffffffff80571a8a>] start_kernel+0x2d3/0x2df
 [<ffffffff80571115>] _sinittext+0x115/0x11c



-- 
Stefan Richter
-=====-==--- ---= =-==-
http://arcgraph.de/sr/

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