Re: recursive spinlocks. Shoot.

Peter T. Breuer (ptb@it.uc3m.es)
Wed, 21 May 2003 16:16:51 +0200


In article <20030520231013$3d77@gated-at.bofh.it> you wrote:
> From: Richard B. Johnson [mailto:root@chaos.analogic.com]
>> The lock must guarantee that recursion is not allowed. Or to put
>> it more bluntly, the lock must result in a single thread of execution
>> through the locked object.

> Where the HECK do you get that load of bull? The one requirement of a
> MUTUAL EXCLUSION PRIMITIVE (a.k.a. mutex, a.k.a. lock) is *MUTUAL*
> EXCLUSIVITY.

:-) this reminds me of the post I didn't make.

> All else is unfounded blither.

Hey, that was the word I used in the post I didn't make! I'm sort of
glad I didn't say it out loud - it ruins the argument.

Anyhow, I have now written a tool that can detect various improper uses of
locks. I've started out by detecting sleep under spinlock, but I'll go
on to other deadlocks.

% ./c ../dbr/1/sbull..c
<function name=sbull_ioctl file=sbull.c line=171 attr=S_SLEEP>
<function name=sbull_request file=sbull.c line=361 attr=S_SLEEP>
%

Detects two functions in the target file that sleep. For that it had
to analyse 28K lines of C. Put a spinlock in the wrong place and ...

% ./c test16
sleep under spinlock at file="test16" line=30
<function name=sbull_open file=test16 line=1 attr=S_SLEEP>

(I excised a function to fiddle with and put a call to one of the other
two in under a lock).

I'll make this available. As soon as I figure out some more of how
to define C contexts. It uses a database and I'm having trouble
deciding where something is first defined in C.

Peter
-
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/