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

[Bill Huey (hui) <bhuey@lnxw.com>]

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.

bill

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/