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

Groups > linux.kernel > #1445930 > unrolled thread

Is THREAD_INFO_IN_TASK appropriate for -mm for 4.8?

Back to article view | Back to linux.kernel

Contents

  Is THREAD_INFO_IN_TASK appropriate for -mm for 4.8? Andy Lutomirski <luto@kernel.org> - 2016-07-19 01:50 +0200
    Re: Is THREAD_INFO_IN_TASK appropriate for -mm for 4.8? Christian Borntraeger <borntraeger@de.ibm.com> - 2016-07-19 10:30 +0200
      Re: Is THREAD_INFO_IN_TASK appropriate for -mm for 4.8? Heiko Carstens <heiko.carstens@de.ibm.com> - 2016-07-25 16:30 +0200
    Re: Is THREAD_INFO_IN_TASK appropriate for -mm for 4.8? Mark Rutland <mark.rutland@arm.com> - 2016-07-19 13:30 +0200
    Re: Is THREAD_INFO_IN_TASK appropriate for -mm for 4.8? Ingo Molnar <mingo@kernel.org> - 2016-07-20 09:50 +0200

#1445930 — Is THREAD_INFO_IN_TASK appropriate for -mm for 4.8?

Hi all-

There are four core patches needed for the THREAD_INFO_IN_TASK thing,
and they apply cleanly to -mm now.  The x86 patch to flip the feature
on does not apply cleanly anywhere because it depends on changes in
-tip *and* in -mm.  I'd like to get all of this as well as the rest of
the vmap-stacks stuff in by 4.9, but I'm wondering if it might make
sense to get the core THREAD_INFO_IN_TASK stuff into -mm for 4.8
instead.

Pros:
 - It reduces the amount of core code that -tip will have to carry until 4.9.
 - It may benefit other architectures.  Christian Borntraeger
expressed an interest in enabling the feature for s390, but it'll be
awkward for him until the core bit landed.  Similarly, arm64 seems to
be interested.

Cons: It's a bit odd to merge code that can't be enabled as-is.  OTOH
x86 could plausibly enable it for 4.8 if Ingo is okay with applying
"x86/dumpstack: Pin the target stack in save_stack_trace_tsk()" and
"x86: Move thread_info into task_struct" during the merge window after
the -mm patchbomb lands.

The core changes are:

sched: Allow putting thread_info into task_struct
sched: Add try_get_task_stack() and put_task_stack()
kthread: to_live_kthread() needs try_get_task_stack()
sched: Free the stack early if CONFIG_THREAD_INFO_IN_TASK

They're also sitting here against mmots:

https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/log/?h=mmots_ti_in_task

It looks like this:

 include/linux/init_task.h   | 11 ++++++++
 include/linux/sched.h       | 66 +++++++++++++++++++++++++++++++++++++++++++--
 include/linux/thread_info.h | 15 +++++++++++
 init/Kconfig                | 10 +++++++
 init/init_task.c            |  7 +++--
 kernel/fork.c               | 35 +++++++++++++++++++++++-
 kernel/kthread.c            |  8 ++++--
 kernel/sched/core.c         |  4 +++
 kernel/sched/sched.h        |  4 +++
 9 files changed, 153 insertions(+), 7 deletions(-)

So... should I send it out against -mm or should I wait until 4.8-rc1.

[toc] | [next] | [standalone]

#1446231

On 07/19/2016 01:47 AM, Andy Lutomirski wrote:
> Hi all-
> 
> There are four core patches needed for the THREAD_INFO_IN_TASK thing,
> and they apply cleanly to -mm now.  The x86 patch to flip the feature
> on does not apply cleanly anywhere because it depends on changes in
> -tip *and* in -mm.  I'd like to get all of this as well as the rest of
> the vmap-stacks stuff in by 4.9, but I'm wondering if it might make
> sense to get the core THREAD_INFO_IN_TASK stuff into -mm for 4.8
> instead.
> 
> Pros:
>  - It reduces the amount of core code that -tip will have to carry until 4.9.
>  - It may benefit other architectures.  Christian Borntraeger
> expressed an interest in enabling the feature for s390, but it'll be
> awkward for him until the core bit landed.  Similarly, arm64 seems to
> be interested.

I have not yet talked to Martin/Heiko about this, so not sure yet if and when
s390 is going to use this - so no pressure from our side yet.

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

#1449540

On Tue, Jul 19, 2016 at 10:25:42AM +0200, Christian Borntraeger wrote:
> On 07/19/2016 01:47 AM, Andy Lutomirski wrote:
> > Hi all-
> > 
> > There are four core patches needed for the THREAD_INFO_IN_TASK thing,
> > and they apply cleanly to -mm now.  The x86 patch to flip the feature
> > on does not apply cleanly anywhere because it depends on changes in
> > -tip *and* in -mm.  I'd like to get all of this as well as the rest of
> > the vmap-stacks stuff in by 4.9, but I'm wondering if it might make
> > sense to get the core THREAD_INFO_IN_TASK stuff into -mm for 4.8
> > instead.
> > 
> > Pros:
> >  - It reduces the amount of core code that -tip will have to carry until 4.9.
> >  - It may benefit other architectures.  Christian Borntraeger
> > expressed an interest in enabling the feature for s390, but it'll be
> > awkward for him until the core bit landed.  Similarly, arm64 seems to
> > be interested.
> 
> I have not yet talked to Martin/Heiko about this, so not sure yet if and when
> s390 is going to use this - so no pressure from our side yet.

I wrote a patch four weeks ago which converts s390 based on Linus' orginal
patches. So yes, we will convert s390 as soon as this hits upstream.

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

#1446348

On Mon, Jul 18, 2016 at 04:47:39PM -0700, Andy Lutomirski wrote:
> Hi all-
> 
> There are four core patches needed for the THREAD_INFO_IN_TASK thing,
> and they apply cleanly to -mm now.  The x86 patch to flip the feature
> on does not apply cleanly anywhere because it depends on changes in
> -tip *and* in -mm.  I'd like to get all of this as well as the rest of
> the vmap-stacks stuff in by 4.9, but I'm wondering if it might make
> sense to get the core THREAD_INFO_IN_TASK stuff into -mm for 4.8
> instead.
> 
> Pros:
>  - It reduces the amount of core code that -tip will have to carry until 4.9.
>  - It may benefit other architectures.  Christian Borntraeger
> expressed an interest in enabling the feature for s390, but it'll be
> awkward for him until the core bit landed.  Similarly, arm64 seems to
> be interested.

This would probably be useful for arm64.

There's still a reasonable amount to figure out (e.g. [1,2]), so from my
PoV this is a nice-to-have, but there's no pressure.

Thanks,
Mark.

[1] https://lkml.org/lkml/2016/7/11/193
[2] https://lkml.org/lkml/2016/7/11/483

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

#1447051

* Andy Lutomirski <luto@kernel.org> wrote:

> Cons: It's a bit odd to merge code that can't be enabled as-is.  OTOH
> x86 could plausibly enable it for 4.8 if Ingo is okay with applying
> "x86/dumpstack: Pin the target stack in save_stack_trace_tsk()" and
> "x86: Move thread_info into task_struct" during the merge window after
> the -mm patchbomb lands.

There's quite a few risky stuff piled up already so I'd prefer if we delayed these 
core bits and the enablement to v4.9.

We can carry these core bits in -tip as well, can create a tip:sched/thread_info 
tree for it and such. I'd prefer that because this way we have natural proximity 
between patch application, testing and eventual fixes.

Then we can expose -next to all these changes as a single, bisectable group of 
commits and, should anything overly catastrophic happen, remove it and regroup our 
forces.

This would really be the best approach I think, since I'd like to default-enable 
all this on x86 from the very beginning.

Thanks,

	Ingo

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web