Messages in this thread | | | Date | Wed, 5 Mar 2003 14:01:34 +0000 | From | Matthew Wilcox <> | Subject | Re: [CHECKER] more potential deadlocks |
| |
> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |