* Steven Rostedt <[email protected]> wrote:
> > proc_subdir_lock can also be used from softirq (tasklet) context, which
> > may lead to deadlocks.
> >
> > This bug was found via the lock validator:
> >
>
> Thanks Ingo,
>
> I stressed in sending the patch that there was a big assumption that
> the calls would not be done in (soft)irq context. I just didn't want
> to add overhead if it wasn't needed. But I guess that this is needed
> until we can remove all the instances that use it in softirq context.
> But that's for a later patch.
the validator just found another problem with this lock, pointing out
that files_lock nests inside of proc_subdir_lock, and that files_lock is
a softirq-unsafe lock, creating another (unlikely but possible) deadlock
scenario:
=====================================
[ BUG: lock inversion bug detected! ]
-------------------------------------
grep/2290 just changed the state of lock {proc_subdir_lock} at:
[<c0196e53>] remove_proc_entry+0x33/0x1f0
but this lock took lock {files_lock} in the past,
acquired at: [<c0196ece>] remove_proc_entry+0xae/0x1f0
and interrupts could create an inverse lock dependency between them,
which could lead to deadlocks!
other info that might help in debugging this:
------------------------------
| showing all locks held by: | (grep/2290 [c321c790, 125]):
------------------------------
[<c010432d>] show_trace+0xd/0x10
[<c0104347>] dump_stack+0x17/0x20
[<c0137b11>] check_no_lock_2_mask+0x131/0x180
[<c0137ffb>] mark_lock+0xfb/0x2a0
[<c01387b3>] debug_lock_chain+0x613/0x10d0
[<c01392ad>] debug_lock_chain_spin+0x3d/0x60
[<c02656ed>] _raw_spin_lock+0x2d/0x90
[<c04d88d2>] _spin_lock_bh+0x12/0x20
[<c0196e53>] remove_proc_entry+0x33/0x1f0
[<c01427c9>] unregister_handler_proc+0x19/0x20
[<c0141f8b>] free_irq+0x7b/0xe0
[<c02f2302>] floppy_release_irq_and_dma+0x1b2/0x210
[<c02f07f7>] set_dor+0xc7/0x1b0
[<c02f3871>] motor_off_callback+0x21/0x30
[<c01273a5>] run_timer_softirq+0xf5/0x1f0
[<c0122cf7>] __do_softirq+0x97/0x130
[<c0105519>] do_softirq+0x69/0x100
=======================
[<c01229a9>] irq_exit+0x39/0x50
[<c010f4cc>] smp_apic_timer_interrupt+0x4c/0x50
[<c010393b>] apic_timer_interrupt+0x27/0x2c
to solve this we must either change files_lock to be softirq-safe too
(bleh!), or we must forbid remove_proc_entry() use from softirq
contexts. Neither is a happy solution - remove_proc_entry() is used
within free_irq(), and who knows how many drivers do free_irq() in
softirq/tasklet context ...
Andrew, this needs to be resolved before v2.6.16, correct? Steve's patch
solves a real bug in the upstream kernel.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
