inconsistent usage of

inconsistent usage of

[Heiko.Rabe]

I found inconsistent behavoir between SMP oand none SMP kernels using spin
locks inside driver programming
As first an simple example:

static spinlock_t        qtlock               = SPIN_LOCK_UNLOCKED;

void foo()
{
     unsigned long  local_flags;
     spin_lock_irqsave (&qtlock, local_flags);
     spin_lock_irqsave (&qtlock, local_flags);
}

Calling the function foo() works proper in none SMP kernels. I assume, the
spinlocks internaly will be initialized as
recursive semaphore as default. So it is possible to aquire it more than
once by the same thread.

If foo() has been called using a SMP kernel, it freezes the kernel. I
assume that the semaphore object will be initialized as
default to be none recursive. So the semaphore can't aquired a second time
from the same thread.

I found it during investigation of open source ISDN USB external Box
drivers, that is well working in none SMP kernels
but freeze at SMP kernels. Course i have an SMP kernel, i run into the
freeze problem shown above.
The example is only the simple structure about, it's not coded in that way
inside the driver but results in this scenario.
I have fixed the problem at driver to work well at SMP kernels too, but it
seems to be a general issue.

I think, semaphores should be have the same behavoir (default
initialization) at SMP and none SMP kernels. Some code
problems running software at SMP kernels that freeze could be avoided, if
we had a consistent default behavoir of semaphores.

Is the there any reason for this difference i doesn't know ?
Could this be handled in cosistent behavoir handling ?

regards

Heiko Rabe
Senior Developer
InVision Software AG
Tel.: +49-(0)341/497208-12
Fax: +49-(0)2102/728-111
mailto:heiko.rabe@invision.de

Re: inconsistent usage of

[Duncan Sands]

> void foo()
> {
>      unsigned long  local_flags;
>      spin_lock_irqsave (&qtlock, local_flags);
>      spin_lock_irqsave (&qtlock, local_flags);
> }
>
> Calling the function foo() works proper in none SMP kernels. I assume, the
> spinlocks internaly will be initialized as
> recursive semaphore as default. So it is possible to aquire it more than
> once by the same thread.

No.  If you acquire it twice then you die.  The above code is wrong.
Where did you find it?

All the best,

Duncan.

Re: inconsistent usage of

[viro]

On Tue, Apr 22, 2003 at 10:11:11AM +0200, Heiko.Rabe@InVision.de wrote:
> I found inconsistent behavoir between SMP oand none SMP kernels using spin
> locks inside driver programming
> As first an simple example:
> 
> static spinlock_t        qtlock               = SPIN_LOCK_UNLOCKED;
> 
> void foo()
> {
>      unsigned long  local_flags;
>      spin_lock_irqsave (&qtlock, local_flags);
>      spin_lock_irqsave (&qtlock, local_flags);
> }
> 
> Calling the function foo() works proper in none SMP kernels. I assume, the

... only because spinlocks are no-op on UP.

> spinlocks internaly will be initialized as
> recursive semaphore as default. So it is possible to aquire it more than
> once by the same thread.

Spinlocks are *not* recursive.  The code above is a bug - it's just that
on non-SMP it doesn't get caught.

Spinlock is a mutex, not a recursive sempahore.

Re: inconsistent usage of

[Jens Axboe]

On Tue, Apr 22 2003, Heiko.Rabe@InVision.de wrote:
> I found inconsistent behavoir between SMP oand none SMP kernels using spin
> locks inside driver programming
> As first an simple example:
> 
> static spinlock_t        qtlock               = SPIN_LOCK_UNLOCKED;
> 
> void foo()
> {
>      unsigned long  local_flags;
>      spin_lock_irqsave (&qtlock, local_flags);
>      spin_lock_irqsave (&qtlock, local_flags);
> }

[snip rant]

Check the spinlock implementation. All the above does in UP is
disable/save interrupts twice. The actual spinlock is a nop. As only one
processor can be executing inside the kernel in UP, you only need to
guard against interrupts.

-- 
Jens Axboe