netdev - Re: pull-request: wireless-next-2024-01-25

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: <20240129115505.76d35e31@kernel.org>
Date: Mon, 29 Jan 2024 11:55:05 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Kalle Valo <kvalo@...nel.org>
Cc: Arend Van Spriel <arend.vanspriel@...adcom.com>,
 <netdev@...r.kernel.org>, <linux-wireless@...r.kernel.org>
Subject: Re: pull-request: wireless-next-2024-01-25

On Sat, 27 Jan 2024 12:08:59 +0200 Kalle Valo wrote:
> Jakub Kicinski <kuba@...nel.org> writes:
> >> I don't run checkpatch except for ath10k/ath11k/ath12k, too much noise.
> >> I ended up adding this to my script:  
> >
> > We run build with sparse and W=1 and then diff the number of warnings 
> > to weed out the pre-existing ones, FWIW.   
> 
> So for wireless and wireless-next I now check W=1 warnings every time I
> push. We are mostly warning free now but I'm not checking the linker
> warnings, for example the current MODULE_DESCRIPTION() warnings.
> 
> It's really annoying, and extra work, that people enable new W=1
> warnings before fixing them. Could we somehow push back on those and
> require that warnings are fixed before enabling with W=1 level?

My quite possibly incorrect understanding is that "giving people time
to fix" is the main point of W=1 :( W=2 is for stuff which may false
positive, W=1 is for stuff which does not false positive but we can't
enable it in formal builds because the tree is full of it.

> In wireless there is a significant number of sparse warnings. I have
> tried the cleanup people to fix them but it seems there's no interest,
> instead we get to receive pointless cleanups wasting our time. <loud sigh>

Tell me about it.. :)

> BTW the 'no new line at end of file' warning is indeed from sparse, like
> Arend suspected:
> 
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil.c:432:49: warning: no newline at end of file

BTW I'd happy to help you set up an instance of our build testing bot,
if you have a VM that can be used. It does take a bit of care and
feeding, but seeing the build failures in patchwork pays the time back.