Re: [DOCUMENTATION] Revised Unreliable Kernel Locking Guide

[Zwane Mwaikambo]

A few comments on top of Paul's and another seperate one;

On Fri, 12 Dec 2003, Paul E. McKenney wrote:

> o	Hardware Interrupt / Hardware IRQ: How does in_irq()
> 	know that interrupts have been blocked?  The local_irq_disable()
> 	does not seem to mess with the counter, and preempt_disable()
> 	just does the standard inc/dec stuff...
>
> 	o	in_irq() is hardirq_count().
> 	o	hardirq_count() is (preempt_count() & HARDIRQ_MASK).
> 	o	preempt_count is an integer, HARDIRQ_MASK is a constant that
> 		is out of the normal inc/dec range.
>
> 	I see how an interrupt handler causes in_irq() to do its thing
> 	via the irq_enter() and irq_exit() macros, but I don't see how
> 	masking interrupts makes this happen.
>
> 	Probably just my confusion, but...
>
> 	Ditto for "in_interrupt()".  That would be for both the
> 	analysis and the probable confusion on my part.

I'd have to agree, it would require OR'ing with irqs_disabled(). And
another addendum would be that in_interrupt() also returns true when in a
softirq handler.

>
> o	Software Interrupt / softirq: formatting botch "of'software".
> 	This would be "o'software", right?
>
> o	Preemption: Would it be worth changing the first bit
> 	of the second sentence to read something like: "In 2.5.4
> 	and later, when CONFIG_PREEMPT is set, this changes:"?

I think he could also add that local_irq_disable() also disables
preemption implicitely.

User Context
The kernel executing on behalf of a particular process (ie. a system
call or trap) or kernel thread. You can tell which process with the
current() macro.) Not to be confused with userspace. Can be interrupted by
software or hardware interrupts.

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