Re: [RFC] RCU and CONFIG_PREEMPT_RT progress, part 3

["Paul E. McKenney" <paulmck@us.ibm.com>]

On Wed, Jul 13, 2005 at 01:35:54PM -0700, Bill Huey wrote:
> On Wed, Jul 13, 2005 at 11:48:01AM -0700, Paul E. McKenney wrote:
> > 1.	Is use of spin_trylock() and spin_unlock() in hardirq code
> > 	(e.g., rcu_check_callbacks() and callees) a Bad Thing?
> > 	Seems to result in boot-time hangs when I try it, and switching
> > 	to _raw_spin_trylock() and _raw_spin_unlock() seems to work
> > 	better.  But I don't see why the other primitives hang --
> > 	after all, you can call wakeup functions in irq context in
> > 	stock kernels...
> 
> The implementation of "printk" does funky stuff like this so I'm assuming it's
> sort of acceptable.
> 
> Some of those function bypass latency tracing and preemption violation checks.
> Don't see a reason why you should be touching those functions unless you're
> going to modify implementation of spinlocks directly. Just use
> spinlock_t/raw_spinlock_t to take advantage of the type parametrics in Ingo's
> spinlock code to determine which lock you're using and you should be fine.

Using raw_spinlock_t along with spin_lock_irqsave() and friends does
seem to be working, thanks to both you and Steve for suggesting it!

							Thanx, Paul