spinlocks dont work

spinlocks dont work

[RANDAZZO]

On my uniprocessor system, I have two LKM's

driver1 takes hold of the spinlock....but does not release it...
driver2 attempts to take hold, and is allowed!!!!

how come spin locks don't work?????

how can I restrict access (to hardware) to only one driver at a time???

should I use semaphores,  etc...


 
"This message may contain company proprietary information. If you are not
the intended recipient, any disclosure, copying, distribution or reliance on
the contents of this message is prohibited. If you received this message in
error, please delete and notify me."

Re: spinlocks dont work

[Richard B. Johnson]

On Fri, 13 Feb 2004 RANDAZZO@ddc-web.com wrote:

> On my uniprocessor system, I have two LKM's
>
> driver1 takes hold of the spinlock....but does not release it...
> driver2 attempts to take hold, and is allowed!!!!
> how come spin locks don't work?????
> how can I restrict access (to hardware) to only one driver at a time???
> should I use semaphores,  etc...
>

Spin-locks do work. However, you need to use the same lock-object
for each execution path. A common error is to do:

static spinlock_t device_lock;

... in one file, and...

static spinlock_t device_lock;

... in another...

There is also a possibility that the kernel you are using does not
impliment spin-locks if it's not compiled for SMP. To make sure,
compile your uniprocessor machine for SMP.

Basically, you use semaphores when the particular execution path
can sleep, and spin-locks when they can't. You can never sleep
in an ISR, so you need to use spin-lock protection where something
could change as a result of an interrupt.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.24 on an i686 machine (797.90 BogoMips).
            Note 96.31% of all statistics are fiction.

Re: spinlocks dont work

[Joe Thornber]

On Fri, Feb 13, 2004 at 11:27:23AM -0500, RANDAZZO@ddc-web.com wrote:
> On my uniprocessor system, I have two LKM's

Read this:

http://www.kernel.org/pub/linux/kernel/people/rusty/kernel-locking/index.html

- Joe

Re: spinlocks dont work

[Rik van Riel]

On Fri, 13 Feb 2004 RANDAZZO@ddc-web.com wrote:

> On my uniprocessor system, I have two LKM's
        ^^^^^^^^^^^^

> how come spin locks don't work?????

The spinlock code is compiled to NOPs on uniprocessor
systems.  That is ok because the second driver cannot
run while the first driver is holding the lock.

You cannot reschedule while holding a spinlock.

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

Re: spinlocks dont work

[Jamie Lokier]

RANDAZZO@ddc-web.com wrote:
> On my uniprocessor system, I have two LKM's
>
> driver1 takes hold of the spinlock....but does not release it...
> driver2 attempts to take hold, and is allowed!!!!

How does driver2 run when driver1 holds the spinlock?  It is not
possible: driver1 is running, and you only have one CPU.

It is an error if you call schedule() while holding a spinlock.  It is
also an error if you call the non-irqsave or non-bh spinlock functions
from a context where an irq or bh could interrupt and take the same lock.

These rules ensure that driver1 and driver2 are prevented from
accessing the hardware at the same time.

> how come spin locks don't work?????

They do, if you use them correctly.

> how can I restrict access (to hardware) to only one driver at a time???

By following the correct rules.
See http://www.kernel.org/pub/linux/kernel/people/rusty/kernel-locking/

> should I use semaphores,  etc...

Are you scheduling while you hold the spinlock?  Then you should use
semaphores instead.  But you cannot use semaphores if you are locking
from any kind of interrupt (this includes timer callbacks and wakeup
functions).

Are you using the spinlock from an interrupt?  This is not normally a
problem because each hardware device normally has just one interrupt source.

Are you using the spinlock from a softirq or whatever they are called
these days, as well as an interrupt?  Then you should be using the
spin_lock_irqsave functions in those cases.

And so on.  You must use the correct type of lock functions.

In a uniprocessor kernel, spinlocks compile to almost no code.
(Someone said they compile to nops; this is not quite accurate).  Even
on a uniprocessor, they disable preemptive scheduling while the lock
is held.  This is completely correct.

-- Jamie