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: <CR2LNW3CP5YQ.11C2G8ZF14Z9N@vincent-arch>
Date:   Fri, 10 Mar 2023 10:35:59 +0100
From:   "Vincenzo Palazzo" <vincenzopalazzodev@...il.com>
To:     "Greg KH" <gregkh@...uxfoundation.org>
Cc:     <x86@...nel.org>, <luto@...nel.org>,
        <linux-hardening@...r.kernel.org>
Subject: Re: [PATCH v1] x86: suppress warning generated by W=1

On Fri Mar 10, 2023 at 10:28 AM CET, Greg KH wrote:
> On Fri, Mar 10, 2023 at 10:19:53AM +0100, Vincenzo Palazzo wrote:
> > On Fri Mar 10, 2023 at 8:33 AM CET, Greg KH wrote:
> > > On Thu, Mar 09, 2023 at 06:48:54PM +0100, Vincenzo Palazzo wrote:
> > > > suppress unused warnings and fix the error that there is
> > > > with the W=1 enabled.
> > >
> > > Why are you building with that option enabled?  It's not a normal one at
> > > all.
> > 
> > I was using this option because I would like to see if my c code has
> > warnings, but currently it is not possible compile the kernel with 
> > W=1.
>
> Yes, that is the main issue here, the kernel does not build cleanly for
> lots of good reasons (i.e. foolish compiler warnings that are not
> actually pointing out a real problem), so that option is not enabled by
> default right now.

I see, I was missing this info :) thanks!

>
> So this change is not needed right now, perhaps you can fix up the
> compiler to not make this type of warning for code that is correct?

I would happy to, but I am pretty sure that the compiler guys had a
strong option to keep this option enabled.

However, I could try to make an informative email to see if there is any
way to fix this warning without write hacky code.

>
> > Maybe I'm missing a little bit of history here, this is not the correct
> > option to compile the kernel with -Wall?
>
> Yes, but the kernel does not build cleanly with that option, as you have
> found out.  Fixes for when the kernel code is wrong is great to have,
> but not at the expense of "we are doing this only to shut up the
> compiler because it does not understand our code" like you are doing
> here, sorry.

Yep, I see you point and I share your idea to do not try to do this kind 
of suppress work just because the code do not looks like write
in the standart way.

>
> thanks,

Thanks to you for this good information.

Cheers!

Vincent.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ