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] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 27 Apr 2018 15:16:04 -0700
From:   Alexei Starovoitov <ast@...com>
To:     Daniel Borkmann <daniel@...earbox.net>, <peterz@...radead.org>,
        <edumazet@...gle.com>, <davem@...emloft.net>,
        <linux-kernel@...r.kernel.org>, <torvalds@...ux-foundation.org>,
        <bp@...en8.de>, <hpa@...or.com>, <mingo@...nel.org>,
        <tglx@...utronix.de>, <linux-tip-commits@...r.kernel.org>,
        <netdev@...r.kernel.org>
Subject: arch/x86/net/bpf_jit_comp conflicts. was: [tip:x86/cleanups] x86/bpf:
 Clean up non-standard comments, to make the code more readable

On 4/27/18 5:13 AM, Daniel Borkmann wrote:
> Hi Ingo,
>
> On 04/27/2018 01:00 PM, tip-bot for Ingo Molnar wrote:
>> Commit-ID:  5f26c50143f58f256535bee8d93a105f36d4d2da
>> Gitweb:     https://git.kernel.org/tip/5f26c50143f58f256535bee8d93a105f36d4d2da
>> Author:     Ingo Molnar <mingo@...nel.org>
>> AuthorDate: Fri, 27 Apr 2018 11:54:40 +0200
>> Committer:  Ingo Molnar <mingo@...nel.org>
>> CommitDate: Fri, 27 Apr 2018 12:42:04 +0200
>>
>> x86/bpf: Clean up non-standard comments, to make the code more readable
>>
>> So by chance I looked into x86 assembly in arch/x86/net/bpf_jit_comp.c and
>> noticed the weird and inconsistent comment style it mistakenly learned from
>> the networking code:
>>
>>  /* Multi-line comment ...
>>   * ... looks like this.
>>   */
>>
>> Fix this to use the standard comment style specified in Documentation/CodingStyle
>> and used in arch/x86/ as well:
>>
>>  /*
>>   * Multi-line comment ...
>>   * ... looks like this.
>>   */
>>
>> Also, to quote Linus's ... more explicit views about this:
>>
>>
>>   > But no, the networking code picked *none* of the above sane formats.
>>   > Instead, it picked these two models that are just half-arsed
>>   > shit-for-brains:
>>   >
>>   >  (no)
>>   >      /* This is disgusting drug-induced
>>   >        * crap, and should die
>>   >        */
>>   >
>>   >   (no-no-no)
>>   >       /* This is also very nasty
>>   >        * and visually unbalanced */
>>   >
>>   > Please. The networking code actually has the *worst* possible comment
>>   > style. You can literally find that (no-no-no) style, which is just
>>   > really horribly disgusting and worse than the otherwise fairly similar
>>   > (d) in pretty much every way.
>>
>> Also improve the comments and some other details while at it:
>>
>>  - Don't mix same-line and previous-line comment style on otherwise
>>    identical code patterns within the same function,
>>
>>  - capitalize 'BPF' and x86 register names consistently,
>>
>>  - capitalize sentences consistently,
>>
>>  - instead of 'x64' use 'x86-64': x64 is a Microsoft specific term,
>>
>>  - use more consistent punctuation,
>>
>>  - use standard coding style in macros as well,
>>
>>  - fix typos and a few other minor details.
>>
>> Consistent coding style is not optional, at least in arch/x86/.
>>
>> No change in functionality.
>
> Thanks for the cleanup, looks fine to me!

same here. thanks for the cleanup!

>> ( In case this commit causes conflicts with pending development code
>>   I'll be glad to help resolve any conflicts! )
>
> Any objections if we would simply route this via bpf-next tree, otherwise
> this will indeed cause really ugly merge conflicts throughout the JIT with
> pending work.

right. would be much better to route this patch via bpf-next.
Though all the changes are cleanups in comments I'm pretty sure
they will conflict with other changes we're doing.

Ingo,
could you please drop this patch from tip tree and resend it to us?
I cannot find the original patch in any public mailing list.
Only in tip-bot notification.

Personally I don't care whether bpf jit code uses networking
or non-networking style of comments, but will be happy to enforce
non-networking for this file in the future, since that seems to be the
preference.

Thanks

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ