> If we fix it in the task-switch code, we shouldn't need any other changes
> (ie Chuck's change is unnecessary too), because then the process that sets
> NT will happily die (with NT set), but switch away to something else and
> nobody else will be affected.
Won't it die in the kernel with an oops on the next interrupt?
> So if I'm right, then this patch _should_ fix it. UNTESTED (and the
> "ref_from_fork" special case doesn't clear NT, so it's strictly incompete,
> but maybe somebody can test this?)
Are you sure this handles interrupts or nested syscalls
before the context switch correctly?
I think it really needs to be handled in the sysenter path.
>
> Hmm? Ingo? Comments?
>
> Andi? I don't know if x86-64 honors NT in 64-bit mode, but if it does, it
> needs something similar (assuming this works).
It doesn't task switch, but you would get a #GP in IRET at least.
Leaking that to another process is definitely not good.
> #define switch_to(prev,next,last) do { \
> unsigned long esi,edi; \
> - asm volatile("pushl %%ebp\n\t" \
> + asm volatile("pushfl\n\t" /* Save flags */ \
> + "pushl %%ebp\n\t" \
We used to do that pushfl/popfl some time ago, but Ben removed it because
it was slow on P4. Ok, nobody thought of that case back then.
-Andi
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
