linux-kernel - Re: fault.c cleanup, what else could it be

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]

Date:	Tue, 31 Mar 2009 02:16:16 +0400
From:	Alexey Dobriyan <adobriyan@...il.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Al Viro <viro@...IV.linux.org.uk>, linux-kernel@...r.kernel.org,
	"H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: fault.c cleanup, what else could it be

On Mon, Mar 30, 2009 at 03:49:26AM +0200, Ingo Molnar wrote:
> 
> * Al Viro <viro@...IV.linux.org.uk> wrote:
> 
> > On Mon, Mar 30, 2009 at 03:13:55AM +0200, Ingo Molnar wrote:
> > 
> > > There is simply no excuse for ever having let that crap get there 
> > > into fs/proc/base.c. There is no excuse for ever letting that crap 
> > > grow. The fact that that crap is there is proof of systemic failure 
> > > over the years to keep that code clean.
> > 
> > Nothing like proof by assertion, eh?
> 
> The proof is what i quoted - see below the full dump again. Those 
> are bona fide evidence of unclean code.
> 
> > > I dont really want to see "real work" done on code that was not 
> > > properly and cleanly finished in the first place.
> > 
> > Tough.  At the moment we have a rather unpleasant hole with 
> > tentative fix that touches fs/proc/base.c.  Whether you want said 
> > work postponed until all whitespace wanking is done on file in 
> > question or not, I simply don't give a damn - getting rid of real 
> > bug takes precedence.  Whitespace crap should be dealt with as we 
> > go through the functions containing such crap, religious bullshit 
> > nonwithstanding.
> 
> I am profoundly surprised that something as lightweight and simple 
> as a cleanup patch can make life difficult to you at all. How are 
> you handling them? Have you ever tried?
> 
> > And I very much object against completely unfounded assertions 
> > claiming that checkpatch noise makes a useful proxy for code 
> > quality.  You keep making those again and again, without a shred 
> > of evidence to show.
> 
> You dont have to take my word for it. Look at the output below. 
> Check the code. Compare to the CodingStyle. If it does not match, 
> then it's unclean code that should have been rejected when it got 
> there. Some of that is ancient code, some of that is recent code.
> 
> It might be perfectly fine code otherwise, i made no assertion about 
> the quality of other code in that area.
> 
> 	Ingo
> 
> ---------------->
> ERROR: space required before the open parenthesis '('
> #154: FILE: proc/base.c:154:

I'm finally convinced you do not understand what's going on in this
thread and previous threads on the subject and quitting. There will be
C/R stuff because I already promised and nothing more.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/