Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1425532 > unrolled thread
| Started by | Andy Lutomirski <luto@amacapital.net> |
|---|---|
| First post | 2016-06-18 00:50 +0200 |
| Last post | 2016-06-18 01:30 +0200 |
| Articles | 6 — 4 participants |
Back to article view | Back to linux.kernel
[off-list] a path toward killing thread_info Andy Lutomirski <luto@amacapital.net> - 2016-06-18 00:50 +0200
Re: [off-list] a path toward killing thread_info Al Viro <viro@ZenIV.linux.org.uk> - 2016-06-18 01:10 +0200
Re: [off-list] a path toward killing thread_info "H. Peter Anvin" <hpa@zytor.com> - 2016-06-18 01:20 +0200
Re: [off-list] a path toward killing thread_info Benjamin Herrenschmidt <benh@kernel.crashing.org> - 2016-06-18 01:30 +0200
Re: [off-list] a path toward killing thread_info "H. Peter Anvin" <hpa@zytor.com> - 2016-06-18 02:10 +0200
Re: [off-list] a path toward killing thread_info Andy Lutomirski <luto@amacapital.net> - 2016-06-18 01:30 +0200
| From | Andy Lutomirski <luto@amacapital.net> |
|---|---|
| Date | 2016-06-18 00:50 +0200 |
| Subject | [off-list] a path toward killing thread_info |
| Message-ID | <rLaKm-47q-5@gated-at.bofh.it> |
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
[toc] | [next] | [standalone]
| From | Al Viro <viro@ZenIV.linux.org.uk> |
|---|---|
| Date | 2016-06-18 01:10 +0200 |
| Message-ID | <rLb3H-4td-9@gated-at.bofh.it> |
| In reply to | #1425532 |
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?
[toc] | [prev] | [next] | [standalone]
| From | "H. Peter Anvin" <hpa@zytor.com> |
|---|---|
| Date | 2016-06-18 01:20 +0200 |
| Message-ID | <rLbdn-4wD-7@gated-at.bofh.it> |
| In reply to | #1425548 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Benjamin Herrenschmidt <benh@kernel.crashing.org> |
|---|---|
| Date | 2016-06-18 01:30 +0200 |
| Message-ID | <rLbn3-4A9-11@gated-at.bofh.it> |
| In reply to | #1425549 |
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.
[toc] | [prev] | [next] | [standalone]
| From | "H. Peter Anvin" <hpa@zytor.com> |
|---|---|
| Date | 2016-06-18 02:10 +0200 |
| Message-ID | <rLbZM-54e-19@gated-at.bofh.it> |
| In reply to | #1425554 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Andy Lutomirski <luto@amacapital.net> |
|---|---|
| Date | 2016-06-18 01:30 +0200 |
| Message-ID | <rLbn3-4A9-9@gated-at.bofh.it> |
| In reply to | #1425548 |
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.
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web