linux-kselftest.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Re: [PATCH 2/7] arm64: Implement copy_thread_tls
       [not found]       ` <CA+y5pbSBYLvZ46nJP0pSYZnRohtPxHitOHPEaLXq23-QrPKk2g@mail.gmail.com>
@ 2020-01-07  9:02         ` Christian Brauner
  2020-01-07 17:45           ` Will Deacon
  0 siblings, 1 reply; 5+ messages in thread
From: Christian Brauner @ 2020-01-07  9:02 UTC (permalink / raw)
  To: Amanieu d'Antras
  Cc: Will Deacon, Will Deacon, linux-kernel, Christian Brauner,
	# 3.4.x, Linux ARM, keescook, linux-kselftest

[Cc Kees in case he knows something about where arch specific tests live
 or whether we have a framework for this]

On Mon, Jan 06, 2020 at 07:03:32PM +0100, Amanieu d'Antras wrote:
> On Mon, Jan 6, 2020 at 6:39 PM Will Deacon <will@kernel.org> wrote:
> > I also ran the native and compat selftests but, unfortunately, they all
> > pass even without this patch. Do you reckon it would be possible to update
> > them to check the tls pointer?
> 
> Here's the program I used for testing on arm64. I considered adding it
> to the selftests but there is no portable way of reading the TLS
> register on all architectures.

I'm not saying you need to do this right now.
It feels like we must've run into the "this is architecture
specific"-and-we-want-to-test-this issue before... Do we have a place
where architecture specific selftests live?

> 
> #include <sys/syscall.h>
> #include <unistd.h>
> #include <stdio.h>
> #include <stdint.h>
> 
> #define __NR_clone3 435
> struct clone_args {
>     uint64_t flags;
>     uint64_t pidfd;
>     uint64_t child_tid;
>     uint64_t parent_tid;
>     uint64_t exit_signal;
>     uint64_t stack;
>     uint64_t stack_size;
>     uint64_t tls;
> };
> 
> #define USE_CLONE3
> 
> int main() {
>     printf("Before fork: tp = %p\n", __builtin_thread_pointer());
> #ifdef USE_CLONE3
>     struct clone_args args = {
>         .flags = CLONE_SETTLS,
>         .tls = (uint64_t)__builtin_thread_pointer(),
>     };
>     int ret = syscall(__NR_clone3, &args, sizeof(args));
> #else
>     int ret = syscall(__NR_clone, CLONE_SETTLS, 0, 0,
> __builtin_thread_pointer(), 0);
> #endif
>     printf("Fork returned %d, tp = %p\n", ret, __builtin_thread_pointer());
> }

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH 2/7] arm64: Implement copy_thread_tls
  2020-01-07  9:02         ` [PATCH 2/7] arm64: Implement copy_thread_tls Christian Brauner
@ 2020-01-07 17:45           ` Will Deacon
  2020-01-07 18:12             ` Kees Cook
  2020-01-07 19:30             ` Christian Brauner
  0 siblings, 2 replies; 5+ messages in thread
From: Will Deacon @ 2020-01-07 17:45 UTC (permalink / raw)
  To: Christian Brauner
  Cc: Amanieu d'Antras, Will Deacon, linux-kernel,
	Christian Brauner, # 3.4.x, Linux ARM, keescook, linux-kselftest

On Tue, Jan 07, 2020 at 10:02:27AM +0100, Christian Brauner wrote:
> [Cc Kees in case he knows something about where arch specific tests live
>  or whether we have a framework for this]
> 
> On Mon, Jan 06, 2020 at 07:03:32PM +0100, Amanieu d'Antras wrote:
> > On Mon, Jan 6, 2020 at 6:39 PM Will Deacon <will@kernel.org> wrote:
> > > I also ran the native and compat selftests but, unfortunately, they all
> > > pass even without this patch. Do you reckon it would be possible to update
> > > them to check the tls pointer?
> > 
> > Here's the program I used for testing on arm64. I considered adding it
> > to the selftests but there is no portable way of reading the TLS
> > register on all architectures.
> 
> I'm not saying you need to do this right now.

Agreed, these patches should be merged in their current state and my ack
stands for that.

> It feels like we must've run into the "this is architecture
> specific"-and-we-want-to-test-this issue before... Do we have a place
> where architecture specific selftests live?

For arch-specific selftests there are tools/testing/selftests/$ARCH
directories, although in this case maybe it's better to have an #ifdef
in a header so that architectures with __builtin_thread_pointer can use
that.

Will

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH 2/7] arm64: Implement copy_thread_tls
  2020-01-07 17:45           ` Will Deacon
@ 2020-01-07 18:12             ` Kees Cook
  2020-01-07 19:30               ` Christian Brauner
  2020-01-07 19:30             ` Christian Brauner
  1 sibling, 1 reply; 5+ messages in thread
From: Kees Cook @ 2020-01-07 18:12 UTC (permalink / raw)
  To: Will Deacon
  Cc: Christian Brauner, Amanieu d'Antras, Will Deacon,
	linux-kernel, Christian Brauner, # 3.4.x, Linux ARM,
	linux-kselftest

On Tue, Jan 07, 2020 at 05:45:09PM +0000, Will Deacon wrote:
> On Tue, Jan 07, 2020 at 10:02:27AM +0100, Christian Brauner wrote:
> > [Cc Kees in case he knows something about where arch specific tests live
> >  or whether we have a framework for this]
> > [...]
> > It feels like we must've run into the "this is architecture
> > specific"-and-we-want-to-test-this issue before... Do we have a place
> > where architecture specific selftests live?
> 
> For arch-specific selftests there are tools/testing/selftests/$ARCH
> directories, although in this case maybe it's better to have an #ifdef
> in a header so that architectures with __builtin_thread_pointer can use
> that.

Yup, I agree: that's the current best-practice for arch-specific
selftests.

-- 
Kees Cook

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH 2/7] arm64: Implement copy_thread_tls
  2020-01-07 17:45           ` Will Deacon
  2020-01-07 18:12             ` Kees Cook
@ 2020-01-07 19:30             ` Christian Brauner
  1 sibling, 0 replies; 5+ messages in thread
From: Christian Brauner @ 2020-01-07 19:30 UTC (permalink / raw)
  To: Will Deacon
  Cc: Amanieu d'Antras, Will Deacon, linux-kernel,
	Christian Brauner, # 3.4.x, Linux ARM, keescook, linux-kselftest

On Tue, Jan 07, 2020 at 05:45:09PM +0000, Will Deacon wrote:
> On Tue, Jan 07, 2020 at 10:02:27AM +0100, Christian Brauner wrote:
> > [Cc Kees in case he knows something about where arch specific tests live
> >  or whether we have a framework for this]
> > 
> > On Mon, Jan 06, 2020 at 07:03:32PM +0100, Amanieu d'Antras wrote:
> > > On Mon, Jan 6, 2020 at 6:39 PM Will Deacon <will@kernel.org> wrote:
> > > > I also ran the native and compat selftests but, unfortunately, they all
> > > > pass even without this patch. Do you reckon it would be possible to update
> > > > them to check the tls pointer?
> > > 
> > > Here's the program I used for testing on arm64. I considered adding it
> > > to the selftests but there is no portable way of reading the TLS
> > > register on all architectures.
> > 
> > I'm not saying you need to do this right now.
> 
> Agreed, these patches should be merged in their current state and my ack
> stands for that.

Oh yeah, that's how I took your Ack.
Thanks! :)

> 
> > It feels like we must've run into the "this is architecture
> > specific"-and-we-want-to-test-this issue before... Do we have a place
> > where architecture specific selftests live?
> 
> For arch-specific selftests there are tools/testing/selftests/$ARCH
> directories, although in this case maybe it's better to have an #ifdef
> in a header so that architectures with __builtin_thread_pointer can use
> that.

Yeah, I think the #ifdef approach might make the most sense.

Christian

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH 2/7] arm64: Implement copy_thread_tls
  2020-01-07 18:12             ` Kees Cook
@ 2020-01-07 19:30               ` Christian Brauner
  0 siblings, 0 replies; 5+ messages in thread
From: Christian Brauner @ 2020-01-07 19:30 UTC (permalink / raw)
  To: Kees Cook
  Cc: Will Deacon, Amanieu d'Antras, Will Deacon, linux-kernel,
	Christian Brauner, # 3.4.x, Linux ARM, linux-kselftest

On Tue, Jan 07, 2020 at 10:12:39AM -0800, Kees Cook wrote:
> On Tue, Jan 07, 2020 at 05:45:09PM +0000, Will Deacon wrote:
> > On Tue, Jan 07, 2020 at 10:02:27AM +0100, Christian Brauner wrote:
> > > [Cc Kees in case he knows something about where arch specific tests live
> > >  or whether we have a framework for this]
> > > [...]
> > > It feels like we must've run into the "this is architecture
> > > specific"-and-we-want-to-test-this issue before... Do we have a place
> > > where architecture specific selftests live?
> > 
> > For arch-specific selftests there are tools/testing/selftests/$ARCH
> > directories, although in this case maybe it's better to have an #ifdef
> > in a header so that architectures with __builtin_thread_pointer can use
> > that.
> 
> Yup, I agree: that's the current best-practice for arch-specific
> selftests.

Thanks! I think using #ifdef in this case with __builtin_thread_pointer
sounds good.
So the tests can be moved into the clone3() test-suite for those
architectures.

Christian

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2020-01-07 19:31 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <20200102172413.654385-1-amanieu@gmail.com>
     [not found] ` <20200102172413.654385-3-amanieu@gmail.com>
     [not found]   ` <20200102180130.hmpipoiiu3zsl2d6@wittgenstein>
     [not found]     ` <20200106173953.GB9676@willie-the-truck>
     [not found]       ` <CA+y5pbSBYLvZ46nJP0pSYZnRohtPxHitOHPEaLXq23-QrPKk2g@mail.gmail.com>
2020-01-07  9:02         ` [PATCH 2/7] arm64: Implement copy_thread_tls Christian Brauner
2020-01-07 17:45           ` Will Deacon
2020-01-07 18:12             ` Kees Cook
2020-01-07 19:30               ` Christian Brauner
2020-01-07 19:30             ` Christian Brauner

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).