LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Roland McGrath <roland@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	linux-kernel@vger.kernel.org,
	Tomasz Grobelny <tomasz@grobelny.oswiecenia.net>
Subject: Re: [PATCH] x86 tls prevent_tail_call
Date: Wed, 27 Feb 2008 08:26:17 +0100	[thread overview]
Message-ID: <20080227072617.GB4638@elte.hu> (raw)
In-Reply-To: <20080226210018.A031B26F9A4@magilla.localdomain>


* Roland McGrath <roland@redhat.com> wrote:

> The x86 TLS cleanup in commit efd1ca52d04d2f6df337a3332cee56cd60e6d4c4 
> made the sys_set_thread_area and sys_get_thread_area functions ripe 
> for tail call optimization.  If the compiler chooses to use it for 
> them, it can clobber the user trap frame because these are asmlinkage 
> functions.

thanks, applied.

>  asmlinkage int sys_set_thread_area(struct user_desc __user *u_info)
>  {
> -	return do_set_thread_area(current, -1, u_info, 1);
> +	int ret = do_set_thread_area(current, -1, u_info, 1);
> +	prevent_tail_call(ret);
> +	return ret;

i'm wondering, have you seen this happen in practice? We use 
sys_set_thread_area() for every new task started up. I guess we havent 
seen problems in the field yet because this early during startup tasks 
do not normally receive signals? (or if they do they are fatal and no 
user signal context is used.)

btw., gcc 4.2.3 doesnt do it due to CONFIG_FRAME_POINTERS=y here, and 
most distros turn on frame pointers.

btw., this whole thing of us having to notice such tail-optimization 
incidents is totally fragile and unreliable. Shouldnt there be a "dont 
tail-optimize me" attribute which we could stick into asmlinkage? 
Perhaps sparse could detect asmlinkage functions that do not do 
prevent_tail_call()s?

	Ingo

  reply	other threads:[~2008-02-27  7:26 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-26 21:00 Roland McGrath
2008-02-27  7:26 ` Ingo Molnar [this message]
2008-02-27  7:38   ` Roland McGrath
2008-02-27 19:59     ` Tomasz Grobelny

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=20080227072617.GB4638@elte.hu \
    --to=mingo@elte.hu \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=roland@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=tomasz@grobelny.oswiecenia.net \
    --cc=torvalds@linux-foundation.org \
    --subject='Re: [PATCH] x86 tls prevent_tail_call' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).