From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751631AbcFXVfW (ORCPT ); Fri, 24 Jun 2016 17:35:22 -0400 Received: from mail-vk0-f52.google.com ([209.85.213.52]:33599 "EHLO mail-vk0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751232AbcFXVfU (ORCPT ); Fri, 24 Jun 2016 17:35:20 -0400 MIME-Version: 1.0 In-Reply-To: References: <20160623185340.GO30154@twins.programming.kicks-ass.net> <20160624202530.unmidps4kpebo2na@treble> <20160624205116.4hbnurrnan4afq2t@treble> From: Andy Lutomirski Date: Fri, 24 Jun 2016 14:34:59 -0700 Message-ID: Subject: Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core) To: Linus Torvalds 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: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 "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? > Works for me. I'll see whether my vmap patches still apply and, if needed, rebase and send a v5. --Andy From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Lutomirski Subject: Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core) Date: Fri, 24 Jun 2016 14:34:59 -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: In-Reply-To: To: Linus Torvalds 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: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 "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? > Works for me. I'll see whether my vmap patches still apply and, if needed, rebase and send a v5. --Andy From mboxrd@z Thu Jan 1 00:00:00 1970 Reply-To: kernel-hardening@lists.openwall.com MIME-Version: 1.0 In-Reply-To: References: <20160623185340.GO30154@twins.programming.kicks-ass.net> <20160624202530.unmidps4kpebo2na@treble> <20160624205116.4hbnurrnan4afq2t@treble> From: Andy Lutomirski Date: Fri, 24 Jun 2016 14:34:59 -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: Linus Torvalds 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: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 "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? > Works for me. I'll see whether my vmap patches still apply and, if needed, rebase and send a v5. --Andy