Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1504247 > unrolled thread

[PATCH 0/3] THREAD_INFO_IN_TASK prep work for arm64+s390

Started byMark Rutland <mark.rutland@arm.com>
First post2016-10-19 20:40 +0200
Last post2016-10-24 12:20 +0200
Articles 7 — 4 participants

Back to article view | Back to linux.kernel


Contents

  [PATCH 0/3] THREAD_INFO_IN_TASK prep work for arm64+s390 Mark Rutland <mark.rutland@arm.com> - 2016-10-19 20:40 +0200
    [PATCH 1/3] sched/core,x86: make struct thread_info arch specific again Mark Rutland <mark.rutland@arm.com> - 2016-10-19 20:40 +0200
      Re: [PATCH 1/3] sched/core,x86: make struct thread_info arch specific again Andy Lutomirski <luto@amacapital.net> - 2016-10-20 01:30 +0200
        Re: [PATCH 1/3] sched/core,x86: make struct thread_info arch  specific again Ingo Molnar <mingo@kernel.org> - 2016-10-20 08:50 +0200
          Re: [PATCH 1/3] sched/core,x86: make struct thread_info arch  specific again Mark Rutland <mark.rutland@arm.com> - 2016-10-20 11:40 +0200
      [tip:x86/urgent] sched/core, x86: Make struct thread_info arch  specific again tip-bot for Heiko Carstens <tipbot@zytor.com> - 2016-10-21 08:00 +0200
    Re: [PATCH 0/3] THREAD_INFO_IN_TASK prep work for arm64+s390 Mark Rutland <mark.rutland@arm.com> - 2016-10-24 12:20 +0200

#1504247 — [PATCH 0/3] THREAD_INFO_IN_TASK prep work for arm64+s390

FromMark Rutland <mark.rutland@arm.com>
Date2016-10-19 20:40 +0200
Subject[PATCH 0/3] THREAD_INFO_IN_TASK prep work for arm64+s390
Message-ID<su3Wq-53C-35@gated-at.bofh.it>
Hi all,

Heiko and I have been working on THREAD_INFO_IN_TASK for s390 and arm64
respectively, and we're both targetting v4.10.

These are the common core changes which we both require, which happen to
touch x86 and some core headers. We'd either need these merged for
v4.9-rc*, or placed on a stable branch/tag that we can both base atop
of.

I've put together a branch [1,2] based on v4.9-rc1, but the patches themselves
are sorely lacking in relevant acks. Are people willing to help change that? ;)

Thanks,
Mark.

[1] git://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git core/ti-stack-split
[2] https://git.kernel.org/cgit/linux/kernel/git/mark/linux.git/log/?h=core/ti-stack-split

Heiko Carstens (1):
  sched/core,x86: make struct thread_info arch specific again

Mark Rutland (2):
  thread_info: factor out restart_block
  thread_info: include <current.h> for THREAD_INFO_IN_TASK

 arch/x86/include/asm/thread_info.h |  9 +++++++
 include/linux/restart_block.h      | 51 ++++++++++++++++++++++++++++++++++++
 include/linux/thread_info.h        | 53 ++------------------------------------
 3 files changed, 62 insertions(+), 51 deletions(-)
 create mode 100644 include/linux/restart_block.h

-- 
1.9.1

[toc] | [next] | [standalone]


#1504249 — [PATCH 1/3] sched/core,x86: make struct thread_info arch specific again

FromMark Rutland <mark.rutland@arm.com>
Date2016-10-19 20:40 +0200
Subject[PATCH 1/3] sched/core,x86: make struct thread_info arch specific again
Message-ID<su3Wr-53C-71@gated-at.bofh.it>
In reply to#1504247
From: Heiko Carstens <heiko.carstens@de.ibm.com>

commit c65eacbe290b ("sched/core: Allow putting thread_info into
task_struct") made struct thread_info a generic struct with only a
single flags member if THREAD_INFO_IN_TASK_STRUCT is selected.

This change however seems to be quite x86 centric, since at least the
generic preemption code (asm-generic/preempt.h) assumes that struct
thread_info also has a preempt_count member, which apparently was not
true for x86.

We could add a bit more ifdefs to solve this problem too, but it seems
to be much simpler to make struct thread_info arch specific
again. This also makes the conversion to THREAD_INFO_IN_TASK_STRUCT a
bit easier for architectures that have a couple of arch specific stuff
in their thread_info definition.

The arch specific stuff _could_ be moved to thread_struct. However
keeping them in thread_info makes it easier: accessing thread_info
members is simple, since it is at the beginning of the task_struct,
while the thread_struct is at the end. At least on s390 the offsets
needed to access members of the thread_struct (with task_struct as
base) are too large for various asm instructions.  This is not a
problem when keeping these members within thread_info.

Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
---
 arch/x86/include/asm/thread_info.h |  9 +++++++++
 include/linux/thread_info.h        | 11 -----------
 2 files changed, 9 insertions(+), 11 deletions(-)

diff --git a/arch/x86/include/asm/thread_info.h b/arch/x86/include/asm/thread_info.h
index 2aaca53..ad6f5eb0 100644
--- a/arch/x86/include/asm/thread_info.h
+++ b/arch/x86/include/asm/thread_info.h
@@ -52,6 +52,15 @@
 #include <asm/cpufeature.h>
 #include <linux/atomic.h>
 
+struct thread_info {
+	unsigned long		flags;		/* low level flags */
+};
+
+#define INIT_THREAD_INFO(tsk)			\
+{						\
+	.flags		= 0,			\
+}
+
 #define init_stack		(init_thread_union.stack)
 
 #else /* !__ASSEMBLY__ */
diff --git a/include/linux/thread_info.h b/include/linux/thread_info.h
index 45f004e..2873baf 100644
--- a/include/linux/thread_info.h
+++ b/include/linux/thread_info.h
@@ -14,17 +14,6 @@
 struct compat_timespec;
 
 #ifdef CONFIG_THREAD_INFO_IN_TASK
-struct thread_info {
-	unsigned long		flags;		/* low level flags */
-};
-
-#define INIT_THREAD_INFO(tsk)			\
-{						\
-	.flags		= 0,			\
-}
-#endif
-
-#ifdef CONFIG_THREAD_INFO_IN_TASK
 #define current_thread_info() ((struct thread_info *)current)
 #endif
 
-- 
1.9.1

[toc] | [prev] | [next] | [standalone]


#1504407 — Re: [PATCH 1/3] sched/core,x86: make struct thread_info arch specific again

FromAndy Lutomirski <luto@amacapital.net>
Date2016-10-20 01:30 +0200
SubjectRe: [PATCH 1/3] sched/core,x86: make struct thread_info arch specific again
Message-ID<su8t3-81g-3@gated-at.bofh.it>
In reply to#1504249
On Wed, Oct 19, 2016 at 11:28 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> From: Heiko Carstens <heiko.carstens@de.ibm.com>
>
> commit c65eacbe290b ("sched/core: Allow putting thread_info into
> task_struct") made struct thread_info a generic struct with only a
> single flags member if THREAD_INFO_IN_TASK_STRUCT is selected.
>
> This change however seems to be quite x86 centric, since at least the
> generic preemption code (asm-generic/preempt.h) assumes that struct
> thread_info also has a preempt_count member, which apparently was not
> true for x86.
>
> We could add a bit more ifdefs to solve this problem too, but it seems
> to be much simpler to make struct thread_info arch specific
> again. This also makes the conversion to THREAD_INFO_IN_TASK_STRUCT a
> bit easier for architectures that have a couple of arch specific stuff
> in their thread_info definition.
>
> The arch specific stuff _could_ be moved to thread_struct. However
> keeping them in thread_info makes it easier: accessing thread_info
> members is simple, since it is at the beginning of the task_struct,
> while the thread_struct is at the end. At least on s390 the offsets
> needed to access members of the thread_struct (with task_struct as
> base) are too large for various asm instructions.  This is not a
> problem when keeping these members within thread_info.

Acked-by: Andy Lutomirski <luto@kernel.org>

Ingo, there's a (somewhat weak) argument for sending this via
tip/urgent: it doesn't change generated code at all, and I think it
will avoid a silly depedency or possible conflict for the next merge
window, since both arm64 and s390 are going to need it.

--Andy

[toc] | [prev] | [next] | [standalone]


#1504545 — Re: [PATCH 1/3] sched/core,x86: make struct thread_info arch specific again

FromIngo Molnar <mingo@kernel.org>
Date2016-10-20 08:50 +0200
SubjectRe: [PATCH 1/3] sched/core,x86: make struct thread_info arch specific again
Message-ID<sufkS-3W0-5@gated-at.bofh.it>
In reply to#1504407
* Andy Lutomirski <luto@amacapital.net> wrote:

> On Wed, Oct 19, 2016 at 11:28 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> > From: Heiko Carstens <heiko.carstens@de.ibm.com>
> >
> > commit c65eacbe290b ("sched/core: Allow putting thread_info into
> > task_struct") made struct thread_info a generic struct with only a
> > single flags member if THREAD_INFO_IN_TASK_STRUCT is selected.
> >
> > This change however seems to be quite x86 centric, since at least the
> > generic preemption code (asm-generic/preempt.h) assumes that struct
> > thread_info also has a preempt_count member, which apparently was not
> > true for x86.
> >
> > We could add a bit more ifdefs to solve this problem too, but it seems
> > to be much simpler to make struct thread_info arch specific
> > again. This also makes the conversion to THREAD_INFO_IN_TASK_STRUCT a
> > bit easier for architectures that have a couple of arch specific stuff
> > in their thread_info definition.
> >
> > The arch specific stuff _could_ be moved to thread_struct. However
> > keeping them in thread_info makes it easier: accessing thread_info
> > members is simple, since it is at the beginning of the task_struct,
> > while the thread_struct is at the end. At least on s390 the offsets
> > needed to access members of the thread_struct (with task_struct as
> > base) are too large for various asm instructions.  This is not a
> > problem when keeping these members within thread_info.
> 
> Acked-by: Andy Lutomirski <luto@kernel.org>
> 
> Ingo, there's a (somewhat weak) argument for sending this via
> tip/urgent: it doesn't change generated code at all, and I think it
> will avoid a silly depedency or possible conflict for the next merge
> window, since both arm64 and s390 are going to need it.

Can certainly do it if this is the final version of the patch. Mark?

Thanks,

	Ingo

[toc] | [prev] | [next] | [standalone]


#1504705 — Re: [PATCH 1/3] sched/core,x86: make struct thread_info arch specific again

FromMark Rutland <mark.rutland@arm.com>
Date2016-10-20 11:40 +0200
SubjectRe: [PATCH 1/3] sched/core,x86: make struct thread_info arch specific again
Message-ID<suhZn-5G9-15@gated-at.bofh.it>
In reply to#1504545
On Thu, Oct 20, 2016 at 08:40:45AM +0200, Ingo Molnar wrote:
> 
> * Andy Lutomirski <luto@amacapital.net> wrote:
> 
> > On Wed, Oct 19, 2016 at 11:28 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> > > From: Heiko Carstens <heiko.carstens@de.ibm.com>
> > >
> > > commit c65eacbe290b ("sched/core: Allow putting thread_info into
> > > task_struct") made struct thread_info a generic struct with only a
> > > single flags member if THREAD_INFO_IN_TASK_STRUCT is selected.
> > >
> > > This change however seems to be quite x86 centric, since at least the
> > > generic preemption code (asm-generic/preempt.h) assumes that struct
> > > thread_info also has a preempt_count member, which apparently was not
> > > true for x86.
> > >
> > > We could add a bit more ifdefs to solve this problem too, but it seems
> > > to be much simpler to make struct thread_info arch specific
> > > again. This also makes the conversion to THREAD_INFO_IN_TASK_STRUCT a
> > > bit easier for architectures that have a couple of arch specific stuff
> > > in their thread_info definition.
> > >
> > > The arch specific stuff _could_ be moved to thread_struct. However
> > > keeping them in thread_info makes it easier: accessing thread_info
> > > members is simple, since it is at the beginning of the task_struct,
> > > while the thread_struct is at the end. At least on s390 the offsets
> > > needed to access members of the thread_struct (with task_struct as
> > > base) are too large for various asm instructions.  This is not a
> > > problem when keeping these members within thread_info.
> > 
> > Acked-by: Andy Lutomirski <luto@kernel.org>
> > 
> > Ingo, there's a (somewhat weak) argument for sending this via
> > tip/urgent: it doesn't change generated code at all, and I think it
> > will avoid a silly depedency or possible conflict for the next merge
> > window, since both arm64 and s390 are going to need it.
> 
> Can certainly do it if this is the final version of the patch. Mark?

Yes; this is the final version of this patch.

I can rebase the other two core patches atop, assuming this goes in for
a v4.9-rc* tag soon.

Thanks,
Mark.

[toc] | [prev] | [next] | [standalone]


#1505482 — [tip:x86/urgent] sched/core, x86: Make struct thread_info arch specific again

Fromtip-bot for Heiko Carstens <tipbot@zytor.com>
Date2016-10-21 08:00 +0200
Subject[tip:x86/urgent] sched/core, x86: Make struct thread_info arch specific again
Message-ID<suB22-1nm-23@gated-at.bofh.it>
In reply to#1504249
Commit-ID:  c8061485a0d7569a865a3cc3c63347b0f42b3765
Gitweb:     http://git.kernel.org/tip/c8061485a0d7569a865a3cc3c63347b0f42b3765
Author:     Heiko Carstens <heiko.carstens@de.ibm.com>
AuthorDate: Wed, 19 Oct 2016 19:28:11 +0100
Committer:  Ingo Molnar <mingo@kernel.org>
CommitDate: Thu, 20 Oct 2016 13:27:47 +0200

sched/core, x86: Make struct thread_info arch specific again

The following commit:

  c65eacbe290b ("sched/core: Allow putting thread_info into task_struct")

... made 'struct thread_info' a generic struct with only a
single ::flags member, if CONFIG_THREAD_INFO_IN_TASK_STRUCT=y is
selected.

This change however seems to be quite x86 centric, since at least the
generic preemption code (asm-generic/preempt.h) assumes that struct
thread_info also has a preempt_count member, which apparently was not
true for x86.

We could add a bit more #ifdefs to solve this problem too, but it seems
to be much simpler to make struct thread_info arch specific
again. This also makes the conversion to THREAD_INFO_IN_TASK_STRUCT a
bit easier for architectures that have a couple of arch specific stuff
in their thread_info definition.

The arch specific stuff _could_ be moved to thread_struct. However
keeping them in thread_info makes it easier: accessing thread_info
members is simple, since it is at the beginning of the task_struct,
while the thread_struct is at the end. At least on s390 the offsets
needed to access members of the thread_struct (with task_struct as
base) are too large for various asm instructions.  This is not a
problem when keeping these members within thread_info.

Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: keescook@chromium.org
Cc: linux-arch@vger.kernel.org
Link: http://lkml.kernel.org/r/1476901693-8492-2-git-send-email-mark.rutland@arm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
 arch/x86/include/asm/thread_info.h |  9 +++++++++
 include/linux/thread_info.h        | 11 -----------
 2 files changed, 9 insertions(+), 11 deletions(-)

diff --git a/arch/x86/include/asm/thread_info.h b/arch/x86/include/asm/thread_info.h
index 2aaca53..ad6f5eb0 100644
--- a/arch/x86/include/asm/thread_info.h
+++ b/arch/x86/include/asm/thread_info.h
@@ -52,6 +52,15 @@ struct task_struct;
 #include <asm/cpufeature.h>
 #include <linux/atomic.h>
 
+struct thread_info {
+	unsigned long		flags;		/* low level flags */
+};
+
+#define INIT_THREAD_INFO(tsk)			\
+{						\
+	.flags		= 0,			\
+}
+
 #define init_stack		(init_thread_union.stack)
 
 #else /* !__ASSEMBLY__ */
diff --git a/include/linux/thread_info.h b/include/linux/thread_info.h
index 45f004e..2873baf 100644
--- a/include/linux/thread_info.h
+++ b/include/linux/thread_info.h
@@ -14,17 +14,6 @@ struct timespec;
 struct compat_timespec;
 
 #ifdef CONFIG_THREAD_INFO_IN_TASK
-struct thread_info {
-	unsigned long		flags;		/* low level flags */
-};
-
-#define INIT_THREAD_INFO(tsk)			\
-{						\
-	.flags		= 0,			\
-}
-#endif
-
-#ifdef CONFIG_THREAD_INFO_IN_TASK
 #define current_thread_info() ((struct thread_info *)current)
 #endif
 

[toc] | [prev] | [next] | [standalone]


#1507060

FromMark Rutland <mark.rutland@arm.com>
Date2016-10-24 12:20 +0200
Message-ID<svKwh-6el-5@gated-at.bofh.it>
In reply to#1504247
Hi Andrew,

On Wed, Oct 19, 2016 at 07:28:10PM +0100, Mark Rutland wrote:
> Heiko and I have been working on THREAD_INFO_IN_TASK for s390 and arm64
> respectively, and we're both targetting v4.10.
> 
> These are the common core changes which we both require, which happen to
> touch x86 and some core headers. We'd either need these merged for
> v4.9-rc*, or placed on a stable branch/tag that we can both base atop
> of.
> 
> I've put together a branch [1,2] based on v4.9-rc1, but the patches themselves
> are sorely lacking in relevant acks. Are people willing to help change that? ;)

Would you be happy to ack patches 2 and 3?

Ingo took patch 1 for 4.9-rc2, and these are the only core parts s390
and arm64 need to implement THREAD_INFO_IN_TASK for v4.10.

I'd like to put them on a stable branch.

Thanks,
Mark.

> [1] git://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git core/ti-stack-split
> [2] https://git.kernel.org/cgit/linux/kernel/git/mark/linux.git/log/?h=core/ti-stack-split
> 
> Heiko Carstens (1):
>   sched/core,x86: make struct thread_info arch specific again
> 
> Mark Rutland (2):
>   thread_info: factor out restart_block
>   thread_info: include <current.h> for THREAD_INFO_IN_TASK
> 
>  arch/x86/include/asm/thread_info.h |  9 +++++++
>  include/linux/restart_block.h      | 51 ++++++++++++++++++++++++++++++++++++
>  include/linux/thread_info.h        | 53 ++------------------------------------
>  3 files changed, 62 insertions(+), 51 deletions(-)
>  create mode 100644 include/linux/restart_block.h
> 
> -- 
> 1.9.1
> 

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web