Prev: [git pull] one OF-related build regression fix
Next: Implement direct pineview backlight control.
From: Jeffrey Merkey on 2 Jul 2010 18:20
On an AMD64 based system executing int 1 exceptions across a rex64
sysret, if the debugger sets the trap flag, r11 which holds the eflags
values for the
sysret return from syscall, the flags do not appear to get set
resutling in the int exception nesting by calling sysret over and over
again until the kernel stack
runs off the end. Looks like the resume did not get set on this instruction.

sysret on AMD requires the flags be saved into r11 and what I am
seeing is the flags not matching what has been set in the pt_regs
struct.

Jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Jeffrey Merkey on 2 Jul 2010 21:10
On Fri, Jul 2, 2010 at 4:18 PM, Jeffrey Merkey <jeffmerkey(a)gmail.com> wrote:
> On an AMD64 based system executing int 1 exceptions across a rex64
> sysret, if the debugger sets the trap flag, r11 which holds the eflags
> values for the
> sysret return from syscall, the flags do not appear to get set
> resutling in the int exception nesting by calling sysret over and over
> again until the kernel stack
> runs off the end. �Looks like the resume did not get set on this instruction.
>
> sysret on AMD requires the flags be saved into r11 and what I am
> seeing is the flags not matching what has been set in the pt_regs
> struct.
>
> Jeff
>

The specific function to look at is in entry_64.S sysret_check. The
sequence goes;

swapgs
rex64 sysret

After swapgs the eflags in r11 do not match the actual flags passed.
The resume flag gets cleared when the sysret instruction completes,
and int 1 keeps firing on that processor until the stack runs out of
space.

Jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Jeffrey Merkey on 3 Jul 2010 01:00
On Fri, Jul 2, 2010 at 4:18 PM, Jeffrey Merkey <jeffmerkey(a)gmail.com> wrote:
> On an AMD64 based system executing int 1 exceptions across a rex64
> sysret, if the debugger sets the trap flag, r11 which holds the eflags
> values for the
> sysret return from syscall, the flags do not appear to get set
> resutling in the int exception nesting by calling sysret over and over
> again until the kernel stack
> runs off the end. �Looks like the resume did not get set on this instruction.
>
> sysret on AMD requires the flags be saved into r11 and what I am
> seeing is the flags not matching what has been set in the pt_regs
> struct.
>
> Jeff
>

For some reason, zeroing the DR6 register before calling notify_die
makes this problem go away.

Jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 | 
Pages: 1
Prev: [git pull] one OF-related build regression fix
Next: Implement direct pineview backlight control.