Re: [PATCH] improve spinlock debugging

[george anzinger <george@mvista.com>]

Roman Zippel wrote:
> 
> Hi,
> 
> Robert Love wrote:
> 
> > Right, I meant just the spin_lock_irq case, which would be fine except
> > for the case where:
> >
> > spin_lock_irq
> > spin_unlock
> > restore_irq
> >
> > to solve this, we need a spin_unlock_irq_on macro that didn't touch the
> > preemption count.
> 
> Has someone a real example of something like this?
> I'd suspect someone is trying a (questionable) micro optimization or is
> holding the lock for too long anyway. Instead of adding more macros,
> maybe it's better to look closely whether something needs fixing.
> 
Oh it is in there somewhere.  I tried to do the indicated thing for
preemption and ran aground on it.  Grep drivers for spin_lock_irq (or
irq save).  I don't remember which, but there is more than one.


-- 
George           george@mvista.com
High-res-timers: http://sourceforge.net/projects/high-res-timers/
Real time sched: http://sourceforge.net/projects/rtsched/