linux-kernel - Re: [PATCH] x86: squash lines for simple wrapper functions

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAK7LNASxcum=9PLomcZ+=jOxhaPSzhKZuSXX7i6K21YR=qAamw@mail.gmail.com>
Date:   Sat, 10 Sep 2016 18:30:32 +0900
From:   Masahiro Yamada <yamada.masahiro@...ionext.com>
To:     Ingo Molnar <mingo@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>
Cc:     X86 ML <x86@...nel.org>, Ingo Molnar <mingo@...hat.com>,
        Toshi Kani <toshi.kani@....com>,
        Denys Vlasenko <dvlasenk@...hat.com>,
        Borislav Petkov <bp@...e.de>,
        Paul Gortmaker <paul.gortmaker@...driver.com>,
        "H. Peter Anvin" <hpa@...or.com>, Nathan Zimmer <nzimmer@....com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Mike Travis <travis@....com>,
        Daniel J Blueman <daniel@...ascale.com>,
        Dimitri Sivanich <sivanich@....com>,
        Matt Fleming <matt@...eblueprint.co.uk>,
        Hedi Berriche <hedi@....com>,
        Steffen Persvold <sp@...ascale.com>,
        Alex Thorlton <athorlton@....com>,
        Wei Jiangang <weijg.fnst@...fujitsu.com>
Subject: Re: [PATCH] x86: squash lines for simple wrapper functions

Hi Ingo, Thomas,

Thanks for your review!



2016-09-08 15:33 GMT+09:00 Ingo Molnar <mingo@...nel.org>:

>>  static unsigned int flat_get_apic_id(unsigned long x)
>>  {
>> -     unsigned int id;
>> -
>> -     id = (((x)>>24) & 0xFFu);
>> -
>> -     return id;
>> +     return ((x) >> 24) & 0xFFu;
>
> So while we are removing unnecessary things, exactly why does the 'x' need
> parentheses?


I will change it to:

    return (x >> 24) & 0xFF;





>>  static unsigned long set_apic_id(unsigned int id)
>>  {
>> -     unsigned long x;
>> -
>> -     x = ((id & 0xFFu)<<24);
>> -     return x;
>> +     return (id & 0xFFu) << 24;
>
> 'id' is already unsigned, why does the 'u' have to be stressed in the literal?
> (Ditto for other places as well)


I will change it to:

          return (id & 0xFF) << 24;



>>  static unsigned long numachip1_set_apic_id(unsigned int id)
>>  {
>> -     unsigned long x;
>> -
>> -     x = ((id & 0xffU) << 24);
>> -     return x;
>> +     return (id & 0xffU) << 24;
>>  }
>
> Why is the spelling of the literal inconsistent here with the other patterns?


I think 0xff is more consistent than 0xFF
in arch/x86/kernel/apic/apic_numachip.c


Making the constant literals consistent across files
is a too much churn, I think.



>> +++ b/arch/x86/kernel/apic/x2apic_uv_x.c
>> @@ -533,11 +533,8 @@ static unsigned int x2apic_get_apic_id(unsigned long x)
>>
>>  static unsigned long set_apic_id(unsigned int id)
>>  {
>> -     unsigned long x;
>> -
>>       /* maskout x2apic_extra_bits ? */
>> -     x = id;
>> -     return x;
>> +     return id;
>>  }
>
> This was clearly left there to document a quirk and as a placeholder for future
> changes.
>


As suggested by Thomas, I will change it to:

{
         /* CHECKME: Do we need to mask out the xapic extra bits? */
         return id;
}



(I am adding '?' at the comment line.)




If there is no more comment, I will send v2.



-- 
Best Regards
Masahiro Yamada