Re: PATCH 2.4.0.10.3: pc_keyb and q40_keyb cleanup

From: Jeff Garzik (jgarzik@mandrakesoft.com)
Date: Tue Oct 17 2000 - 04:26:23 EST


Andrea Arcangeli wrote:
> On Mon, Oct 16, 2000 at 09:31:42PM -0400, Jeff Garzik wrote:
> >[..] Why are local interrupts disabled [in pc_keyb.c]?
>
> To avoid to deadlock on the kbd_controller_lock in SMP or to race in UP.
>
> Both irq handler and normal kernel context (open/close) will play with the keyb
> controller at around address 0x6x and accesses are serialized via the
> kbd_controller_lock.

Well, the -spin lock- exists for serialization. My question is.... Why
does pc_keyb irq handler disable local irqs for this case? What is the
race/deadlock that exists with spin_lock in the irq handler, but does
not exist with spin_lock_irqsave in the irq handler?

For UP, using spin_lock_irqsave in user context, and spin_lock in the
irq handler, irqs are disabled for user context, and user context is
disabled while the irq handler is running, so no race, and no additional
synchronization needed.

For SMP, using spin_lock_irqsave in user context, and spin_lock in the
irq handler, the irq handler and user context need only to spin_lock to
protect the kbd controller.

If the above two paragraphs are correct... then why was my patch
incorrect?

Sorry that I'm a bit slow here, but I just don't see why
s/spin_lock_irqsave/spin_lock/ is wrong...

        Jeff

-- 
Jeff Garzik                    | The difference between laziness and
Building 1024                  | prioritization is the end result.
MandrakeSoft                   |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Mon Oct 23 2000 - 21:00:11 EST