[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-atm
Subject:    Re: Kernel locking, advice sought
From:       Heikki Vatiainen <hessu () cs ! tut ! fi>
Date:       2000-03-31 19:29:11
[Download RAW message or body]

Werner Almesberger <almesber@lrc.epfl.ch> wrote:

> Heikki Vatiainen wrote:
> > 1. Cache lookups are done after a write_lock_irqsave().
> 
> Yes, except that you want a read lock, read_lock_irqsave.

Of course. I was wearing a suit when I wrote that, so that might
have blurred my thinking even below the normal level :-)
 
> > 2. Functions that add/remove entries are called after a
> >    spin_lock_irq() because they are not called from hardware IRQ
> >    context.
> 
> I don't think you can mix spinlocks and r/w locks, so you'd have to
> use write_lock_irq or write_lock_irqsave.

True. The compiler would probably have also noticed this since the 
two macros expand to function calls for which the prototypes are
void spin_lock(spinlock_t *lock)  and  void write_lock(rwlock_t *rw)

> > Does this sound good? Rusty did not talk about locking between
> > hardware IRQs and user context, but as I understood this issue, the
> > problem and the solutions are the same as between software
> > interrupts and hardware IRQs.
> 
> Yes, pretty much. Except that user context may have the additional
> complication of sleeping. But this is of course something you can
> control.

Ah, another good note. If all the possible sleepers are in the 
kernel locking howto (section 9.7) then I only have to check the 
kmalloc()s in MPOA's case. A quick look showed no problems there.

> > Also, later when all the drivers have
> > been converted to use tasklets, the egress locking can be done with
> > read_lock_bh() calls.
> 
> Maybe you should check with Alexey if *_bh will continue to affect
> tasklets and timers in the future.

I will. Once again I'm relying on Rusty's howto in which he writes
that e.g spin_lock_bh() is there for historical reasons and should
"be called spin_lock_softirq() in a perfect world."

Thanks a lot for helping with this, I'll try to get this done
this the weekend.

// Heikki
-- 
Heikki Vatiainen                  * hessu@cs.tut.fi
Tampere University of Technology  * Tampere, Finland

[prev in list] [next in list] [prev in thread] [next in thread]