All of lore.kernel.org
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: Suresh Siddha <suresh.b.siddha@intel.com>
Cc: Hans Rosenfeld <hans.rosenfeld@amd.com>,
	Ingo Molnar <mingo@elte.hu>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	tglx@linutronix.de, robert.richter@amd.com,
	andreas.herrmann3@amd.com
Subject: Re: [RFC] x86, fpu: unify signal handling code paths for x86 and x86_64 kernels
Date: Thu, 14 Jun 2012 17:16:30 -0700	[thread overview]
Message-ID: <4FDA7EDE.3070408@zytor.com> (raw)
In-Reply-To: <1339719035.3475.52.camel@sbsiddha-desk.sc.intel.com>

On 06/14/2012 05:10 PM, Suresh Siddha wrote:
> 
> For the above mentioned reason, I guess the current usage of
> is_ia32_task() in copy_siginfo_to_user32() (added recently for x32
> support) is broken, as the TS_COMPAT flag may not be set for the x86
> compat mode apps in those paths.
> 
> Peter offline suggested that the signal  delivery path should probably
> set/clear the TS_COMPAT flag (just like we do it for syscall paths), so
> that is_ia32_task() will work in those paths.
> 
> But the exception paths for the 32bit and 64bit apps in the 64-bit
> kernel is same. So I really need to use something like TIF_IA32 to find
> out the compat mode of the task. Anyways, the comment in the below patch
> explains the problem ;) What should we do? Just remove the
> is_ia32_task() checks in signal paths and just use TIF_IA32 or do
> something like below.
> 
> My personal preference is to use TIF_IA32 check and avoid  the usage of
> is_ia32_task() in the signal delivery paths.

That is the quick fix, but...

> Signal return goes through a system call which already sets the
> TS_COMPAT. It is the signal delivery that is causing the asymmetry.

Yes, and I think you missed some aspects of my statement: the notion
would be that TS_COMPAT would be set from the TIF_IA32 flag at the time
we decide to deliver a signal, the signal being a pseudo-system-call.
However, the more I wonder about if that will confuse the crap out of
ptrace, so using TIF_IA32 might just be the best thing anyway.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.


  reply	other threads:[~2012-06-15  0:17 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-13  0:03 [RFC] x86, fpu: unify signal handling code paths for x86 and x86_64 kernels Suresh Siddha
2012-06-13  0:17 ` H. Peter Anvin
2012-06-14 14:37 ` Hans Rosenfeld
2012-06-14 20:45   ` Suresh Siddha
2012-06-15  0:10   ` Suresh Siddha
2012-06-15  0:16     ` H. Peter Anvin [this message]
2012-06-15  1:07       ` Suresh Siddha
2012-06-15  1:13         ` H. Peter Anvin
2012-06-15  1:16           ` Suresh Siddha
2012-06-15  1:17             ` H. Peter Anvin
2012-06-16  3:14         ` [tip:x86/urgent] x86, compat: Use test_thread_flag(TIF_IA32) in compat signal delivery tip-bot for Suresh Siddha
2012-06-14 20:48 ` [RFC] x86, fpu: unify signal handling code paths for x86 and x86_64 kernels H. Peter Anvin
2012-06-14 20:49   ` Suresh Siddha

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=4FDA7EDE.3070408@zytor.com \
    --to=hpa@zytor.com \
    --cc=andreas.herrmann3@amd.com \
    --cc=hans.rosenfeld@amd.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=robert.richter@amd.com \
    --cc=suresh.b.siddha@intel.com \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.