From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751526AbdFGA3A (ORCPT ); Tue, 6 Jun 2017 20:29:00 -0400 Received: from mga09.intel.com ([134.134.136.24]:6640 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750766AbdFGA27 (ORCPT ); Tue, 6 Jun 2017 20:28:59 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.39,308,1493708400"; d="scan'208";a="96383374" Message-ID: <1496795332.24288.89.camel@ranerica-desktop> Subject: Re: [PATCH v7 07/26] x86/insn-eval: Do not BUG on invalid register type From: Ricardo Neri To: Borislav Petkov Cc: Ingo Molnar , Thomas Gleixner , "H. Peter Anvin" , Andy Lutomirski , Peter Zijlstra , Andrew Morton , Brian Gerst , Chris Metcalf , Dave Hansen , Paolo Bonzini , Masami Hiramatsu , Huang Rui , Jiri Slaby , Jonathan Corbet , "Michael S. Tsirkin" , Paul Gortmaker , Vlastimil Babka , Chen Yucong , Alexandre Julliard , Stas Sergeev , Fenghua Yu , "Ravi V. Shankar" , Shuah Khan , linux-kernel@vger.kernel.org, x86@kernel.org, linux-msdos@vger.kernel.org, wine-devel@winehq.org, Adam Buchbinder , Colin Ian King , Lorenzo Stoakes , Qiaowei Ren , Arnaldo Carvalho de Melo , Adrian Hunter , Kees Cook , Thomas Garnier , Dmitry Vyukov Date: Tue, 06 Jun 2017 17:28:52 -0700 In-Reply-To: <20170606115842.ei3uowcgxwta2v5g@pd.tnic> References: <20170505181724.55000-1-ricardo.neri-calderon@linux.intel.com> <20170505181724.55000-8-ricardo.neri-calderon@linux.intel.com> <20170529163748.bmihhr4j3hznbhcn@pd.tnic> <1496729218.24288.82.camel@ranerica-desktop> <20170606115842.ei3uowcgxwta2v5g@pd.tnic> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4-0ubuntu2 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2017-06-06 at 13:58 +0200, Borislav Petkov wrote: > On Mon, Jun 05, 2017 at 11:06:58PM -0700, Ricardo Neri wrote: > > I agree that insn-eval reads somewhat funny. I did not want to go with > > insn-dec.c as insn.c, in my opinion, already decodes the instruction > > (i.e., it finds prefixes, opcodes, ModRM, SIB and displacement bytes). > > In insn-eval.c I simply take those decoded parameters and evaluate them > > to obtain the values they contain (e.g., a specific memory location). > > Perhaps, insn-resolve.c could be a better name? Or maybe isnn-operands? > > So actually I'm gravitating towards calling all that instruction > "massaging" code with a single prefix to denote this comes from the insn > decoder/handler/whatever... > > I.e., > > "insn-decoder: x86: invalid register type" > > or > > "inat: x86: invalid register type" > > or something to that effect. > > I mean, If we're going to grow our own - as we do, apparently - maybe it > all should be a separate entity with its proper name. I see. You were more concerned about the naming of the coding artifacts (e.g., function names, error prints, etc) than the actual filenames. I think I have aligned with the function naming of insn.c in all the functions that are exposed via header by using the inns_ prefix. For static functions I don't use that prefix. Perhaps I can use the __ prefix as insn.c does. Thanks and BR, Ricardo From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ricardo Neri Subject: Re: [PATCH v7 07/26] x86/insn-eval: Do not BUG on invalid register type Date: Tue, 06 Jun 2017 17:28:52 -0700 Message-ID: <1496795332.24288.89.camel@ranerica-desktop> References: <20170505181724.55000-1-ricardo.neri-calderon@linux.intel.com> <20170505181724.55000-8-ricardo.neri-calderon@linux.intel.com> <20170529163748.bmihhr4j3hznbhcn@pd.tnic> <1496729218.24288.82.camel@ranerica-desktop> <20170606115842.ei3uowcgxwta2v5g@pd.tnic> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20170606115842.ei3uowcgxwta2v5g@pd.tnic> Sender: linux-kernel-owner@vger.kernel.org List-ID: Content-Type: text/plain; charset="us-ascii" To: Borislav Petkov Cc: Ingo Molnar , Thomas Gleixner , "H. Peter Anvin" , Andy Lutomirski , Peter Zijlstra , Andrew Morton , Brian Gerst , Chris Metcalf , Dave Hansen , Paolo Bonzini , Masami Hiramatsu , Huang Rui , Jiri Slaby , Jonathan Corbet , "Michael S. Tsirkin" , Paul Gortmaker , Vlastimil Babka , Chen Yucong , Alexandre Julliard , Stas Sergeev , Fenghua Yu On Tue, 2017-06-06 at 13:58 +0200, Borislav Petkov wrote: > On Mon, Jun 05, 2017 at 11:06:58PM -0700, Ricardo Neri wrote: > > I agree that insn-eval reads somewhat funny. I did not want to go with > > insn-dec.c as insn.c, in my opinion, already decodes the instruction > > (i.e., it finds prefixes, opcodes, ModRM, SIB and displacement bytes). > > In insn-eval.c I simply take those decoded parameters and evaluate them > > to obtain the values they contain (e.g., a specific memory location). > > Perhaps, insn-resolve.c could be a better name? Or maybe isnn-operands? > > So actually I'm gravitating towards calling all that instruction > "massaging" code with a single prefix to denote this comes from the insn > decoder/handler/whatever... > > I.e., > > "insn-decoder: x86: invalid register type" > > or > > "inat: x86: invalid register type" > > or something to that effect. > > I mean, If we're going to grow our own - as we do, apparently - maybe it > all should be a separate entity with its proper name. I see. You were more concerned about the naming of the coding artifacts (e.g., function names, error prints, etc) than the actual filenames. I think I have aligned with the function naming of insn.c in all the functions that are exposed via header by using the inns_ prefix. For static functions I don't use that prefix. Perhaps I can use the __ prefix as insn.c does. Thanks and BR, Ricardo