signal dequeue ...

signal dequeue ...

[Davide Libenzi]

I'm just trying to figure out the reason why signal must be delivered one at a
time instead of building a frame with multiple calls with only the last one
chaining back to the kernel.
All previous calls instead of calling the stub that jump back to the kernel
will call a small stub like ( Ix86 ) :


stkclean_stub:
        add $frame_size, %esp
        cmp %esp, $end_stubs
        jae $sigreturn_stub
        ret
sigreturn_stub:
        mov __NR_sigreturn, %eax
        int $0x80
end_stubs:

...
| context1
* $stkclean_stub
* sigh1_eip
| context0
* $stkclean_stub
* sigh0_eip


When sigh0 return, it'll call stkclean_stub that will clean context0 and if
we're at the end it'll call the jump-back-to-kernel stub, otherwise the it'll
execute the  ret  the will call sigh1 handler ... and so on.





- Davide

Re: signal dequeue ...

[george anzinger]

Davide Libenzi wrote:
> 
> I'm just trying to figure out the reason why signal must be delivered one at a
> time instead of building a frame with multiple calls with only the last one
> chaining back to the kernel.
> All previous calls instead of calling the stub that jump back to the kernel
> will call a small stub like ( Ix86 ) :
> 
> stkclean_stub:
>         add $frame_size, %esp
>         cmp %esp, $end_stubs
>         jae $sigreturn_stub
>         ret
> sigreturn_stub:
>         mov __NR_sigreturn, %eax
>         int $0x80
> end_stubs:
> 
> ...
> | context1
> * $stkclean_stub
> * sigh1_eip
> | context0
> * $stkclean_stub
> * sigh0_eip
> 
> When sigh0 return, it'll call stkclean_stub that will clean context0 and if
> we're at the end it'll call the jump-back-to-kernel stub, otherwise the it'll
> execute the  ret  the will call sigh1 handler ... and so on.
> 
And if the user handler does a long_jmp?  

Actually some systems have code in long_jmp to notify the system that it
will not be returning (these are systems that deliver signals to user
land with context on the kernel stack and need to know when to unwind
the kernel stack).

George

Re: signal dequeue ...

[Davide Libenzi]

On 22-Jun-2001 george anzinger wrote:
> Davide Libenzi wrote:
>> 
>> I'm just trying to figure out the reason why signal must be delivered one at
>> a
>> time instead of building a frame with multiple calls with only the last one
>> chaining back to the kernel.
>> All previous calls instead of calling the stub that jump back to the kernel
>> will call a small stub like ( Ix86 ) :
>> 
>> stkclean_stub:
>>         add $frame_size, %esp
>>         cmp %esp, $end_stubs
>>         jae $sigreturn_stub
>>         ret
>> sigreturn_stub:
>>         mov __NR_sigreturn, %eax
>>         int $0x80
>> end_stubs:
>> 
>> ...
>> | context1
>> * $stkclean_stub
>> * sigh1_eip
>> | context0
>> * $stkclean_stub
>> * sigh0_eip
>> 
>> When sigh0 return, it'll call stkclean_stub that will clean context0 and if
>> we're at the end it'll call the jump-back-to-kernel stub, otherwise the
>> it'll
>> execute the  ret  the will call sigh1 handler ... and so on.
>> 
> And if the user handler does a long_jmp?  

But if the user handler does a long_jump even the old stub will be missed,
isn't it ?




- Davide

Re: signal dequeue ...

[george anzinger]

Davide Libenzi wrote:
> 
> On 22-Jun-2001 george anzinger wrote:
> > Davide Libenzi wrote:
> >>
> >> I'm just trying to figure out the reason why signal must be delivered one at
> >> a
> >> time instead of building a frame with multiple calls with only the last one
> >> chaining back to the kernel.
> >> All previous calls instead of calling the stub that jump back to the kernel
> >> will call a small stub like ( Ix86 ) :
> >>
> >> stkclean_stub:
> >>         add $frame_size, %esp
> >>         cmp %esp, $end_stubs
> >>         jae $sigreturn_stub
> >>         ret
> >> sigreturn_stub:
> >>         mov __NR_sigreturn, %eax
> >>         int $0x80
> >> end_stubs:
> >>
> >> ...
> >> | context1
> >> * $stkclean_stub
> >> * sigh1_eip
> >> | context0
> >> * $stkclean_stub
> >> * sigh0_eip
> >>
> >> When sigh0 return, it'll call stkclean_stub that will clean context0 and if
> >> we're at the end it'll call the jump-back-to-kernel stub, otherwise the
> >> it'll
> >> execute the  ret  the will call sigh1 handler ... and so on.
> >>
> > And if the user handler does a long_jmp?
> 
> But if the user handler does a long_jump even the old stub will be missed,
> isn't it ?

Right, but the remaining signals are still pending.  In your method, the
kernel doesn't know which were and which were not actually delivered.

George

Re: signal dequeue ...

[Paul Menage]

In article <0C01A29FBAE24448A792F5C68F5EA47D120354@nasdaq.ms.ensim.com>,
you write:
>
>Right, but the remaining signals are still pending.  In your method, the
>kernel doesn't know which were and which were not actually delivered.
>

You could add an SA_MULTIPLE flag to the sigaction() sa_flags, which
permit the kernel to stack multiple signals up in this way for apps
that guarantee not to misbehave. In do_signal()/handle_signal(), only
allow a signal to be stacked on another signal if its handler has
SA_MULTIPLE set. So non-stackable signals will always be the last
signal frame of the stack to be entered, and it won't matter if they
longjmp() out.

Would the performance improvement from this be worthwhile? I imagine if
you're handling a lot of SIGIO signals, the ability to batch up several
signals in a single user/kernel crossing might be of noticeable benefit.

Paul

Re: signal dequeue ...

[Davide Libenzi]

On 22-Jun-2001 Paul Menage wrote:
> In article <0C01A29FBAE24448A792F5C68F5EA47D120354@nasdaq.ms.ensim.com>,
> you write:
>>
>>Right, but the remaining signals are still pending.  In your method, the
>>kernel doesn't know which were and which were not actually delivered.
>>
> 
> You could add an SA_MULTIPLE flag to the sigaction() sa_flags, which
> permit the kernel to stack multiple signals up in this way for apps
> that guarantee not to misbehave. In do_signal()/handle_signal(), only
> allow a signal to be stacked on another signal if its handler has
> SA_MULTIPLE set. So non-stackable signals will always be the last
> signal frame of the stack to be entered, and it won't matter if they
> longjmp() out.
> 
> Would the performance improvement from this be worthwhile? I imagine if
> you're handling a lot of SIGIO signals, the ability to batch up several
> signals in a single user/kernel crossing might be of noticeable benefit.

This could be a good idea but before moving a single hair I want to measure the
maximum ( and average ) queue length for rt signals.
In case this will be constantly > 1 to have a multiple signal dispatch will
save a lot of kernel-mode / user-mode switches.
Otherwise this will be files under NAI ( Not An Issue ) :)





- Davide