Date: Tue, 16 Apr 2024 11:47:17 +0300
From: Dan Carpenter <dan.carpenter@...aro.org>
To: Ricardo Ribalda <ribalda@...omium.org>
Cc: Martin Tuma <martin.tuma@...iteqautomotive.com>,
	Mauro Carvalho Chehab <mchehab@...nel.org>,
	Laurent Pinchart <laurent.pinchart@...asonboard.com>,
	Hans Verkuil <hverkuil-cisco@...all.nl>,
	Hugues Fruchet <hugues.fruchet@...s.st.com>,
	Alain Volmat <alain.volmat@...s.st.com>,
	Maxime Coquelin <mcoquelin.stm32@...il.com>,
	Alexandre Torgue <alexandre.torgue@...s.st.com>,
	Paul Kocialkowski <paul.kocialkowski@...tlin.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Chen-Yu Tsai <wens@...e.org>,
	Jernej Skrabec <jernej.skrabec@...il.com>,
	Samuel Holland <samuel@...lland.org>,
	Sakari Ailus <sakari.ailus@...ux.intel.com>,
	Thierry Reding <thierry.reding@...il.com>,
	Jonathan Hunter <jonathanh@...dia.com>,
	Sowjanya Komatineni <skomatineni@...dia.com>,
	Luca Ceresoli <luca.ceresoli@...tlin.com>,
	Matthias Brugger <matthias.bgg@...il.com>,
	AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
	Hans Verkuil <hverkuil@...all.nl>, Sergey Kozlov <serjk@...up.ru>,
	Abylay Ospan <aospan@...up.ru>,
	Ezequiel Garcia <ezequiel@...guardiasur.com.ar>,
	Dmitry Osipenko <digetx@...il.com>,
	Stanimir Varbanov <stanimir.k.varbanov@...il.com>,
	Vikash Garodia <quic_vgarodia@...cinc.com>,
	Bryan O'Donoghue <bryan.odonoghue@...aro.org>,
	Bjorn Andersson <andersson@...nel.org>,
	Konrad Dybcio <konrad.dybcio@...aro.org>,
	Benjamin Mugnier <benjamin.mugnier@...s.st.com>,
	Sylvain Petinot <sylvain.petinot@...s.st.com>,
	Jacopo Mondi <jacopo+renesas@...ndi.org>,
	Kieran Bingham <kieran.bingham+renesas@...asonboard.com>,
	Laurent Pinchart <laurent.pinchart+renesas@...asonboard.com>,
	Niklas Söderlund <niklas.soderlund+renesas@...natech.se>,
	Pavel Machek <pavel@....cz>, linux-media@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	linux-stm32@...md-mailman.stormreply.com,
	linux-arm-kernel@...ts.infradead.org, linux-staging@...ts.linux.dev,
	linux-sunxi@...ts.linux.dev, linux-tegra@...r.kernel.org,
	linux-mediatek@...ts.infradead.org, linux-arm-msm@...r.kernel.org,
	Oleg Drokin <green@...uxhacker.ru>
Subject: Re: [PATCH 00/35] media: Fix coccinelle warning/errors

In my opinion, it's better to just ignore old warnings.

When code is new the warnings are going to be mostly correct.  The
original author is there and knows what the code does.  Someone has
the hardware ready to test any changes.  High value, low burden.

When the code is old only the false positives are left.  No one is
testing the code.  It's low value, high burden.

Plus it puts static checker authors in a difficult place because now
people have to work around our mistakes.  It creates animosity.

Now we have to hold ourselves to a much higher standard for false
positives.  It sounds like I'm complaining and lazy, right?  But Oleg
Drokin has told me previously that I spend too much time trying to
silence false positives instead of working on new code.  He's has a
point which is that actually we have limited amount of time and we have
to make choices about what's the most useful thing we can do.

So what I do and what the zero day bot does is we look at warnings one
time and we re-review old warnings whenever a file is changed.

Kernel developers are very good at addressing static checker warnings
and fixing the real issues...  People sometimes ask me to create a
database of warnings which I have reviewed but the answer is that
anything old can be ignored.  As I write this, I've had a thought that
instead of a database of false positives maybe we should record a
database of real bugs to ensure that the fixes for anything real is
applied.

regards,
dan carpenter

Powered by blists - more mailing lists