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-next>] [day] [month] [year] [list]
Message-Id: <200607301830.01659.jesper.juhl@gmail.com>
Date:	Sun, 30 Jul 2006 18:30:01 +0200
From:	Jesper Juhl <jesper.juhl@...il.com>
To:	linux-kernel@...r.kernel.org
Cc:	Andrew Morton <akpm@...l.org>,
	Nikita Danilov <nikita@...sterfs.com>,
	Joe Perches <joe@...ches.com>,
	Martin Waitz <tali@...ingilde.org>,
	Jan-Benedict Glaw <jbglaw@...-owl.de>,
	Christoph Hellwig <hch@...radead.org>,
	David Woodhouse <dwmw2@...radead.org>,
	Arjan van de Ven <arjan@...radead.org>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Valdis Kletnieks <Valdis.Kletnieks@...edu>,
	Sam Ravnborg <sam@...nborg.org>,
	Russell King <rmk@....linux.org.uk>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Randy Dunlap <rdunlap@...otime.net>,
	Jesper Juhl <jesper.juhl@...il.com>
Subject: [PATCH 00/12] making the kernel -Wshadow clean - The initial step

Ok, here we go again...

This is a series of patches that try to be an initial step towards making
the kernel build -Wshadow clean.

Yeah, I'm persisting with this since I get the impression, from the feedback
I've been getting, that this effort is mostly looked upon favorably.

The reasons why we should do this should be obvious, but I'll list the main
reasons anyway.
In the end the compiler will help us prevent new (and hard to find bugs)
due to symbol shadowing.
It'll help us keep our namespaces separate.
We may find some bugs along the way - and even if it's just one it'll be
worth it :)

I have recieved a lot of useful feedback to the previous patches I've
posted and I've tried to incorporate all the feedback in this series.

There should be no change in behaviour from these patches and it's my hope
that they are acceptable for merging so that, going forward, I will have 
these 12 less to keep track of separately.

A patch to add -Wshadow to the toplevel Makefile is not included since it's
still a little early for that. There are still a lot of warnings that need 
to be fixed, this series is just the first step (but as I think the numbers
below will show, it's a pretty big first step).
I'm only able to work against i386 at the moment, so the results below
probably won't be as nice for other archs, but no need to worry, I do plan
to clean up other archs as well - I just need to get a bunch of
cross-compilers installed.
My plan is to keep submitting new series of patches against -mm (assuming
that these will get merged there) until we are down to less than 100 warnings
for all the standard configs for all archs and then at that point submit a
patch to add -Wshadow to the toplevel Makefile - if someone wants to help
out I'd appreciate it - there are still lots of warnings left to work on, some
of them I've just not gotten to yet, but some of them I'll definately need 
help with as well.


All of this is against 2.6.18-rc3.

Without the patches, adding -Wshadow to the makefile results in these 
warnings for a few different .config's :

allnoconfig
---
$ grep warning build.log.allno | grep shadow | wc -l
1267

allmodconfig
---
$ grep warning build.log.allmod | grep shadow | wc -l
39921

allyesconfig
---
$ grep warning build.log.allyes | grep shadow | wc -l
32477

with my normal workstation config
---
$ grep warning build.log.juhl | grep shadow | wc -l
5298


After applying the patches in this series, quite a different picture
emerges.

allnoconfig :	124 warnings	(~10%)
allmodconfig :	6508 warnings	(~16%)
allyesconfig :	6522 warnings (~20%)
my config :	958 warnings	(~18%)

So with just 12 small patches the number of -Wshadow related warnings is
reduced to between 10 and 20 percent of what they previously were. 
Personally I'd say that's a pretty good first step.

I've added a bunch of people to Cc: on this mail, trying to pick those that
have either responded to my previous attempts or whoes code I'm changing.
I may not have gotten it 100% right, so please bear with me.
I'll not be sending the actual patches to all of you guys - don't want to 
spam your inbox too much. Instead I'll send all 12 patches as a reply to
this email to LKML with just akpm cc.   I hope that's OK with everyone.


Patch series overview : 

[PATCH 00/12] making the kernel -Wshadow clean - The initial step
[PATCH 01/12] making the kernel -Wshadow clean - fix mconf
[PATCH 02/12] making the kernel -Wshadow clean - fix lxdialog
[PATCH 03/12] making the kernel -Wshadow clean - fix jiffies.h
[PATCH 04/12] making the kernel -Wshadow clean - warnings related to 'up'
[PATCH 05/12] making the kernel -Wshadow clean - warnings related to wbc and map_bh
[PATCH 06/12] making the kernel -Wshadow clean - fix checksum
[PATCH 07/12] making the kernel -Wshadow clean - fix vgacon
[PATCH 08/12] making the kernel -Wshadow clean - fix keyboard.c
[PATCH 09/12] making the kernel -Wshadow clean - neighbour.h and 'proc_handler'
[PATCH 10/12] making the kernel -Wshadow clean - mm/truncate.c
[PATCH 11/12] making the kernel -Wshadow clean - USB & completion
[PATCH 12/12] making the kernel -Wshadow clean - 'irq' shadows local and global


-- 
Jesper Juhl <jesper.juhl@...il.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ