From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9D01AECDFB0 for ; Thu, 12 Jul 2018 23:08:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 525E120842 for ; Thu, 12 Jul 2018 23:08:37 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 525E120842 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linutronix.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387500AbeGLXUT (ORCPT ); Thu, 12 Jul 2018 19:20:19 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:46071 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1733207AbeGLXUS (ORCPT ); Thu, 12 Jul 2018 19:20:18 -0400 Received: from p4fea482e.dip0.t-ipconnect.de ([79.234.72.46] helo=nanos.glx-home) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1fdkhE-0007hs-IU; Fri, 13 Jul 2018 01:08:24 +0200 Date: Fri, 13 Jul 2018 01:08:23 +0200 (CEST) From: Thomas Gleixner To: Yu-cheng Yu cc: Ingo Molnar , x86@kernel.org, "H. Peter Anvin" , Ingo Molnar , linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-mm@kvack.org, linux-arch@vger.kernel.org, linux-api@vger.kernel.org, Arnd Bergmann , Andy Lutomirski , Balbir Singh , Cyrill Gorcunov , Dave Hansen , Florian Weimer , "H.J. Lu" , Jann Horn , Jonathan Corbet , Kees Cook , Mike Kravetz , Nadav Amit , Oleg Nesterov , Pavel Machek , Peter Zijlstra , "Ravi V. Shankar" , Vedvyas Shanbhogue Subject: Re: [RFC PATCH v2 25/27] x86/cet: Add PTRACE interface for CET In-Reply-To: <1531435034.2965.15.camel@intel.com> Message-ID: References: <20180710222639.8241-1-yu-cheng.yu@intel.com> <20180710222639.8241-26-yu-cheng.yu@intel.com> <20180711102035.GB8574@gmail.com> <1531323638.13297.24.camel@intel.com> <20180712140327.GA7810@gmail.com> <1531435034.2965.15.camel@intel.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8323329-1575887918-1531436904=:1597" X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-1575887918-1531436904=:1597 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT On Thu, 12 Jul 2018, Yu-cheng Yu wrote: > On Thu, 2018-07-12 at 16:03 +0200, Ingo Molnar wrote: > > * Yu-cheng Yu wrote: > > > > > diff --git a/arch/x86/kernel/ptrace.c b/arch/x86/kernel/ptrace.c > > > > > index e2ee403865eb..ac2bc3a18427 100644 > > > > > --- a/arch/x86/kernel/ptrace.c > > > > > +++ b/arch/x86/kernel/ptrace.c > > > > > @@ -49,7 +49,9 @@ enum x86_regset { > > > > >   REGSET_IOPERM64 = REGSET_XFP, > > > > >   REGSET_XSTATE, > > > > >   REGSET_TLS, > > > > > + REGSET_CET64 = REGSET_TLS, > > > > >   REGSET_IOPERM32, > > > > > + REGSET_CET32, > > > > >  }; > > > > Why does REGSET_CET64 alias on REGSET_TLS? > > > In x86_64_regsets[], there is no [REGSET_TLS].  The core dump code > > > cannot handle holes in the array. > > Is there a fundamental (ABI) reason for that? > > What I did was, ran Linux with 'slub_debug', and forced a core dump > (kill -abrt ), then there was a red zone warning in the dmesg. > My feeling is there could be issues in the core dump code.  These Kernel development is not about feelings. Either you can track down the root cause or you cannot. There is no place for feelings and no place in between. And if you cannot track down the root cause and explain it proper then the resulting patch is just papering over the symptoms and will come back to hunt you (or others) sooner than later. No if, no could, no feelings. Facts is what matters. Really. Thanks, tglx --8323329-1575887918-1531436904=:1597-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Gleixner Subject: Re: [RFC PATCH v2 25/27] x86/cet: Add PTRACE interface for CET Date: Fri, 13 Jul 2018 01:08:23 +0200 (CEST) Message-ID: References: <20180710222639.8241-1-yu-cheng.yu@intel.com> <20180710222639.8241-26-yu-cheng.yu@intel.com> <20180711102035.GB8574@gmail.com> <1531323638.13297.24.camel@intel.com> <20180712140327.GA7810@gmail.com> <1531435034.2965.15.camel@intel.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="8323329-1575887918-1531436904=:1597" Return-path: In-Reply-To: <1531435034.2965.15.camel@intel.com> Sender: linux-kernel-owner@vger.kernel.org To: Yu-cheng Yu Cc: Ingo Molnar , x86@kernel.org, "H. Peter Anvin" , Ingo Molnar , linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-mm@kvack.org, linux-arch@vger.kernel.org, linux-api@vger.kernel.org, Arnd Bergmann , Andy Lutomirski , Balbir Singh , Cyrill Gorcunov , Dave Hansen , Florian Weimer , "H.J. Lu" , Jann Horn , Jonathan Corbet , Kees Cook , Mike Kravetz , Nadav Amit , Oleg Nesterov , Pavel Machek , Peter Zijlstra List-Id: linux-api@vger.kernel.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-1575887918-1531436904=:1597 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT On Thu, 12 Jul 2018, Yu-cheng Yu wrote: > On Thu, 2018-07-12 at 16:03 +0200, Ingo Molnar wrote: > > * Yu-cheng Yu wrote: > > > > > diff --git a/arch/x86/kernel/ptrace.c b/arch/x86/kernel/ptrace.c > > > > > index e2ee403865eb..ac2bc3a18427 100644 > > > > > --- a/arch/x86/kernel/ptrace.c > > > > > +++ b/arch/x86/kernel/ptrace.c > > > > > @@ -49,7 +49,9 @@ enum x86_regset { > > > > >   REGSET_IOPERM64 = REGSET_XFP, > > > > >   REGSET_XSTATE, > > > > >   REGSET_TLS, > > > > > + REGSET_CET64 = REGSET_TLS, > > > > >   REGSET_IOPERM32, > > > > > + REGSET_CET32, > > > > >  }; > > > > Why does REGSET_CET64 alias on REGSET_TLS? > > > In x86_64_regsets[], there is no [REGSET_TLS].  The core dump code > > > cannot handle holes in the array. > > Is there a fundamental (ABI) reason for that? > > What I did was, ran Linux with 'slub_debug', and forced a core dump > (kill -abrt ), then there was a red zone warning in the dmesg. > My feeling is there could be issues in the core dump code.  These Kernel development is not about feelings. Either you can track down the root cause or you cannot. There is no place for feelings and no place in between. And if you cannot track down the root cause and explain it proper then the resulting patch is just papering over the symptoms and will come back to hunt you (or others) sooner than later. No if, no could, no feelings. Facts is what matters. Really. Thanks, tglx --8323329-1575887918-1531436904=:1597-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) by kanga.kvack.org (Postfix) with ESMTP id AD8AB6B000A for ; Thu, 12 Jul 2018 19:08:32 -0400 (EDT) Received: by mail-wr1-f72.google.com with SMTP id d7-v6so1455922wre.8 for ; Thu, 12 Jul 2018 16:08:32 -0700 (PDT) Received: from Galois.linutronix.de (Galois.linutronix.de. [2a01:7a0:2:106d:700::1]) by mx.google.com with ESMTPS id i65-v6si4967112wme.74.2018.07.12.16.08.31 for (version=TLS1_2 cipher=AES128-SHA bits=128/128); Thu, 12 Jul 2018 16:08:31 -0700 (PDT) Date: Fri, 13 Jul 2018 01:08:23 +0200 (CEST) From: Thomas Gleixner Subject: Re: [RFC PATCH v2 25/27] x86/cet: Add PTRACE interface for CET In-Reply-To: <1531435034.2965.15.camel@intel.com> Message-ID: References: <20180710222639.8241-1-yu-cheng.yu@intel.com> <20180710222639.8241-26-yu-cheng.yu@intel.com> <20180711102035.GB8574@gmail.com> <1531323638.13297.24.camel@intel.com> <20180712140327.GA7810@gmail.com> <1531435034.2965.15.camel@intel.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8323329-1575887918-1531436904=:1597" Sender: owner-linux-mm@kvack.org List-ID: To: Yu-cheng Yu Cc: Ingo Molnar , x86@kernel.org, "H. Peter Anvin" , Ingo Molnar , linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-mm@kvack.org, linux-arch@vger.kernel.org, linux-api@vger.kernel.org, Arnd Bergmann , Andy Lutomirski , Balbir Singh , Cyrill Gorcunov , Dave Hansen , Florian Weimer , "H.J. Lu" , Jann Horn , Jonathan Corbet , Kees Cook , Mike Kravetz , Nadav Amit , Oleg Nesterov , Pavel Machek , Peter Zijlstra , "Ravi V. Shankar" , Vedvyas Shanbhogue This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-1575887918-1531436904=:1597 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT On Thu, 12 Jul 2018, Yu-cheng Yu wrote: > On Thu, 2018-07-12 at 16:03 +0200, Ingo Molnar wrote: > > * Yu-cheng Yu wrote: > > > > > diff --git a/arch/x86/kernel/ptrace.c b/arch/x86/kernel/ptrace.c > > > > > index e2ee403865eb..ac2bc3a18427 100644 > > > > > --- a/arch/x86/kernel/ptrace.c > > > > > +++ b/arch/x86/kernel/ptrace.c > > > > > @@ -49,7 +49,9 @@ enum x86_regset { > > > > > A REGSET_IOPERM64 = REGSET_XFP, > > > > > A REGSET_XSTATE, > > > > > A REGSET_TLS, > > > > > + REGSET_CET64 = REGSET_TLS, > > > > > A REGSET_IOPERM32, > > > > > + REGSET_CET32, > > > > > A }; > > > > Why does REGSET_CET64 alias on REGSET_TLS? > > > In x86_64_regsets[], there is no [REGSET_TLS]. A The core dump code > > > cannot handle holes in the array. > > Is there a fundamental (ABI) reason for that? > > What I did was, ran Linux with 'slub_debug', and forced a core dump > (kill -abrt ), then there was a red zone warning in the dmesg. > My feeling is there could be issues in the core dump code. A These Kernel development is not about feelings. Either you can track down the root cause or you cannot. There is no place for feelings and no place in between. And if you cannot track down the root cause and explain it proper then the resulting patch is just papering over the symptoms and will come back to hunt you (or others) sooner than later. No if, no could, no feelings. Facts is what matters. Really. Thanks, tglx --8323329-1575887918-1531436904=:1597--