Is THREAD_INFO_IN_TASK appropriate for -mm for 4.8?

Is THREAD_INFO_IN_TASK appropriate for -mm for 4.8?

[Andy Lutomirski]

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.

Is THREAD_INFO_IN_TASK appropriate for -mm for 4.8?

[Christian Borntraeger]

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.

Is THREAD_INFO_IN_TASK appropriate for -mm for 4.8?

[Heiko Carstens]

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.

Is THREAD_INFO_IN_TASK appropriate for -mm for 4.8?

[Mark Rutland]

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

Is THREAD_INFO_IN_TASK appropriate for -mm for 4.8?

[Ingo Molnar]

* 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