[lkml]   [2000]   [Oct]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: PATCH pc_keyb and q40_keyb cleanup
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

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


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
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:41    [W:0.105 / U:2.956 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site