Re: + espfix-code-cleanup.patch added to -mm tree

Hi.

Chuck Ebbert wrote:

Only problem I have with this is we lose the original fault info from
the iret.  So we have no real way of knowing whether it was #GP, #NP, #SF
or whatever, and no record of the offending iret's address.

Thanks for the precise explanation.
There was also a problem with me reading the Intel's manual:
it uses Pop() in their pseudo-code, and it Pop()'s the values
*before* checking them. The description of the Pop() is very
confusing:
---
Pop() removes the value from the top of the stack and returns it.
---
What "removes" means here is unclear. Whether it adjusts a stack
pointer, is unclear. Since it is Pop(), I was assuming "removes"
means it also adjusts the stack pointer, but now I see it was a
wrong guess.

-
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/

---

• References:
  • Re: + espfix-code-cleanup.patch added to -mm tree
    • From: Chuck Ebbert <[email protected]>

• Prev by Date: [patch 3/3] selinux: replace ctxid with sid in selinux_audit_rule_match interface
• Next by Date: Re: [PATCH] LSM: remove BSD secure level security module
• Previous by thread: Re: + espfix-code-cleanup.patch added to -mm tree
• Next by thread: Re: + espfix-code-cleanup.patch added to -mm tree
• Index(es):
  • Date
  • Thread

[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]