linux-kernel - Re: finding unused header files

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]

Message-ID: <1340366312.1773.124.camel@x61.thuisdomein>
Date:	Fri, 22 Jun 2012 13:58:32 +0200
From:	Paul Bolle <pebolle@...cali.nl>
To:	"Robert P. J. Day" <rpjday@...shcourse.ca>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	ysato@...rs.sourceforge.jp
Subject: Re: finding unused header files

On Fri, 2012-06-22 at 06:46 -0400, Robert P. J. Day wrote:
> the script is stupidly conservative and didn't identify that shm.h
> header since *somewhere* in the entire kernel source tree, someone was
> including a file called "shm.h" -- not even for the same architecture.
> like i said, stupidly conservative.

The approach I settled on is, in short, to generate two sets:
I) a set of all header files in the tree;
II) a set of all "paths" used in all the preprocessor include directives
in the tree.
You compare these sets (sort of) backwards, using as little of the paths
in both sets as you can get away with. So sometimes you have a header
"foo.h" and there's not a single include ending in "foo.h": that's an
unused header, and it's easy to spot. But if you do not spot an unused
header that easily, you try whether the long path might also turn up
unused headers, because of mismatches in the earlier parts of the paths
involved. All rather obvious, I guess.

There's a bit more to it - eg, the plain "/asm/" headers generated to
include headers in "/asm-generic/" - but that's the gist of it. Not all
unused headers will be spotted using that approach, but I guess that's a
20/80 rule: 20% of the effort, 80% of the results.

But, whatever approach you take, that's the easy part. The hard part is
peeking at the (history of the) tree to see what happened: was that
header simply never used, did it end up orphaned after changes in other
files, or was it added recently and should we expect a file using that
header to show up in the near future? Figuring all that out turned out
to be time consuming.

Paul Bolle

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