From: Andi Kleen <ak@suse.de>
To: Roland McGrath <roland@redhat.com>
Cc: Linus Torvalds <torvalds@osdl.org>, Andi Kleen <ak@suse.de>,
Andrew Morton <akpm@osdl.org>,
Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] i386: handle iret faults better
Date: Fri, 29 Apr 2005 17:01:17 +0200 [thread overview]
Message-ID: <20050429150117.GJ21080@wotan.suse.de> (raw)
In-Reply-To: <200504290340.j3T3eCcO032218@magilla.sf.frob.com>
On Thu, Apr 28, 2005 at 08:40:12PM -0700, Roland McGrath wrote:
> I was never very happy with the special-case check for iret_exc either.
> But for the first crack, I went for the fix that didn't touch other
> infrastructure code.
>
> The fault.c changes here are really not necessary for the bug fix at all,
> it will never be used there. But to make it a clean infrastructure
> upgrade, I made every caller of fixup_exception consistently pass in the
> complete info it uses for signals in the user-mode case.
>
>
> A user process can cause a kernel-mode fault in the iret instruction, by
> setting an invalid %cs and such, via ptrace or sigreturn. The fixup code
> now calls do_exit(11), so a process will die with SIGSEGV but never
> generate a core dump. This is vastly more confusing in a multithreaded
> program, because do_exit just kills that one thread and so it appears to
> mysteriously disappear when it calls sigreturn.
>
> This patch makes faults in iret produce the normal signals that would
> result from the same errors when executing some user-mode instruction.
> To accomplish this, I've extended the exception_table mechanism to support
> "special fixups". Instead of a PC location to jump to, these have a
> function called in the trap handler context and passed the full trap details.
>
I think this is still far too complicated. Or at least I would
not accept a similar patch for x86-64 :) The infrastructure
seems also needlessly complicated to me, because I dont know
what it should be used for except for this.
Is it really that hard to just cause a signal in the
iret exception handler in entry.S? You can get the trapno
there anyways from orig_rax (at least on x86-64)
And having all that complicated code just to get the trapno
seems quite pointless to me. Especially since nobody
uses it it will be likely bitrotten more often than working
anyways, so it is not very useful. The error code is
in the stack frame anyways and you can get it from there.
And the trapno can just be faked to something.
-Andi
next prev parent reply other threads:[~2005-04-29 15:02 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-24 0:50 [PATCH] x86_64: " Roland McGrath
2005-04-25 15:33 ` Andi Kleen
2005-04-25 15:55 ` Linus Torvalds
2005-04-25 22:31 ` Roland McGrath
2005-04-25 22:51 ` Linus Torvalds
2005-04-26 1:57 ` Roland McGrath
2005-04-26 4:06 ` Linus Torvalds
2005-04-29 3:40 ` [PATCH] i386: " Roland McGrath
2005-04-29 15:01 ` Andi Kleen [this message]
2005-04-29 16:44 ` Linus Torvalds
2005-05-02 19:56 ` Andi Kleen
2005-04-29 3:45 ` [PATCH] x86_64: " Roland McGrath
2005-04-29 15:02 ` Andi Kleen
-- strict thread matches above, loose matches on Subject: below --
2005-04-24 0:42 [PATCH] i386: " Roland McGrath
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20050429150117.GJ21080@wotan.suse.de \
--to=ak@suse.de \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=roland@redhat.com \
--cc=torvalds@osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®