Re: [CHECKER] more potential deadlocks

[Matthew Wilcox]

> here are some more potential deadlocks. These results are just for:
>          drivers/pci*
>         drivers/usb*
>         drivers/ide*
>         drivers/scsi*
>         net/*ipv[46]*/netfilter*
>         ipc/*
>         mm/*
>         kernel/*
>         net/*ipv4_*
> 
> if there are any other directories that people are likely to inspect
> bugs from, let me know and I'll add them.

fs/ seems an obvious addition to me.  Could you cc linux-fsdevel on
anything you find in there?  Documentation/filesystems/Locking is not
too inaccurate and might help winnow the wheat from the chaff.

I think we'd benefit from the tty code being audited too --
drivers/char/*tty*

> These deadlocks often involve locks accessed through pointers.
> Unfortunately, if the pointers can never point to the same object the
> error is a false positive.
> 
> BTW, is there a locking ettiquette w.r.t. cli()? E.g., are you not
> supposed to acquire a spinlock if you have interrupts disabled (or
> vice versa)?

enabling/disabling interrupts is also a locking mechnism ;-)  When
you access data from interrupt context, you need to disable interrupts
to avoid that race.  So it's perfectly fine to do:

spin_lock_irq(foo);
spin_lock(bar);
spin_unlock(bar);
spin_unlock_irq(foo);

Also, are you modelling spin_lock_bh() yet?  That has a similar
function to spin_lock_irq() except it only protects against
softirqs/tasklets/timers, not regular interrupts.

-- 
"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk