From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751658AbcFXVcq (ORCPT ); Fri, 24 Jun 2016 17:32:46 -0400 Received: from mail-oi0-f49.google.com ([209.85.218.49]:36235 "EHLO mail-oi0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751265AbcFXVcl (ORCPT ); Fri, 24 Jun 2016 17:32:41 -0400 MIME-Version: 1.0 In-Reply-To: References: <20160623185340.GO30154@twins.programming.kicks-ass.net> <20160624202530.unmidps4kpebo2na@treble> <20160624205116.4hbnurrnan4afq2t@treble> From: Linus Torvalds Date: Fri, 24 Jun 2016 14:32:38 -0700 X-Google-Sender-Auth: vSBoZMTm54qadCBeUAS-hbZZ-3c Message-ID: Subject: Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core) To: Andy Lutomirski Cc: Josh Poimboeuf , Brian Gerst , Peter Zijlstra , Oleg Nesterov , Andy Lutomirski , "the arch/x86 maintainers" , Linux Kernel Mailing List , "linux-arch@vger.kernel.org" , Borislav Petkov , Nadav Amit , Kees Cook , "kernel-hardening@lists.openwall.com" , Jann Horn , Heiko Carstens Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 clear that our current "alloc_thread_info_node()" this is entirely insane. We literally do: ti = alloc_thread_info_node(tsk, node); ... tsk->stack = ti; and arch_release_thread_info(tsk->stack); free_thread_info(tsk->stack); and the pure *confusion* there is just crazy. We're talking "tsk->stack", but then we talk about freeing and allocating "thread_info" So I'll apply the whole "rename 'free_thread_info()' into 'free_thread_stack()'" part independently of anything else. It will not change any semantics at all, since we currently have "tsk->stack == thread_info", but it's too ugly to live, and it will then make the patches that *do* change semantics much clearer and easier to see. 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? Linus From mboxrd@z Thu Jan 1 00:00:00 1970 From: Linus Torvalds Subject: Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core) Date: Fri, 24 Jun 2016 14:32:38 -0700 Message-ID: References: <20160623185340.GO30154@twins.programming.kicks-ass.net> <20160624202530.unmidps4kpebo2na@treble> <20160624205116.4hbnurrnan4afq2t@treble> Reply-To: kernel-hardening@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Sender: linus971@gmail.com In-Reply-To: To: Andy Lutomirski Cc: Josh Poimboeuf , Brian Gerst , Peter Zijlstra , Oleg Nesterov , Andy Lutomirski , the arch/x86 maintainers , Linux Kernel Mailing List , "linux-arch@vger.kernel.org" , Borislav Petkov , Nadav Amit , Kees Cook , "kernel-hardening@lists.openwall.com" , Jann Horn , Heiko Carstens List-Id: linux-arch.vger.kernel.org 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 clear that our current "alloc_thread_info_node()" this is entirely insane. We literally do: ti = alloc_thread_info_node(tsk, node); ... tsk->stack = ti; and arch_release_thread_info(tsk->stack); free_thread_info(tsk->stack); and the pure *confusion* there is just crazy. We're talking "tsk->stack", but then we talk about freeing and allocating "thread_info" So I'll apply the whole "rename 'free_thread_info()' into 'free_thread_stack()'" part independently of anything else. It will not change any semantics at all, since we currently have "tsk->stack == thread_info", but it's too ugly to live, and it will then make the patches that *do* change semantics much clearer and easier to see. 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? Linus From mboxrd@z Thu Jan 1 00:00:00 1970 Reply-To: kernel-hardening@lists.openwall.com MIME-Version: 1.0 Sender: linus971@gmail.com In-Reply-To: References: <20160623185340.GO30154@twins.programming.kicks-ass.net> <20160624202530.unmidps4kpebo2na@treble> <20160624205116.4hbnurrnan4afq2t@treble> From: Linus Torvalds Date: Fri, 24 Jun 2016 14:32:38 -0700 Message-ID: Content-Type: text/plain; charset=UTF-8 Subject: [kernel-hardening] Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core) To: Andy Lutomirski Cc: Josh Poimboeuf , Brian Gerst , Peter Zijlstra , Oleg Nesterov , Andy Lutomirski , the arch/x86 maintainers , Linux Kernel Mailing List , "linux-arch@vger.kernel.org" , Borislav Petkov , Nadav Amit , Kees Cook , "kernel-hardening@lists.openwall.com" , Jann Horn , Heiko Carstens List-ID: 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 clear that our current "alloc_thread_info_node()" this is entirely insane. We literally do: ti = alloc_thread_info_node(tsk, node); ... tsk->stack = ti; and arch_release_thread_info(tsk->stack); free_thread_info(tsk->stack); and the pure *confusion* there is just crazy. We're talking "tsk->stack", but then we talk about freeing and allocating "thread_info" So I'll apply the whole "rename 'free_thread_info()' into 'free_thread_stack()'" part independently of anything else. It will not change any semantics at all, since we currently have "tsk->stack == thread_info", but it's too ugly to live, and it will then make the patches that *do* change semantics much clearer and easier to see. 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? Linus