On Wed, 2008-04-30 at 18:28 -0500, Kumar Gala wrote: > > 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 > > TIF_SIGPENDING > > 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.
Why shouldn't it be allowed ? We do store back flags in the real thread info when doing irqstacks... though I just noticed we don't do that for softirqs... paulus, isn't there a chance that we may lose a signal there ? I wouldn't expect softirq's to often send signals to current thread info (ie, they would use targetted flag sending which means the SIGPENDING flag will be set in the right thread_info obtained from the target task struct) but it still sounds safer to copy the flags back just in case... > yeah, so we are now pointing to stack bottom. will fix this up. Call it "base" rather than "bottom", sounds nicer :-) > I agree we run all these interrupt levels with EE disabled. Not > sure > I follow what you mean by irq_enter/ext. That should do the right thing with preempt_count(), look at do_IRQ(). Ben. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
