hi,
In x86_64 platform, INT1 and INT3 trap stack is IST stack called
DEBUG_STACK, when INT1/INT3 trap happens, system will switch to
DEBUG_STACK by hardware. Current DEBUG_STACK size is 4K, when int1/int3
trap happens, kernel will minus current DEBUG_STACK IST value by 4k. But
if int3/int1 trap is nested, it will destroy other vector's IST stack.
This patch modifies this, it sets DEBUG_STACK size as 8K and allows two
level of nested int1/int3 trap.
Kprobe DEBUG_STACK may be nested, because kprobe hanlder may be probed
by other kprobes. This patch is against 2.6.17-rc3.
Signed-Off-By: bibo, mao <[email protected]>
Thanks
bibo,mao
Would you mind explaining why you
- needed to replace the handling of the DEBUG_STKSZ > EXCEPTION_STKSZ in in_exception_stack()?
- used a hard coded 1 instead of (EXCEPTION_STACK_ORDER + 1) for defining DEBUG_STACK_ORDER?
Thanks, Jan
>>> "bibo,mao" <[email protected]> 10.05.06 08:45 >>>
hi,
In x86_64 platform, INT1 and INT3 trap stack is IST stack called
DEBUG_STACK, when INT1/INT3 trap happens, system will switch to
DEBUG_STACK by hardware. Current DEBUG_STACK size is 4K, when int1/int3
trap happens, kernel will minus current DEBUG_STACK IST value by 4k. But
if int3/int1 trap is nested, it will destroy other vector's IST stack.
This patch modifies this, it sets DEBUG_STACK size as 8K and allows two
level of nested int1/int3 trap.
Kprobe DEBUG_STACK may be nested, because kprobe hanlder may be probed
by other kprobes. This patch is against 2.6.17-rc3.
Signed-Off-By: bibo, mao <[email protected]>
Thanks
bibo,mao
ok, EXCEPTION_STACK_ORDER + 1 is better for me.
in_exception_stack() function is to judge which IST stack by parameter
stack value, if DEBUG_STKSZ value is set as 8K. The original function
can not judge whether it is within DEBUG_STACK space.
Thanks
bibo,mao
Jan Beulich wrote:
> Would you mind explaining why you
> - needed to replace the handling of the DEBUG_STKSZ > EXCEPTION_STKSZ in in_exception_stack()?
> - used a hard coded 1 instead of (EXCEPTION_STACK_ORDER + 1) for defining DEBUG_STACK_ORDER?
>
> Thanks, Jan
>
>>>> "bibo,mao" <[email protected]> 10.05.06 08:45 >>>
> hi,
> In x86_64 platform, INT1 and INT3 trap stack is IST stack called
> DEBUG_STACK, when INT1/INT3 trap happens, system will switch to
> DEBUG_STACK by hardware. Current DEBUG_STACK size is 4K, when int1/int3
> trap happens, kernel will minus current DEBUG_STACK IST value by 4k. But
> if int3/int1 trap is nested, it will destroy other vector's IST stack.
> This patch modifies this, it sets DEBUG_STACK size as 8K and allows two
> level of nested int1/int3 trap.
> Kprobe DEBUG_STACK may be nested, because kprobe hanlder may be probed
> by other kprobes. This patch is against 2.6.17-rc3.
>
> Signed-Off-By: bibo, mao <[email protected]>
>
> Thanks
> bibo,mao
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>in_exception_stack() function is to judge which IST stack by parameter
>stack value, if DEBUG_STKSZ value is set as 8K. The original function
>can not judge whether it is within DEBUG_STACK space.
I rather think that the new code can't work properly. Since the pointer in the TSS gets decreased while the handler is
running, using that value is not going to tell you the end of the stack, but you'd rather get the end of the stack the
next (nested) invocation of the handler would use. Further, treating the entire DEBUG_STKSZ range as a single piece is
wrong, too, because it is not being used as a contiguous stack (but rather as 2 stacks EXCEPTION_STKSZ in size); the new
code shouldn't be able to properly deal with nested invocations because of this.
Jan
yes, I am wrong. And I will modify this. And then only need define
DEBUG_STACK_ORDER as (EXCEPTION_STACK_ORDER + 1)
thanks
bibo,mao
Jan Beulich wrote:
>> in_exception_stack() function is to judge which IST stack by parameter
>> stack value, if DEBUG_STKSZ value is set as 8K. The original function
>> can not judge whether it is within DEBUG_STACK space.
>
> I rather think that the new code can't work properly. Since the pointer in the TSS gets decreased while the handler is
> running, using that value is not going to tell you the end of the stack, but you'd rather get the end of the stack the
> next (nested) invocation of the handler would use. Further, treating the entire DEBUG_STKSZ range as a single piece is
> wrong, too, because it is not being used as a contiguous stack (but rather as 2 stacks EXCEPTION_STKSZ in size); the new
> code shouldn't be able to properly deal with nested invocations because of this.
>
> Jan
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
On Wednesday 10 May 2006 10:26, bibo,mao wrote:
> yes, I am wrong. And I will modify this. And then only need define
> DEBUG_STACK_ORDER as (EXCEPTION_STACK_ORDER + 1)
If the kprobes code really wants to nest (in my opinion it's a kprobes
bug) you should reduce its stack to 2K or so. Don't want to waste
space for stupid code like this.
-Andi