Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Tue, Sep 6, 2016 at 9:19 AM, Jann Horn wrote: > On Thu, Jun 23, 2016 at 09:41:11AM -0700, Andy Lutomirski wrote: >> 3. Free stacks immediately and cache them (really easy). > > Random note: task_current_syscall() (via /proc/$pid/syscall) will probably > need additional >

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Tue, Sep 6, 2016 at 9:19 AM, Jann Horn wrote: > On Thu, Jun 23, 2016 at 09:41:11AM -0700, Andy Lutomirski wrote: >> 3. Free stacks immediately and cache them (really easy). > > Random note: task_current_syscall() (via /proc/$pid/syscall) will probably > need additional > locking when the

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Thu, Jun 23, 2016 at 09:41:11AM -0700, Andy Lutomirski wrote: > 3. Free stacks immediately and cache them (really easy). Random note: task_current_syscall() (via /proc/$pid/syscall) will probably need additional locking when the stack is freed before the task. signature.asc Description:

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Thu, Jun 23, 2016 at 09:41:11AM -0700, Andy Lutomirski wrote: > 3. Free stacks immediately and cache them (really easy). Random note: task_current_syscall() (via /proc/$pid/syscall) will probably need additional locking when the stack is freed before the task. signature.asc Description:

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Fri 24-06-16 22:22:55, Oleg Nesterov wrote: > On 06/24, Michal Hocko wrote: > > > > On Fri 24-06-16 16:05:58, Michal Hocko wrote: > > > On Thu 23-06-16 20:52:21, Oleg Nesterov wrote: > > > > > > > > But I agree, this is fixable (and in fact I still hope TIF_MEMDIE will > > > > die, > > > > at

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Fri 24-06-16 22:22:55, Oleg Nesterov wrote: > On 06/24, Michal Hocko wrote: > > > > On Fri 24-06-16 16:05:58, Michal Hocko wrote: > > > On Thu 23-06-16 20:52:21, Oleg Nesterov wrote: > > > > > > > > But I agree, this is fixable (and in fact I still hope TIF_MEMDIE will > > > > die, > > > > at

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Sat, Jun 25, 2016 at 4:30 PM, Andy Lutomirski wrote: > > Maybe I'm misunderstanding the role of release_task. It looks like > there's this path in the scheduler I can borrow: > > if (unlikely(prev_state == TASK_DEAD)) { > > With a kludge in place to free the stack in

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Sat, Jun 25, 2016 at 4:30 PM, Andy Lutomirski wrote: > > Maybe I'm misunderstanding the role of release_task. It looks like > there's this path in the scheduler I can borrow: > > if (unlikely(prev_state == TASK_DEAD)) { > > With a kludge in place to free the stack in there and

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Sat, Jun 25, 2016 at 4:19 PM, Andy Lutomirski wrote: > I rebased my series onto your tree and then rebased this thing onto my > series, tweaked it some, and split it up a bit. My version works a > bit differently (thread_info has a single element if the new option is >

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Sat, Jun 25, 2016 at 4:19 PM, Andy Lutomirski wrote: > I rebased my series onto your tree and then rebased this thing onto my > series, tweaked it some, and split it up a bit. My version works a > bit differently (thread_info has a single element if the new option is > set) but is otherwise

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Fri, Jun 24, 2016 at 7:41 PM, Linus Torvalds wrote: > On Fri, Jun 24, 2016 at 2:34 PM, Andy Lutomirski wrote: >>> >>> So let me get the pure semantic patches done, and then for 4.8 when we >>> do the things that actually change real meaning

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Fri, Jun 24, 2016 at 7:41 PM, Linus Torvalds wrote: > On Fri, Jun 24, 2016 at 2:34 PM, Andy Lutomirski wrote: >>> >>> So let me get the pure semantic patches done, and then for 4.8 when we >>> do the things that actually change real meaning we'll have a sane >>> base. Ok? >> >> Works for me.

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Fri, Jun 24, 2016 at 2:34 PM, Andy Lutomirski wrote: >> >> So let me get the pure semantic patches done, and then for 4.8 when we >> do the things that actually change real meaning we'll have a sane >> base. Ok? > > Works for me. I'll see whether my vmap patches still

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Fri, Jun 24, 2016 at 2:34 PM, Andy Lutomirski wrote: >> >> So let me get the pure semantic patches done, and then for 4.8 when we >> do the things that actually change real meaning we'll have a sane >> base. Ok? > > Works for me. I'll see whether my vmap patches still apply and, if > needed,

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Fri, Jun 24, 2016 at 2:32 PM, Linus Torvalds wrote: > On Fri, Jun 24, 2016 at 2:25 PM, Andy Lutomirski wrote: >> >> What's the prognosis for this patch? Should I queue up all the pieces >> and send them out after the vmap-stack thing? > >

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Fri, Jun 24, 2016 at 2:32 PM, Linus Torvalds wrote: > On Fri, Jun 24, 2016 at 2:25 PM, Andy Lutomirski wrote: >> >> What's the prognosis for this patch? Should I queue up all the pieces >> and send them out after the vmap-stack thing? > > I'm going to split this thing up and apply the

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Fri, Jun 24, 2016 at 2:25 PM, Andy Lutomirski wrote: > > What's the prognosis for this patch? Should I queue up all the pieces > and send them out after the vmap-stack thing? I'm going to split this thing up and apply the "semantically null" cleanup parts. For example,

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Fri, Jun 24, 2016 at 2:25 PM, Andy Lutomirski wrote: > > What's the prognosis for this patch? Should I queue up all the pieces > and send them out after the vmap-stack thing? I'm going to split this thing up and apply the "semantically null" cleanup parts. For example, this patch makes it

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Fri, Jun 24, 2016 at 2:06 PM, Linus Torvalds wrote: > On Fri, Jun 24, 2016 at 1:51 PM, Josh Poimboeuf wrote: >> >> Found another bug: > > Yup. Those two were the ones that kept it from working for me. Thanks. > > Anyway, here's the final

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Fri, Jun 24, 2016 at 2:06 PM, Linus Torvalds wrote: > On Fri, Jun 24, 2016 at 1:51 PM, Josh Poimboeuf wrote: >> >> Found another bug: > > Yup. Those two were the ones that kept it from working for me. Thanks. > > Anyway, here's the final combined patch that works for me on x86-64. > No more

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Fri, Jun 24, 2016 at 11:11:47AM -0700, Linus Torvalds wrote: > On Fri, Jun 24, 2016 at 10:51 AM, Linus Torvalds > wrote: > > > > And in particular, the init_task stack initialization initialized it > > to the init_thread pointer. Which was definitely deadly. > >

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Fri, Jun 24, 2016 at 1:51 PM, Josh Poimboeuf wrote: > > Found another bug: Yup. Those two were the ones that kept it from working for me. Thanks. Anyway, here's the final combined patch that works for me on x86-64. No more thread-info on the stack.

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Fri, Jun 24, 2016 at 11:11:47AM -0700, Linus Torvalds wrote: > On Fri, Jun 24, 2016 at 10:51 AM, Linus Torvalds > wrote: > > > > And in particular, the init_task stack initialization initialized it > > to the init_thread pointer. Which was definitely deadly. > > > > Let's see if that was it..

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Fri, Jun 24, 2016 at 1:51 PM, Josh Poimboeuf wrote: > > Found another bug: Yup. Those two were the ones that kept it from working for me. Thanks. Anyway, here's the final combined patch that works for me on x86-64. No more thread-info on the stack. Linus This is an

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Fri, Jun 24, 2016 at 1:51 PM, Josh Poimboeuf wrote: > On Fri, Jun 24, 2016 at 03:25:30PM -0500, Josh Poimboeuf wrote: >> On Fri, Jun 24, 2016 at 11:11:47AM -0700, Linus Torvalds wrote: >> > On Fri, Jun 24, 2016 at 10:51 AM, Linus Torvalds >> >

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Fri, Jun 24, 2016 at 1:51 PM, Josh Poimboeuf wrote: > On Fri, Jun 24, 2016 at 03:25:30PM -0500, Josh Poimboeuf wrote: >> On Fri, Jun 24, 2016 at 11:11:47AM -0700, Linus Torvalds wrote: >> > On Fri, Jun 24, 2016 at 10:51 AM, Linus Torvalds >> > wrote: >> > > >> > > And in particular, the

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Fri, Jun 24, 2016 at 03:25:30PM -0500, Josh Poimboeuf wrote: > On Fri, Jun 24, 2016 at 11:11:47AM -0700, Linus Torvalds wrote: > > On Fri, Jun 24, 2016 at 10:51 AM, Linus Torvalds > > wrote: > > > > > > And in particular, the init_task stack initialization

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Fri, Jun 24, 2016 at 03:25:30PM -0500, Josh Poimboeuf wrote: > On Fri, Jun 24, 2016 at 11:11:47AM -0700, Linus Torvalds wrote: > > On Fri, Jun 24, 2016 at 10:51 AM, Linus Torvalds > > wrote: > > > > > > And in particular, the init_task stack initialization initialized it > > > to the

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On 06/24, Michal Hocko wrote: > > On Fri 24-06-16 16:05:58, Michal Hocko wrote: > > On Thu 23-06-16 20:52:21, Oleg Nesterov wrote: > > > > > > But I agree, this is fixable (and in fact I still hope TIF_MEMDIE will > > > die, > > > at least in its current form). > > > > We can move the flag to the

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On 06/24, Michal Hocko wrote: > > On Fri 24-06-16 16:05:58, Michal Hocko wrote: > > On Thu 23-06-16 20:52:21, Oleg Nesterov wrote: > > > > > > But I agree, this is fixable (and in fact I still hope TIF_MEMDIE will > > > die, > > > at least in its current form). > > > > We can move the flag to the

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Fri, Jun 24, 2016 at 10:56 AM, Linus Torvalds wrote: > On Fri, Jun 24, 2016 at 10:47 AM, Andy Lutomirski wrote: >> >> FWIW, your patch is much more lenient than my approach. > > I hate big flag-days - they cause so much pain for everybody.

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Fri, Jun 24, 2016 at 10:56 AM, Linus Torvalds wrote: > On Fri, Jun 24, 2016 at 10:47 AM, Andy Lutomirski wrote: >> >> FWIW, your patch is much more lenient than my approach. > > I hate big flag-days - they cause so much pain for everybody. The > people who get it to work and can test it,

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Fri, Jun 24, 2016 at 10:51 AM, Linus Torvalds wrote: > > And in particular, the init_task stack initialization initialized it > to the init_thread pointer. Which was definitely deadly. > > Let's see if that was it.. No, it's still broken. But it's *less* broken,

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Fri, Jun 24, 2016 at 10:51 AM, Linus Torvalds wrote: > > And in particular, the init_task stack initialization initialized it > to the init_thread pointer. Which was definitely deadly. > > Let's see if that was it.. No, it's still broken. But it's *less* broken, so here's a new version of the

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Fri, Jun 24, 2016 at 10:47 AM, Andy Lutomirski wrote: > > FWIW, your patch is much more lenient than my approach. I hate big flag-days - they cause so much pain for everybody. The people who get it to work and can test it, can't test all the other cases (whether they be

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Fri, Jun 24, 2016 at 10:47 AM, Andy Lutomirski wrote: > > FWIW, your patch is much more lenient than my approach. I hate big flag-days - they cause so much pain for everybody. The people who get it to work and can test it, can't test all the other cases (whether they be drivers or other

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Fri, Jun 24, 2016 at 10:40 AM, Linus Torvalds wrote: > > I think I have a few new places to look at.. Yeah, making the 'stack' pointer be 'unsigned long *' rather than 'void *' shows a number of places where we were very confused about things. And in

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Fri, Jun 24, 2016 at 10:40 AM, Linus Torvalds wrote: > > I think I have a few new places to look at.. Yeah, making the 'stack' pointer be 'unsigned long *' rather than 'void *' shows a number of places where we were very confused about things. And in particular, the init_task stack

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Fri, Jun 24, 2016 at 10:40 AM, Linus Torvalds wrote: > On Fri, Jun 24, 2016 at 10:21 AM, Linus Torvalds > wrote: >> >> But as mentioned, I must have missed something. There were a number of >> places where the code used the

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Fri, Jun 24, 2016 at 10:40 AM, Linus Torvalds wrote: > On Fri, Jun 24, 2016 at 10:21 AM, Linus Torvalds > wrote: >> >> But as mentioned, I must have missed something. There were a number of >> places where the code used the task_stack_page() and >> task_thread_info() interchangably, which

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Fri, Jun 24, 2016 at 10:21 AM, Linus Torvalds wrote: > > But as mentioned, I must have missed something. There were a number of > places where the code used the task_stack_page() and > task_thread_info() interchangably, which used to work and is no longer > true.

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Fri, Jun 24, 2016 at 10:21 AM, Linus Torvalds wrote: > > But as mentioned, I must have missed something. There were a number of > places where the code used the task_stack_page() and > task_thread_info() interchangably, which used to work and is no longer > true. There might simply be cases I

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Fri, Jun 24, 2016 at 5:25 AM, Brian Gerst wrote: > * > * rdi: prev task we switched from > + * rsi: task we're switching to > */ > ENTRY(ret_from_fork) > -LOCK ; btr $TIF_FORK, TI_flags(%r8) > +LOCK ; btr $TIF_FORK, TI_flags(%rsi)/* rsi: this newly forked

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Fri, Jun 24, 2016 at 5:25 AM, Brian Gerst wrote: > * > * rdi: prev task we switched from > + * rsi: task we're switching to > */ > ENTRY(ret_from_fork) > -LOCK ; btr $TIF_FORK, TI_flags(%r8) > +LOCK ; btr $TIF_FORK, TI_flags(%rsi)/* rsi: this newly forked task */ > >

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Fri 24-06-16 16:05:58, Michal Hocko wrote: > On Thu 23-06-16 20:52:21, Oleg Nesterov wrote: > > On 06/23, Linus Torvalds wrote: > > > > > > On Thu, Jun 23, 2016 at 10:03 AM, Oleg Nesterov wrote: > > > > > > > > Let me quote my previous email ;) > > > > > > > > And we

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Fri 24-06-16 16:05:58, Michal Hocko wrote: > On Thu 23-06-16 20:52:21, Oleg Nesterov wrote: > > On 06/23, Linus Torvalds wrote: > > > > > > On Thu, Jun 23, 2016 at 10:03 AM, Oleg Nesterov wrote: > > > > > > > > Let me quote my previous email ;) > > > > > > > > And we can't free/nullify

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Thu 23-06-16 20:52:21, Oleg Nesterov wrote: > On 06/23, Linus Torvalds wrote: > > > > On Thu, Jun 23, 2016 at 10:03 AM, Oleg Nesterov wrote: > > > > > > Let me quote my previous email ;) > > > > > > And we can't free/nullify it when the parent/debuger reaps a > > >

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Thu 23-06-16 20:52:21, Oleg Nesterov wrote: > On 06/23, Linus Torvalds wrote: > > > > On Thu, Jun 23, 2016 at 10:03 AM, Oleg Nesterov wrote: > > > > > > Let me quote my previous email ;) > > > > > > And we can't free/nullify it when the parent/debuger reaps a > > > zombie, > > >

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Fri, Jun 24, 2016 at 2:17 AM, Linus Torvalds wrote: > On Thu, Jun 23, 2016 at 12:17 PM, Linus Torvalds > wrote: >> >> With the goal being that I'm hoping that we can then actually get rid >> of this (at least on x86-64, even if we

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Fri, Jun 24, 2016 at 2:17 AM, Linus Torvalds wrote: > On Thu, Jun 23, 2016 at 12:17 PM, Linus Torvalds > wrote: >> >> With the goal being that I'm hoping that we can then actually get rid >> of this (at least on x86-64, even if we leave it in some other >> architectures) in 4.8. > > The

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Thu, Jun 23, 2016 at 12:17 PM, Linus Torvalds wrote: > > With the goal being that I'm hoping that we can then actually get rid > of this (at least on x86-64, even if we leave it in some other > architectures) in 4.8. The context here was that we could almost get

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Thu, Jun 23, 2016 at 12:17 PM, Linus Torvalds wrote: > > With the goal being that I'm hoping that we can then actually get rid > of this (at least on x86-64, even if we leave it in some other > architectures) in 4.8. The context here was that we could almost get rid of thread-info entirely,

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Thu, Jun 23, 2016 at 12:34:24PM -0700, Linus Torvalds wrote: > On Thu, Jun 23, 2016 at 12:11 PM, Peter Zijlstra wrote: > > > > Didn't we talk about using SLAB_DESTROY_BY_RCU for task_struct before? > > If that is possible, a reuse in per-cpu cache is equally possible. > >

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Thu, Jun 23, 2016 at 12:34:24PM -0700, Linus Torvalds wrote: > On Thu, Jun 23, 2016 at 12:11 PM, Peter Zijlstra wrote: > > > > Didn't we talk about using SLAB_DESTROY_BY_RCU for task_struct before? > > If that is possible, a reuse in per-cpu cache is equally possible. > > > > All we really

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Thu, Jun 23, 2016 at 12:11 PM, Peter Zijlstra wrote: > > Didn't we talk about using SLAB_DESTROY_BY_RCU for task_struct before? > If that is possible, a reuse in per-cpu cache is equally possible. > > All we really want to guarantee is that the memory remains a >

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Thu, Jun 23, 2016 at 12:11 PM, Peter Zijlstra wrote: > > Didn't we talk about using SLAB_DESTROY_BY_RCU for task_struct before? > If that is possible, a reuse in per-cpu cache is equally possible. > > All we really want to guarantee is that the memory remains a > task_struct, it need not

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Thu, Jun 23, 2016 at 11:53 AM, Peter Zijlstra wrote: >> >> So the attached patch seems to be the right thing to do regardless of >> this whole discussion. > > Yeah, that looks fine. Want me to take it or will you just commit? I'm committing these trivial non-semantic

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Thu, Jun 23, 2016 at 11:53 AM, Peter Zijlstra wrote: >> >> So the attached patch seems to be the right thing to do regardless of >> this whole discussion. > > Yeah, that looks fine. Want me to take it or will you just commit? I'm committing these trivial non-semantic patches, I'm actually

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Thu, Jun 23, 2016 at 12:09:53PM -0700, Andy Lutomirski wrote: > On Thu, Jun 23, 2016 at 11:53 AM, Peter Zijlstra wrote: > > Yeah, that looks fine. Want me to take it or will you just commit? > > PeterZ, mind if I split it into a couple of patches, test it, and add > it

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Thu, Jun 23, 2016 at 12:09:53PM -0700, Andy Lutomirski wrote: > On Thu, Jun 23, 2016 at 11:53 AM, Peter Zijlstra wrote: > > Yeah, that looks fine. Want me to take it or will you just commit? > > PeterZ, mind if I split it into a couple of patches, test it, and add > it to my series? Not at

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Thu, Jun 23, 2016 at 04:31:26PM +0200, Oleg Nesterov wrote: > On 06/22, Linus Torvalds wrote: > > > > Oleg, what do you think? Would it be reasonable to free the stack and > > thread_info synchronously at exit time, clear the pointer (to catch > > any odd use), and only RCU-delay the

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Thu, Jun 23, 2016 at 04:31:26PM +0200, Oleg Nesterov wrote: > On 06/22, Linus Torvalds wrote: > > > > Oleg, what do you think? Would it be reasonable to free the stack and > > thread_info synchronously at exit time, clear the pointer (to catch > > any odd use), and only RCU-delay the

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Thu, Jun 23, 2016 at 11:53 AM, Peter Zijlstra wrote: > On Thu, Jun 23, 2016 at 10:52:58AM -0700, Linus Torvalds wrote: >> Ugh. Looking around at this, it turns out that a great example of this >> kind of legacy issue is the debug_mutex stuff. >> >> It uses "struct

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Thu, Jun 23, 2016 at 11:53 AM, Peter Zijlstra wrote: > On Thu, Jun 23, 2016 at 10:52:58AM -0700, Linus Torvalds wrote: >> Ugh. Looking around at this, it turns out that a great example of this >> kind of legacy issue is the debug_mutex stuff. >> >> It uses "struct thread_info *" as the owner

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Thu, Jun 23, 2016 at 11:46 AM, Linus Torvalds wrote: > On Thu, Jun 23, 2016 at 10:52 AM, Linus Torvalds > wrote: >> >> Ugh. Looking around at this, it turns out that a great example of this >> kind of legacy issue is the

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Thu, Jun 23, 2016 at 11:46 AM, Linus Torvalds wrote: > On Thu, Jun 23, 2016 at 10:52 AM, Linus Torvalds > wrote: >> >> Ugh. Looking around at this, it turns out that a great example of this >> kind of legacy issue is the debug_mutex stuff. > > Interestingly, the *only* other user of ti->task

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Thu, Jun 23, 2016 at 08:12:16PM +0200, Oleg Nesterov wrote: > > And probably kill task_struct->blocked_on? I do not see the point of > this task->blocked_on != waiter check. I think that came about because of PI and or deadlock detection. Of course, the current mutex code doesn't have

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Thu, Jun 23, 2016 at 08:12:16PM +0200, Oleg Nesterov wrote: > > And probably kill task_struct->blocked_on? I do not see the point of > this task->blocked_on != waiter check. I think that came about because of PI and or deadlock detection. Of course, the current mutex code doesn't have

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Thu, Jun 23, 2016 at 11:00:08AM -0700, Kees Cook wrote: > > Why does __mutex_lock_common() have "task" as a stack variable? That's actually a fairly common thing to do. The reason is that 'current' is far more expensive to evaluate than a local variable.

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Thu, Jun 23, 2016 at 11:00:08AM -0700, Kees Cook wrote: > > Why does __mutex_lock_common() have "task" as a stack variable? That's actually a fairly common thing to do. The reason is that 'current' is far more expensive to evaluate than a local variable.

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Thu, Jun 23, 2016 at 10:52:58AM -0700, Linus Torvalds wrote: > Ugh. Looking around at this, it turns out that a great example of this > kind of legacy issue is the debug_mutex stuff. > > It uses "struct thread_info *" as the owner pointer, and there is _no_ > existing reason for it. In fact,

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Thu, Jun 23, 2016 at 10:52:58AM -0700, Linus Torvalds wrote: > Ugh. Looking around at this, it turns out that a great example of this > kind of legacy issue is the debug_mutex stuff. > > It uses "struct thread_info *" as the owner pointer, and there is _no_ > existing reason for it. In fact,

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On 06/23, Linus Torvalds wrote: > > On Thu, Jun 23, 2016 at 10:03 AM, Oleg Nesterov wrote: > > > > Let me quote my previous email ;) > > > > And we can't free/nullify it when the parent/debuger reaps a zombie, > > say, mark_oom_victim() expects that

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On 06/23, Linus Torvalds wrote: > > On Thu, Jun 23, 2016 at 10:03 AM, Oleg Nesterov wrote: > > > > Let me quote my previous email ;) > > > > And we can't free/nullify it when the parent/debuger reaps a zombie, > > say, mark_oom_victim() expects that get_task_struct() protects > >

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Thu, Jun 23, 2016 at 10:52 AM, Linus Torvalds wrote: > > Ugh. Looking around at this, it turns out that a great example of this > kind of legacy issue is the debug_mutex stuff. Interestingly, the *only* other user of ti->task for a full allmodconfig build of

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Thu, Jun 23, 2016 at 10:52 AM, Linus Torvalds wrote: > > Ugh. Looking around at this, it turns out that a great example of this > kind of legacy issue is the debug_mutex stuff. Interestingly, the *only* other user of ti->task for a full allmodconfig build of x86-64 seems to be

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On 06/23, Linus Torvalds wrote: > > Ugh. Looking around at this, it turns out that a great example of this > kind of legacy issue is the debug_mutex stuff. Heh ;) I am looking at it too. > It uses "struct thread_info *" as the owner pointer, and there is _no_ > existing reason for it. In fact,

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On 06/23, Linus Torvalds wrote: > > Ugh. Looking around at this, it turns out that a great example of this > kind of legacy issue is the debug_mutex stuff. Heh ;) I am looking at it too. > It uses "struct thread_info *" as the owner pointer, and there is _no_ > existing reason for it. In fact,

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Thu, Jun 23, 2016 at 10:52 AM, Linus Torvalds wrote: > On Thu, Jun 23, 2016 at 10:44 AM, Linus Torvalds > wrote: >> >> The thread_info->tsk pointer, that was one of the most critical issues >> and the main raison d'être of the

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Thu, Jun 23, 2016 at 10:52 AM, Linus Torvalds wrote: > On Thu, Jun 23, 2016 at 10:44 AM, Linus Torvalds > wrote: >> >> The thread_info->tsk pointer, that was one of the most critical issues >> and the main raison d'être of the thread_info, has been replaced on >> x86 by just using the per-cpu

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Thu, Jun 23, 2016 at 10:44 AM, Linus Torvalds wrote: > > The thread_info->tsk pointer, that was one of the most critical issues > and the main raison d'être of the thread_info, has been replaced on > x86 by just using the per-cpu "current_task". Yes,.there are

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Thu, Jun 23, 2016 at 10:44 AM, Linus Torvalds wrote: > > The thread_info->tsk pointer, that was one of the most critical issues > and the main raison d'être of the thread_info, has been replaced on > x86 by just using the per-cpu "current_task". Yes,.there are probably > more than a few

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Thu, Jun 23, 2016 at 10:03 AM, Oleg Nesterov wrote: > > Let me quote my previous email ;) > > And we can't free/nullify it when the parent/debuger reaps a zombie, > say, mark_oom_victim() expects that get_task_struct() protects > thread_info as well. >

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Thu, Jun 23, 2016 at 10:03 AM, Oleg Nesterov wrote: > > Let me quote my previous email ;) > > And we can't free/nullify it when the parent/debuger reaps a zombie, > say, mark_oom_victim() expects that get_task_struct() protects > thread_info as well. > > probably we can

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On 06/23, Andy Lutomirski wrote: > > That sounds a bit more fragile than I'm really comfortable with, > although it'll at least oops reliably if we get it wrong. > > But I'm planning on moving ti->flags (and the rest of thread_info, > either piecemeal or as a unit) into task_struct on

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On 06/23, Andy Lutomirski wrote: > > That sounds a bit more fragile than I'm really comfortable with, > although it'll at least oops reliably if we get it wrong. > > But I'm planning on moving ti->flags (and the rest of thread_info, > either piecemeal or as a unit) into task_struct on

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On 06/23, Linus Torvalds wrote: > > But that does bring up another possibility: do it at wait() time, when > we do release_thread(). That's when we *used* to synchronously free > it, before we did the lockless RCU walks. Let me quote my previous email ;) And we can't free/nullify it when

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On 06/23, Linus Torvalds wrote: > > But that does bring up another possibility: do it at wait() time, when > we do release_thread(). That's when we *used* to synchronously free > it, before we did the lockless RCU walks. Let me quote my previous email ;) And we can't free/nullify it when

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Thu, Jun 23, 2016 at 9:30 AM, Linus Torvalds wrote: > On Thu, Jun 23, 2016 at 7:31 AM, Oleg Nesterov wrote: >> >> I didn't see the patches yet, quite possibly I misunderstood... But no, >> I don't this we can do this (if we are not going to move

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Thu, Jun 23, 2016 at 9:30 AM, Linus Torvalds wrote: > On Thu, Jun 23, 2016 at 7:31 AM, Oleg Nesterov wrote: >> >> I didn't see the patches yet, quite possibly I misunderstood... But no, >> I don't this we can do this (if we are not going to move ti->flags to >> task_struct at least). > >

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Thu, Jun 23, 2016 at 7:31 AM, Oleg Nesterov wrote: > > I didn't see the patches yet, quite possibly I misunderstood... But no, > I don't this we can do this (if we are not going to move ti->flags to > task_struct at least). Argh. Yes, ti->flags is used by others. Everything

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Thu, Jun 23, 2016 at 7:31 AM, Oleg Nesterov wrote: > > I didn't see the patches yet, quite possibly I misunderstood... But no, > I don't this we can do this (if we are not going to move ti->flags to > task_struct at least). Argh. Yes, ti->flags is used by others. Everything else should be

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On 06/22, Linus Torvalds wrote: > > Oleg, what do you think? Would it be reasonable to free the stack and > thread_info synchronously at exit time, clear the pointer (to catch > any odd use), and only RCU-delay the task_struct itself? I didn't see the patches yet, quite possibly I

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On 06/22, Linus Torvalds wrote: > > Oleg, what do you think? Would it be reasonable to free the stack and > thread_info synchronously at exit time, clear the pointer (to catch > any odd use), and only RCU-delay the task_struct itself? I didn't see the patches yet, quite possibly I

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Wed, Jun 22, 2016 at 6:22 PM, Andy Lutomirski wrote: > > I implemented a percpu cache, and it's useless. > > When a task goes away, one reference is held until the next RCU grace > period so that task_struct can be used under RCU (look for > delayed_put_task_struct).

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Wed, Jun 22, 2016 at 6:22 PM, Andy Lutomirski wrote: > > I implemented a percpu cache, and it's useless. > > When a task goes away, one reference is held until the next RCU grace > period so that task_struct can be used under RCU (look for > delayed_put_task_struct). Yeah, that RCU batching

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Mon, Jun 20, 2016 at 9:01 PM, Linus Torvalds wrote: > On Mon, Jun 20, 2016 at 4:43 PM, Andy Lutomirski wrote: >> >> On my laptop, this adds about 1.5µs of overhead to task creation, >> which seems to be mainly caused by vmalloc inefficiently

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Mon, Jun 20, 2016 at 9:01 PM, Linus Torvalds wrote: > On Mon, Jun 20, 2016 at 4:43 PM, Andy Lutomirski wrote: >> >> On my laptop, this adds about 1.5µs of overhead to task creation, >> which seems to be mainly caused by vmalloc inefficiently allocating >> individual pages even when a

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Tue, Jun 21, 2016 at 12:47 PM, Andy Lutomirski wrote: > On Tue, Jun 21, 2016 at 12:47 PM, Arnd Bergmann wrote: >> On Tuesday, June 21, 2016 10:16:21 AM CEST Kees Cook wrote: >>> On Tue, Jun 21, 2016 at 2:24 AM, Arnd Bergmann wrote: >>> > On

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Tue, Jun 21, 2016 at 12:47 PM, Andy Lutomirski wrote: > On Tue, Jun 21, 2016 at 12:47 PM, Arnd Bergmann wrote: >> On Tuesday, June 21, 2016 10:16:21 AM CEST Kees Cook wrote: >>> On Tue, Jun 21, 2016 at 2:24 AM, Arnd Bergmann wrote: >>> > On Monday, June 20, 2016 4:43:30 PM CEST Andy

  1   2   >