[lkml]   [2003]   [Mar]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [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 --

> 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:


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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:33    [W:0.048 / U:1.312 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site