Re: [PATCH v4 15/17] x86/traps: Fixup general protection faults caused by UMIP

[H. Peter Anvin]

Luck 
From: h...@zytor.com
Message-ID: 

On February 24, 2017 11:36:19 AM PST, Ricardo Neri 
 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 15/17] x86/traps: Fixup general protection faults caused by UMIP

[Ricardo Neri]

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

--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 15/17] x86/traps: Fixup general protection faults caused by UMIP

[Andy Lutomirski]

On Thu, Feb 23, 2017 at 2:15 PM, Ricardo Neri
 wrote:
> On Thu, 2017-02-23 at 10:27 +0100, Peter Zijlstra wrote:
>> On Wed, Feb 22, 2017 at 10:37:04PM -0800, Ricardo Neri wrote:
>> > @@ -492,6 +493,9 @@ do_general_protection(struct pt_regs *regs, long 
>> > error_code)
>> > RCU_LOCKDEP_WARN(!rcu_is_watching(), "entry code didn't wake RCU");
>> > cond_local_irq_enable(regs);
>> >
>> > +   if (user_mode(regs) && (fixup_umip_exception(regs) == true))
>> > +   return;
>>
>> I'm thinking
>>
>>   if (user_mode(regs) && fixup_umip_exception(regs))
>>   return;
>>
>> is actually easier to read.
>
> 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 :)

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 01/17] x86/mpx: Do not use SIB index if index points to R/ESP

[Ricardo Neri]

On Fri, 2017-02-24 at 09:47 -0500, Nathan Howard wrote:
> Also, this code would read better with the inner test
> reversed or done first
> 
> if (indx_offset < 0) {
> if (indx_offset != -EDOM)
> goto out_err;
> indx = 0;
> } else {
> indx = regs_get_register(etc...)
> }
> 
> or
> if (indx_offset == -EDOM)
> indx = 0;
> else if (indx_offset < 0)
> goto err;
> 
> 
> Or goto out_err;
> 
> 
> else
> indx = regs_get_register(etc...)
> 
> The compiler should generate the same code in any
> case, but either could improve reader understanding.
> 
> 
> Also, it may be a tweak more efficient to handle the most likely
> runtime case in the conditional stack first (whichever that may be).

The most likely case will be a positive value but I need to check for
negatives first :( I could wrap the first conditional in an "unlikely".

Thanks and BR,
Ricardo


--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 01/17] x86/mpx: Do not use SIB index if index points to R/ESP

[Adan Hawthorn]

On Thu, Feb 23, 2017 at 9:33 PM, Joe Perches  wrote:
> On Thu, 2017-02-23 at 14:17 -0800, Ricardo Neri wrote:
>> On Thu, 2017-02-23 at 08:24 +0100, Peter Zijlstra wrote:
>> > On Wed, Feb 22, 2017 at 10:36:50PM -0800, Ricardo Neri wrote:
>> > > + /*
>> > > +  * A negative offset generally means a error, except
>> > > +  * -EDOM, which means that the contents of the register
>> > > +  * should not be used as index.
>> > > +  */
>> > >   if (indx_offset < 0)
>> > > - goto out_err;
>> > > + if (indx_offset == -EDOM)
>> > > + indx = 0;
>> > > + else
>> > > + goto out_err;
>> > > + else
>> > > + indx = regs_get_register(regs, indx_offset);
>> >
>> > Kernel coding style requires more brackets than are strictly required by
>> > C, any block longer than 1 line needs then. Also, if one leg of a
>> > conditional needs them, then they should be on both legs.
>> >
>> > Your code has many such instances, please change them all.
>>
>> Will do. Sorry for the noise. These instances escaped the checkpatch
>> script.
>
> Also, this code would read better with the inner test
> reversed or done first
>
> if (indx_offset < 0) {
> if (indx_offset != -EDOM)
> goto out_err;
> indx = 0;
> } else {
> indx = regs_get_register(etc...)
> }
>
> or
> if (indx_offset == -EDOM)
> indx = 0;
> else if (indx_offset < 0)
> goto err;

Or, goto out_err;

> else
> indx = regs_get_register(etc...)
>
> The compiler should generate the same code in any
> case, but either could improve reader understanding.

Also, it may be a tweak more efficient to handle the most likely
runtime case in the conditional stack first (whichever that may be).
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html