From: "H. Peter Anvin" <hpa@zytor.com>
To: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>,
Andy Lutomirski <luto@amacapital.net>
Cc: Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Thomas Gleixner <tglx@linutronix.de>,
Andy Lutomirski <luto@kernel.org>, Borislav Petkov <bp@suse.de>,
Andrew Morton <akpm@linux-foundation.org>,
Brian Gerst <brgerst@gmail.com>,
Chris Metcalf <cmetcalf@mellanox.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Liang Z Li <liang.z.li@intel.com>,
Masami Hiramatsu <mhiramat@kernel.org>,
Huang Rui <ray.huang@amd.com>, Jiri Slaby <jslaby@suse.cz>,
Jonathan Corbet <corbet@lwn.net>,
"Michael S. Tsirkin" <mst@redhat.com>,
Paul Gortmaker <paul.gortmaker@windriver.com>,
Vlastimil Babka <vbabka@suse.cz>, Chen Yucong <slaoub@gmail.com>,
Alexandre Julliard <julliard@winehq.org>,
Stas
Subject: Re: [PATCH v4 15/17] x86/traps: Fixup general protection faults caused by UMIP
Date: Fri, 24 Feb 2017 11:45:05 -0800 [thread overview]
Message-ID: <201702241945.v1OJjDKZ011535@mail.zytor.com> (raw)
In-Reply-To: <1487964979.115017.11.camel@ranerica-desktop>
Luck <tony.luck@intel.com>
From: hpa@zytor.com
Message-ID: <C4474E45-EAE0-45D3-8DB1-78AA1C2548A8@zytor.com>
On February 24, 2017 11:36:19 AM PST, Ricardo Neri <ricardo.neri-calderon@linux.intel.com> wrote:
>On Fri, 2017-02-24 at 11:11 -0800, Andy Lutomirski wrote:
>> > In a previous version Andy Lutomirsky suggested that
>> > if (user_mode(regs) && (fixup_umip_exception(regs) == 0))
>> >
>> > was easier to read :). Although at the time fixup_umip_exception
>> > returned a numeric value. Now it only returns true/false for
>> > successful/failed emulation. If with true/false not comparing to
>> true
>> > makes it easier to read, I will make the change.
>>
>> I think == true is silly :)
>
>Then I'll make the change.
>
>Thanks and BR,
>Ricardo
It's worse than silly, it is potentially toxic.
true is a macro which it's defined as 1. Thus
foo == true
... doesn't actually mean what people *think* it does, which is roughly the same thing as
!!foo
However, if foo is not a boolean, this is *very* different; consider if foo is 2.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
next prev parent reply other threads:[~2017-02-24 19:45 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-23 6:36 [PATCH v4 00/17] x86: Enable User-Mode Instruction Prevention Ricardo Neri
2017-02-23 6:36 ` [PATCH v4 01/17] x86/mpx: Do not use SIB index if index points to R/ESP Ricardo Neri
2017-02-23 7:24 ` Peter Zijlstra
2017-02-23 9:50 ` Paul Crawford
2017-02-23 12:47 ` Coding style vs legibility [was Re: [PATCH v4 01/17] x86/mpx: Do not use SIB index if index points to R/ESP] Mouse
2017-02-23 22:17 ` [PATCH v4 01/17] x86/mpx: Do not use SIB index if index points to R/ESP Ricardo Neri
2017-02-24 2:33 ` Joe Perches
2017-02-24 2:41 ` Ricardo Neri
2017-02-24 14:47 ` Nathan Howard
2017-02-24 19:07 ` Ricardo Neri
2017-02-24 15:00 ` Adan Hawthorn
2017-02-23 6:36 ` [PATCH v4 02/17] x86/mpx: Do not use R/EBP as base in the SIB byte with Mod = 0 Ricardo Neri
2017-02-23 6:36 ` [PATCH v4 03/17] x86/mpx, x86/insn: Relocate insn util functions to a new insn-kernel Ricardo Neri
2017-02-23 10:54 ` kbuild test robot
2017-02-23 22:18 ` Ricardo Neri
2017-02-23 6:36 ` [PATCH v4 04/17] x86/insn-eval: Add utility functions to get register offsets Ricardo Neri
2017-02-23 6:36 ` [PATCH v4 05/17] x86/insn-eval: Add utility function to get segment selector Ricardo Neri
2017-02-23 6:36 ` [PATCH v4 06/17] x86/insn-eval: Add utility function to get segment descriptor Ricardo Neri
2017-02-23 6:36 ` [PATCH v4 07/17] x86/insn-eval: Add utility function to get segment descriptor base address Ricardo Neri
2017-02-23 6:36 ` [PATCH v4 08/17] x86/insn-eval: Add functions to get default operand and address sizes Ricardo Neri
2017-02-23 6:36 ` [PATCH v4 09/17] x86/insn-eval: Do not use R/EBP as base if mod in ModRM is zero Ricardo Neri
2017-02-23 6:36 ` [PATCH v4 10/17] insn/eval: Incorporate segment base in address computation Ricardo Neri
2017-02-23 6:37 ` [PATCH v4 11/17] x86/insn-eval: Add support to resolve 16-bit addressing encodings Ricardo Neri
2017-02-23 6:37 ` [PATCH v4 12/17] x86/cpufeature: Add User-Mode Instruction Prevention definitions Ricardo Neri
2017-02-23 6:37 ` [PATCH v4 13/17] x86: Add emulation code for UMIP instructions Ricardo Neri
2017-02-23 6:37 ` [PATCH v4 14/17] x86/umip: Force a page fault when unable to copy emulated result to user Ricardo Neri
2017-02-23 6:37 ` [PATCH v4 15/17] x86/traps: Fixup general protection faults caused by UMIP Ricardo Neri
2017-02-23 9:27 ` Peter Zijlstra
2017-02-23 22:15 ` Ricardo Neri
2017-02-24 19:11 ` Andy Lutomirski
2017-02-24 19:36 ` Ricardo Neri
2017-02-24 19:45 ` H. Peter Anvin [this message]
2017-02-23 6:37 ` [PATCH v4 16/17] x86: Enable User-Mode Instruction Prevention Ricardo Neri
2017-02-23 6:37 ` [PATCH v4 17/17] selftests/x86: Add tests for " Ricardo Neri
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201702241945.v1OJjDKZ011535@mail.zytor.com \
--to=hpa@zytor.com \
--cc=akpm@linux-foundation.org \
--cc=bp@suse.de \
--cc=brgerst@gmail.com \
--cc=cmetcalf@mellanox.com \
--cc=corbet@lwn.net \
--cc=dave.hansen@linux.intel.com \
--cc=jslaby@suse.cz \
--cc=julliard@winehq.org \
--cc=liang.z.li@intel.com \
--cc=luto@amacapital.net \
--cc=luto@kernel.org \
--cc=mhiramat@kernel.org \
--cc=mingo@redhat.com \
--cc=mst@redhat.com \
--cc=paul.gortmaker@windriver.com \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=ray.huang@amd.com \
--cc=ricardo.neri-calderon@linux.intel.com \
--cc=slaoub@gmail.com \
--cc=tglx@linutronix.de \
--cc=vbabka@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox