All of lore.kernel.org
 help / color / mirror / Atom feed
From: Will Deacon <will.deacon@arm.com>
To: "André Hentschel" <nerv@dawncrow.de>
Cc: "linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
	Russell King - ARM Linux <linux@arm.linux.org.uk>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	Jonathan Austin <Jonathan.Austin@arm.com>
Subject: Re: [PATCH v6] arm: Preserve the user r/w register TPIDRURW on context, switch and fork
Date: Tue, 18 Jun 2013 11:07:15 +0100	[thread overview]
Message-ID: <20130618100715.GA3539@mudshark.cambridge.arm.com> (raw)
In-Reply-To: <51BF8A1C.5070403@dawncrow.de>

On Mon, Jun 17, 2013 at 11:13:48PM +0100, André Hentschel wrote:
> From: André Hentschel <nerv@dawncrow.de>
> 
> Since commit 6a1c53124aa1 the user writeable TLS register was zeroed to
> prevent it from being used as a covert channel between two tasks.
> 
> There are more and more applications coming to Windows RT,
> Wine could support them, but mostly they expect to have
> the thread environment block (TEB) in TPIDRURW.
> 
> This patch preserves that register per thread instead of clearing it.
> Unlike the TPIDRURO, which is already switched, the TPIDRURW
> can be updated from userspace so needs careful treatment in the case that we
> modify TPIDRURW and call fork(). To avoid this we must always read
> TPIDRURW in copy_thread.
> 
> Signed-off-by: André Hentschel <nerv@dawncrow.de>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> Signed-off-by: Jonathan Austin <jonathan.austin@arm.com> 
> 
> ---
> This patch is against Linux 3.10-rc6 (7d132055814ef17a6c7b69f342244c410a5e000f)
> 
> v2: rework and fixup of v1, based on a suggested patch by Will Deacon
> v3: total rework and fixup of v2
> v4: removed condition on assembler instruction,
>     adapted my code to kernel-style, both based on comments by Will Deacon
> v5: rebased v4 on 3.10-rc2 and adding this version history
> v6: moved loading the TLS registers to the macros
>     (fixing the "LDRD is not supported on all the CPUs we have" problem)

You've changed quite a lot with this version, including the way the macro
parameters are passed. Why not just replace the problematic ldrd with two
ldr instructions and be done with it? I don't think the simple build error
warrants an overhaul of the code we already had.

Cheers,

Will

WARNING: multiple messages have this Message-ID (diff)
From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v6] arm: Preserve the user r/w register TPIDRURW on context, switch and fork
Date: Tue, 18 Jun 2013 11:07:15 +0100	[thread overview]
Message-ID: <20130618100715.GA3539@mudshark.cambridge.arm.com> (raw)
In-Reply-To: <51BF8A1C.5070403@dawncrow.de>

On Mon, Jun 17, 2013 at 11:13:48PM +0100, Andr? Hentschel wrote:
> From: Andr? Hentschel <nerv@dawncrow.de>
> 
> Since commit 6a1c53124aa1 the user writeable TLS register was zeroed to
> prevent it from being used as a covert channel between two tasks.
> 
> There are more and more applications coming to Windows RT,
> Wine could support them, but mostly they expect to have
> the thread environment block (TEB) in TPIDRURW.
> 
> This patch preserves that register per thread instead of clearing it.
> Unlike the TPIDRURO, which is already switched, the TPIDRURW
> can be updated from userspace so needs careful treatment in the case that we
> modify TPIDRURW and call fork(). To avoid this we must always read
> TPIDRURW in copy_thread.
> 
> Signed-off-by: Andr? Hentschel <nerv@dawncrow.de>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> Signed-off-by: Jonathan Austin <jonathan.austin@arm.com> 
> 
> ---
> This patch is against Linux 3.10-rc6 (7d132055814ef17a6c7b69f342244c410a5e000f)
> 
> v2: rework and fixup of v1, based on a suggested patch by Will Deacon
> v3: total rework and fixup of v2
> v4: removed condition on assembler instruction,
>     adapted my code to kernel-style, both based on comments by Will Deacon
> v5: rebased v4 on 3.10-rc2 and adding this version history
> v6: moved loading the TLS registers to the macros
>     (fixing the "LDRD is not supported on all the CPUs we have" problem)

You've changed quite a lot with this version, including the way the macro
parameters are passed. Why not just replace the problematic ldrd with two
ldr instructions and be done with it? I don't think the simple build error
warrants an overhaul of the code we already had.

Cheers,

Will

  reply	other threads:[~2013-06-18 10:08 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-17 22:13 [PATCH v6] arm: Preserve the user r/w register TPIDRURW on context, switch and fork André Hentschel
2013-06-17 22:13 ` André Hentschel
2013-06-17 22:13 ` André Hentschel
2013-06-18 10:07 ` Will Deacon [this message]
2013-06-18 10:07   ` Will Deacon
2013-06-18 18:58   ` André Hentschel
2013-06-18 18:58     ` André Hentschel
2013-06-18 19:14     ` Will Deacon
2013-06-18 19:14       ` Will Deacon
2013-06-18 19:14       ` Will Deacon

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=20130618100715.GA3539@mudshark.cambridge.arm.com \
    --to=will.deacon@arm.com \
    --cc=Jonathan.Austin@arm.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=nerv@dawncrow.de \
    /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.