[off-list] a path toward killing thread_info

[off-list] a path toward killing thread_info

[Andy Lutomirski]

https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=x86/vmap_stack&id=50d6cef284e80678c2065813b54bf525d1202d0f

It's fairly straightforward, it's arguably a cleanup, and, with it
applied, there are very few references to 'thread_info' left in the
core kernel at all.

PeterZ, I'm thinking of adding task_ti_flags_ptr to directly find the
ti flags word given a task_struct * so the scheduler can use it.  Does
that seem reasonable to you?

Ingo, lockdep tracks mutex owners by thread_info *.  Is there any good
reason for this?  Can I just use task_struct *?  If we do that, I
think thread_info will be *gone* from the core.

--Andy

-- 
Andy Lutomirski
AMA Capital Management, LLC

Re: [off-list] a path toward killing thread_info

[Al Viro]

On Fri, Jun 17, 2016 at 03:41:49PM -0700, Andy Lutomirski wrote:

> PeterZ, I'm thinking of adding task_ti_flags_ptr to directly find the
> ti flags word given a task_struct * so the scheduler can use it.  Does
> that seem reasonable to you?

What are you trying to do?  Merge task_struct and thread_info?

Re: [off-list] a path toward killing thread_info

[H. Peter Anvin]

On June 17, 2016 4:04:31 PM PDT, Al Viro <viro@ZenIV.linux.org.uk> wrote:
>On Fri, Jun 17, 2016 at 03:41:49PM -0700, Andy Lutomirski wrote:
>
>> PeterZ, I'm thinking of adding task_ti_flags_ptr to directly find the
>> ti flags word given a task_struct * so the scheduler can use it. 
>Does
>> that seem reasonable to you?
>
>What are you trying to do?  Merge task_struct and thread_info?

Yes.

I did a half-finished patchset to do this once, in that I defined accessor functions which used container_of instead of pointers on architectures where this merge was enabled.
-- 
Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.

Re: [off-list] a path toward killing thread_info

[Benjamin Herrenschmidt]

On Fri, 2016-06-17 at 16:10 -0700, H. Peter Anvin wrote:
> 
> Yes.
> 
> I did a half-finished patchset to do this once, in that I defined
> accessor functions which used container_of instead of pointers on
> architectures where this merge was enabled.

How do you get to "current" in that case ? A normal per-cpu ?

Cheers,
Ben.

Re: [off-list] a path toward killing thread_info

[H. Peter Anvin]

On June 17, 2016 4:23:19 PM PDT, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>On Fri, 2016-06-17 at 16:10 -0700, H. Peter Anvin wrote:
>> 
>> Yes.
>> 
>> I did a half-finished patchset to do this once, in that I defined
>> accessor functions which used container_of instead of pointers on
>> architectures where this merge was enabled.
>
>How do you get to "current" in that case ? A normal per-cpu ?
>
>Cheers,
>Ben.

Yes.  We already do that on x86-64 at least.
-- 
Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.

Re: [off-list] a path toward killing thread_info

[Andy Lutomirski]

On Fri, Jun 17, 2016 at 4:04 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> On Fri, Jun 17, 2016 at 03:41:49PM -0700, Andy Lutomirski wrote:
>
>> PeterZ, I'm thinking of adding task_ti_flags_ptr to directly find the
>> ti flags word given a task_struct * so the scheduler can use it.  Does
>> that seem reasonable to you?
>
> What are you trying to do?  Merge task_struct and thread_info?

Merge thread_struct and thread_info, actually.  The only functional
thing that thread_info provides is a place for arches to stash stuff.
I also want to end the era of stack overflows smashing data structures
at a fixed offset.

If we kill thread_info (on x86, anyway) and enable virtually mapped
stacks (which I just emailed out v2 of), then a stack overflow will
just OOPS cleanly on x86 without clobbering anything.