All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jamie Lokier <jamie@shareable.org>
To: Tony Lindgren <tony@atomide.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] arm: Replace CONFIG_HAS_TLS_REG with HWCAP_TLS and check for it on V6
Date: Fri, 19 Mar 2010 03:46:45 +0000	[thread overview]
Message-ID: <20100319034645.GG14108@shareable.org> (raw)
In-Reply-To: <20100319013521.GP2900@atomide.com>

Tony Lindgren wrote:
> Also, I wonder if the change __kuser_get_tls is safe?
> 
> +	ldr     r0, [pc, #(16 - 8)]		@ TLS set at 0xffff0ff0?
> +	cmp	r0, #0				@ assume hw TLS if not set
> +	mrceq	p15, 0, r0, c13, c0, 3		@ read TLS register

You cannot assume the TLS value is non-zero, because it's provided by
userspace to use however it wants.  It doesn't even have to be an address.

I'm thinking, why not an alternative() macro like on x86, which is a
very nice way to describe run-time patches of one or a few instructions
which depend on arch feature bits.

Then all that switch_to() logic could be made the size it was before.

An alternative() macro could make a lot of other chip-dependent calls
smaller too, i.e. all those which dispatch through function pointers
at present for cache flushing etc - they could become direct calls, or
an inline instruction or two when possible.

-- Jamie

WARNING: multiple messages have this Message-ID (diff)
From: jamie@shareable.org (Jamie Lokier)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm: Replace CONFIG_HAS_TLS_REG with HWCAP_TLS and check for it on V6
Date: Fri, 19 Mar 2010 03:46:45 +0000	[thread overview]
Message-ID: <20100319034645.GG14108@shareable.org> (raw)
In-Reply-To: <20100319013521.GP2900@atomide.com>

Tony Lindgren wrote:
> Also, I wonder if the change __kuser_get_tls is safe?
> 
> +	ldr     r0, [pc, #(16 - 8)]		@ TLS set at 0xffff0ff0?
> +	cmp	r0, #0				@ assume hw TLS if not set
> +	mrceq	p15, 0, r0, c13, c0, 3		@ read TLS register

You cannot assume the TLS value is non-zero, because it's provided by
userspace to use however it wants.  It doesn't even have to be an address.

I'm thinking, why not an alternative() macro like on x86, which is a
very nice way to describe run-time patches of one or a few instructions
which depend on arch feature bits.

Then all that switch_to() logic could be made the size it was before.

An alternative() macro could make a lot of other chip-dependent calls
smaller too, i.e. all those which dispatch through function pointers
at present for cache flushing etc - they could become direct calls, or
an inline instruction or two when possible.

-- Jamie

  parent reply	other threads:[~2010-03-19  3:46 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-17 17:57 [PATCH] arm: Fix mounting root on omaps with CPU_V6 and CPU_V7 Tony Lindgren
2010-03-17 17:57 ` Tony Lindgren
2010-03-17 18:07 ` Catalin Marinas
2010-03-17 18:07   ` Catalin Marinas
2010-03-17 19:11   ` Tony Lindgren
2010-03-17 19:11     ` Tony Lindgren
2010-03-18 11:13     ` Catalin Marinas
2010-03-18 11:13       ` Catalin Marinas
2010-03-18 17:00       ` Tony Lindgren
2010-03-18 17:00         ` Tony Lindgren
2010-03-19  1:35         ` [PATCH] arm: Replace CONFIG_HAS_TLS_REG with HWCAP_TLS and check for it on V6 Tony Lindgren
2010-03-19  1:35           ` Tony Lindgren
2010-03-19  3:24           ` Tony Lindgren
2010-03-19  3:24             ` Tony Lindgren
2010-03-19  3:46           ` Jamie Lokier [this message]
2010-03-19  3:46             ` Jamie Lokier
2010-03-19  8:54             ` Russell King - ARM Linux
2010-03-19  8:54               ` Russell King - ARM Linux
2010-03-19 15:32               ` Tony Lindgren
2010-03-19 15:32                 ` Tony Lindgren
2010-03-19  8:53           ` Russell King - ARM Linux
2010-03-19  8:53             ` Russell King - ARM Linux
2010-03-19 15:58             ` Tony Lindgren
2010-03-19 15:58               ` Tony Lindgren
2010-03-23  0:16               ` Russell King - ARM Linux
2010-03-23  0:16                 ` Russell King - ARM Linux
2010-03-23  0:54                 ` Tony Lindgren
2010-03-23  0:54                   ` Tony Lindgren
  -- strict thread matches above, loose matches on Subject: below --
2010-03-18 19:02 Tony Lindgren
2010-06-29 10:34 Tony Lindgren

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=20100319034645.GG14108@shareable.org \
    --to=jamie@shareable.org \
    --cc=catalin.marinas@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=tony@atomide.com \
    /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.