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: <20200813071949.GG4354@dell>
Date:   Thu, 13 Aug 2020 08:19:49 +0100
From:   Lee Jones <lee.jones@...aro.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: MFD for v5.9

On Wed, 12 Aug 2020, Linus Torvalds wrote:

> On Tue, Aug 11, 2020 at 12:46 AM Lee Jones <lee.jones@...aro.org> wrote:
> >
> > Enjoy!
> 
> No.
> 
> This causes new compiler warnings.

Hmm... that's frustrating.

Mea culpa.  Apologies for this.

As you know this is unheard of from me.
 
> I pulled, did a basic test-compile, and unpulled.
> 
> I refuse to pull garbage that hasn't even seen the most trivial build-test.
> 
> And no, "I built it but didn't check for warnings" is not a build
> test. That's just complete garbage. It's showing the code to the
> compiler, and not bothering to look at what the compiler said about
> it.

Let me give you my 'reason' (I know there is no 'excuse').

I've been grafting on an attempt to rid the kernel of W=1 warnings
this cycle.  Starting with MFD then working through Backlight, SCSI,
Regulator, RemoteProc, IIO, USB, Misc, Pinctrl, GPIO, etc etc, I've
managed to extinguish almost 3000 warnings to date.  I hope to do
something similar this cycle.

Anyway, I forgot to turn W=1 off when testing MFD.  I saw that there
were a couple of warnings, but I (stupidly) assumed that these were
just residue W=1 issues that I would clean-up next cycle.  Not
realising there were 2 real 'unused variable' problems present.

> You can try again next merge window, by now it's too late to send me
> completely untested garbage and try to fix it up.

Could I please urge you to reconsider.  The branch is well tested (in
-next, by private 'kernel test robot' tests and by extensive TuxBuild
testing).  I have cleaned up the offending line (it was just one line
causing the 2 new 'unused variable' issues) and all of my tests are
now passing (with W=1 turned off).  The branch also extinguishes well
over 100 W=1 warnings to boot.  It certainly does more good than
harm.

If you decide stick with your decision however, I'll also understand.

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ