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

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