newbie questions about while (1) in kernel mode and spinlocks

["Sorin Manolache" <sorinm@gmail.com>]

Dear list,

I am in the process of learning how to write linux device drivers.

I have a 2.6.16.5 kernel running on a monoprocessor machine.
#CONFIG_SMP is not set
CONFIG_DEBUG_SPINLOCK=y.
CONFIG_PREEMPT=y
CONFIG_PREEMPT_BKL=y

First question:

I wrote

while (1)
   ;

in the read function of a test device driver. I expect the calling
process to freeze, and then a timer interrupt to preempt the kernel
and to schedule another process. This does not happen, the whole
system freezes. I see no effect from pressing keys or moving the
mouse. Why? The hardware interrupts are not disabled, are they? Why do
the interrupt handlers not get executed?

Second question:

I wrote

spin_lock(&lck);
down(&sem); /* I know that one shouldn't sleep when holding a lock */
                   /* but I want to understand why */
spin_unlock(&lck);

in the read function and

up(&sem)

in the write function. The semaphore is initially locked, so the first
process invoking down will sleep.

I invoke

cat /dev/test

and the process sleeps on the semaphore. Then I invoke

echo 1 > /dev/test

and I wake up the "cat" process.

Then I intend to invoke _two_ cat processes. I expect the first one to
sleep on the semaphore and the second on to spin at the spin_lock.
Then I expect to wake up the first process by invoking an echo, the
first process to release the lock and the second process to sleep on
the semaphore. What I get is that the system freezes as soon as I
invoke the second "cat" process. Again, no effect from key presses or
mouse movements. Why? Shouldn't the timer interrupt preempt the second
"cat" process that spins on the spinlock and give control to something
else, for example to the console where I could wake up the first "cat"
process? Why do I not see any effect from mouse movements? Hardware
interrupts are not disabled, are they?

Third question:

The Linux Device Drivers book says that a spin_lock should not be
shared between a process and an interrupt handler. The explanation is
that the process may hold the lock, an interrupt occurs, the interrupt
handler spins on the lock held by the process and the system freezes.
Why should it freeze? Isn't it possible for the interrupt handler to
re-enable interrupts as its first thing, then to spin at the lock, the
timer interrupt to preempt the interrupt handler and to relinquish
control to the process which in turn will finish its critical section
and release the lock, making way for the interrupt handler to
continue.

Thank you very much for clarifying these issues.

Regards,
Sorin
-
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/