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]
Message-ID: <alpine.DEB.2.20.1804202303350.17045@alpaca>
Date:   Fri, 20 Apr 2018 23:29:33 +0200 (CEST)
From:   Lukas Bulwahn <lukas.bulwahn@...il.com>
To:     Peter Zijlstra <peterz@...radead.org>
cc:     Philipp Klocke <Phil_K97@....de>, lukas.bulwahn@...il.com,
        kernelnewbies@...nelnewbies.org,
        llvmlinux@...ts.linuxfoundation.org, sil2review@...ts.osadl.org,
        der.herr@...r.at, Ingo Molnar <mingo@...hat.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] sched/fair: Change sched_feat(x) in !CONFIG_SCHED_DEBUG
 case


On Fri, 20 Apr 2018, Peter Zijlstra wrote:

> On Fri, Apr 20, 2018 at 06:29:07PM +0200, Philipp Klocke wrote:
> > The gain is stopping a warning that clutters the output log of clang.
> 
> Well, you should not be using clang anyway. It is known to miscompile
> the kernel.
> 

There are some advantages of having a second compiler that can compile
the kernel (https://lwn.net/Articles/734071/). Some people in the kernel 
community and LLVM community are trying to get that to work.

We also want a zero-warning policy for clang, similar to gcc. 
Hence, this motivates to have a look at those few clang warnings and come 
up with patches for them.

This does not imply to make changes at any cost, and we need to determine 
a proper patch to either change the source code, disable the warning in 
the build script or annotate the file with some clang-specific pragmas.

To us, a minor change in the source sounded most reasonable after looking
at all three possible patches. Philipp might need another iteration, but
it generally looks sound to me if we get the details flattened out. 

Lukas

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ