linux-kernel - Re: [PATCH] init - fix building bug and potential buffer overflow

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]

Date:	Thu, 15 May 2008 18:47:27 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Andrew Morton <akpm@...ux-foundation.org>
cc:	gorcunov@...il.com, geert@...ux-m68k.org, zippel@...ux-m68k.org,
	schwab@...e.de, linux-kernel@...r.kernel.org,
	linux-m68k@...r.kernel.org
Subject: Re: [PATCH] init - fix building bug and potential buffer overflow

On Thu, 15 May 2008, Andrew Morton wrote:
> 
> this, basically:
> 
> >  init/main.c |   78 +++++++++++++++++++++++++++++++----------------------------
> >  1 files changed, 41 insertions(+), 37 deletions(-)
> 
> the dont-mix-bugfixes-and-cleanups mantra.

Sure. I committed them as two separate things.

The point *I* had was that we don't make source code uglier for arbitrary 
reasons. The checkpatch.pl script shouldn't be powerful enough that we do 
uglier source code and break arbitrary rules just to make that script 
happy.

So either we should sy "screw the script, it's wrong", or we should just 
not fix the bug. Or we should say "ok, I can write even _better_ source 
code, and fix the bug, make the source look nicer _and_ not piss off the 
script too".

> > Would somebody please want to move that cast into the macro (or better 
> > yet, make it an inline function that takes a 'void *'), and remove all the 
> > casts from the callers?
> 
> Would be nice.

So I did that too.

		Linus
--
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/