To: Bryan Ford <baford@mit.edu>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] x86_64 signal handling for 64-bit apps w/ mixed 32-bit code - trivial fix
References: <200510051235.41376.baford@mit.edu>
From: Andi Kleen <ak@suse.de>
Date: 06 Oct 2005 18:46:44 +0200
In-Reply-To: <200510051235.41376.baford@mit.edu>
Message-ID: <p734q7uzj7v.fsf@verdi.suse.de>
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1074
Lines: 17

Bryan Ford <baford@mit.edu> writes:

> The proposed patch doesn't affect any performance-critical paths (e.g., 
> syscall or interrupt entry/exit), and merely involves a couple more moves 
> to/from user space on signal frame setup and sigreturn.  It also doesn't 
> affect the size or shape of the sigcontext at all, since there already was an
> (unused) slot for CS, and I've assigned the convenient __pad0 field as a slot 
> for SS.  The existing, unused slots for FS and GS remain unused for now, and 
> I don't see any urgent need to change that.  The only way this might break an 
> existing app is if the app tries to cons up its own signal frame (not 
> generated by the kernel) and pass it to sigreturn, but this is presumably a 
> no-no anyway.

I see the point of saving/restore cs, but why ss and not es/ds ? 

-Andi

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/