linux-kernel - Re: Ingo, no more kconfig patches

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: <19743.1209873251@turing-police.cc.vt.edu>
Date:	Sat, 03 May 2008 23:54:11 -0400
From:	Valdis.Kletnieks@...edu
To:	Adrian Bunk <bunk@...nel.org>
Cc:	Ingo Molnar <mingo@...e.hu>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	linux-kernel@...r.kernel.org, "Rafael J. Wysocki" <rjw@...k.pl>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: Ingo, no more kconfig patches

On Sun, 04 May 2008 01:03:30 +0300, Adrian Bunk said:
> On Sat, May 03, 2008 at 11:52:14PM +0200, Ingo Molnar wrote:

> > My larger point is that this kconfig tool bug breeds a constant stream 
> > of avoidable breakages, which causes lost manpower and causes a stream 
> > of trivial patches hindering maintainers all around the tree. Because 
> > every such trivial patch has to be reviewed, tested, it clogs the commit 
> > logs, etc.
> > 
> > So the more trivial patches we _avoid_ having to do in the future, the 
> > better. I'm not sure why you are even arguing against this this rather 
> > simple point - your arguments are rather hard to understand. Wouldnt you 
> > be happier if a whole category of trivial breakages was avoided and if 
> > you didnt have to deal with and waste your time on that category of 
> > trivial patches anymore?
> > 
> > Most of the time reoccuring trivial patches are an indicator of some 
> > deeper structural problem - as in this case.
> 
> Your conclusions are based on an assumption that isn't true.
> 
> "trivial patches" are the patches you send.
> 
> But they are often bogus.
> 
> Fixing these issues properly often requires a deeper understanding of 
> both kconfig and the dependencies of the underlying code.

I suspect that Ingo is however correct - although a *proper* fix of one of
these bugs requires human-intelligence to figure out what's *really* intended,
the kconfig program *does* have enough information available to issue a a clear
warning:

"Yo doodz - I don't know *what* you intended here, but this SELECT is just
waiting to sink its teeth into somebody's posterior.  You might want to fix it
somehow before somebody needs rabies shots..."

There's a long tradition of toolchains issuing warnings about things that a
toolchain can detect, but cannot correct - for instance, the gcc 'variable is
used uninitialized' warning (distinct from the broken "may be used" warning).
Given the truly insane amounts of code we merge every cycle, we should take
advantage of every opportunity for automated detection of things that can't
possibly be right.

(Ingo - flame me if I've misread your position here...)


Content of type "application/pgp-signature" skipped