Kumar Gala galak at kernel.crashing.org
Thu May 1 09:28:59 EST 2008

On Apr 30, 2008, at 5:22 PM, Benjamin Herrenschmidt wrote:
> On Wed, 2008-04-30 at 17:13 -0500, Kumar Gala wrote:
>> If we don't handle reschedule or signal will we actually not
>> function
>> properly?  I assume reschedule isn't an issue, but could we lose a
>> signal?
> Well, you can be in trouble if you lose TIF_SIGPENDING. You don't - 
> have-
> to actually take the signal, it will then be done on the next return  
> to
> userspace (next timer interrupt, next syscall, ...), but  
> must not be lost.

Interesting.  It seems like causing a signal from an async interrupt  
from kernel space shouldn't be allowed.  At worse we can store back  
the flags into the "real" thread_info.

>>> Nothing specific to your patch, but those level##_STACK_TOP seem to
>>> be pretty badly named if you end up -adding- THREAD_SIZE to actually
>>> get to the stack's top. Do they really contain the stack top or do
>>> they in fact contain the stack base/bottom ?
>> That might be stale from how the old code worked.  I can never
>> remember what we consider the top and bottom of the stack.  (please
>> remind me and I'll fixup the comments and variables).
> Well, top is the high address and bottom is the low address in my view
> of things :-)

yeah, so we are now pointing to stack bottom.  will fix this up.

>> I thought about that.  The only case its a bit of an issue is for
>> CriticalInput.  I don't see Watchdog, Debug, or MachineCheck as
>> being
>> performance critical.  I can use r10 if I save and restored the CR
>> or
>> some other register.
> You can save CR first yeah and then interleave a bit using 2 registers
> (ie. 2 loads, 2 stores, or something like load 1, load 2, store 1,  
> load
> 3, store 2, etc...)

Ok, will look at that.

>> just leaving it to C code.  I assume that preempt_count should be
>> the
>> same value on entry and exit.  Do think we should set HARDIRQ_OFFSET
>> for debug level exceptions?
> Well... I think all those things should run with EE disabled, and thus
> be considered as far as linux is concerned, as interrupts. So the C  
> code
> should do irq_enter/exit.

I agree we run all these interrupt levels with EE disabled.  Not sure  
I follow what you mean by irq_enter/ext.

>> Where should I look for an example of how to convey that information
>> to lockdep?
> The irqtrace stuff in the asm would do maybe unless  
> transfer_to_handler
> does it already, I have to look at the code with all your patches
> applied...


- k

More information about the Linuxppc-dev mailing list