Hi,

I do have questions on the following code from the do_signal method defined in the file arch/i386/kernel/signal.c i.e.
/*
* We want the common case to go fast, which
* is why we may in certain cases get here from
* kernel mode. Just return without doing anything
* if so.
*/
if ((regs->xcs & 3) != 3)
return 1;

If I understand this code then it looks like kernel avoids signal processing from nested interrupts.
Is it true?

Thanks,
Pankaj

What's your kernel version?

it's not even nested interupts but interrupt handlers altogether.

signals are only processed if they are going to return in user space.

this is just to catch some kind of a mistake yes ?

it might be like you said something funky and nested or recursive is going on
an interruptable interrupt handler ? but not necessarily.

Hi,

Thanks for your replies.

1) What's your kernel version?
I am using 2.6.9 kernel.

2) When I say 'kernel avoids signal processing from nested interrupts', I mean that returing from nested interrupts. It like
When one interrput handler is executing, another interrupt can occur and later will complete its execution before the former one.
Lets say an interrupt occur when process is executing in User Mode, it causes the process to switch to Kernel Mode and therefore the regs->xcs = 3, Am I right?
And lets say another interrupt occurs while executing the first interrupt handler, it causes the regs->xcs = 0, right? and while returning from latest handler, it calls the do_signal to process the signals but it doesn't process signals because regs->xcs == 0. And when the first interrupt handler calls do_signal while returning from the interrupt handler, it does process the signals because regs->xcs == 3.

Thanks,
Pankaj

Just like comment, it protects that the function is invoked from kernel space.

it's an interesting question.
i'm thinking out loud because it's so complex.
signals cause interrupts too ! Oh My !
so interrupts calling signal() cause this recursive condition.
interrupts run in a kind of special interrupt context.
for one thing the original context might have faulted.
but it's fast it's not like context switching where you go to scheduling and like that.
lets say a non maskable interrupt happens.
system look to the interrupt pointer table and get the pointer to the interrupt handler memory space.
it hasn't really done context switching but it rather just goes to the system portion of the current stack and is then in kernel address space.

ok so now while the handler is executing another interrupt happens with higher priority.
so now the new interrupt could be handled in a context switch (new stack).
if it has lower priority it would put on hold till the first one returns then processed.

BUT if the register is set to 0 like you said then the signal isn't handled at all
until after the system restarts back in userspace.
i think it's the only really safe way to do it.

this avoids all the nutty conditions
when this could get all screwed up.
pending signal flags don't get cleared and whatnot when the reset to user space takes place.
in other words the state that got saved might not be the right/current state.

but this conveniently avoids the whole issue.
i think ? the whole thing is soooooo confusing.