signal dequeue ...
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
retsigreturn_stub:
mov __NR_sigreturn, %eax
int $0x80end_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
Quoted 25 lines · 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
retsigreturn_stub:
mov__NR_sigreturn, %eax
int $0x80end_stubs:...
| context1
* $stkclean_stub
*sigh1_eip
| context0
* $stkclean_stub
*sigh0_eip
Quoted 4 lines
When sigh0 return, it'll call
stkclean_stubthat 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
Quoted 27 lines · On 22-Jun-2001 george anzinger wrote:
Quoted 26 lines · 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
retsigreturn_stub:
mov__NR_sigreturn, %eax
int $0x80end_stubs:...
| context1
* $stkclean_stub
*sigh1_eip
| context0
* $stkclean_stub
*sigh0_eip
Quoted 6 lines
Quoted 5 lines
When sigh0 return, it'll call
stkclean_stubthat 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
Quoted 34 lines · Davide Libenzi
Quoted 32 lines · On 22-Jun-2001 george anzinger wrote:
Quoted 31 lines · 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
retsigreturn_stub:
mov__NR_sigreturn, %eax
int $0x80end_stubs:...
| context1
* $stkclean_stub
*sigh1_eip
| context0
* $stkclean_stub
*sigh0_eipWhen sigh0 return, it'll call
stkclean_stubthat 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.
Quoted 4 lines
Quoted 1 line
And if the user handler does a
long_jmp?But if the user handler does a
long_jumpeven 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