From: "Dr. David Alan Gilbert" <linux@treblig.org>
To: linux-kernel@vger.kernel.org
Cc: keescook@chromium.org, nathan@kernel.org, luc.vanoostenryck@gmail.com
Subject: thoughts wanted on dead code hunting?
Date: Thu, 9 May 2024 12:08:56 +0000 [thread overview]
Message-ID: <Zjy82Ja6G2iIHl75@gallifrey> (raw)
Hi,
I've stumbled into finding various types of dead code in the kernel
and am after peoples thoughts and suggestions.
Apologies if this is a bit long.
It started off after I noticed an unused LIST_HEAD in the parallel
code, so I sent some patches to clean that and related code up
(waiting review!), but then wrote a hacky script to find more
(and then mutex's); and there's a handful of patches removing those
on list (please review!).
But then I noticed associated with those were some unused structs;
so I went struct hunting, and that's where I've got a problem.
That's found me ~200 candidates; where I guess 150ish are probably
real; but my hacky script is, well trivial and hacky, so they each
need eyeballing, then a git lookup to see why they're unused, and a
compile just to make there's not some subtle macro somewhere.
** Questions:
a) Can anyone think of a better tool than my script (see bottom)?
The simplicity is a blessing & a curse - it doesn't know about
#ifdef's so I don't need to try lots of configs, but at the same
time, it can't tell if the struct actually gets used in a macro
and I have to eyeball for a struct which is assigned to as
a variable at declaration time.
b) The dead structs are all over; so they've mostly been individual
patches rather than a big patch series - how do people feel about
another 150ish similar patches ?
** other Thoughts
* The dead code is all over; from incredibly obscure drivers, to
common stuff like ftrace and iscsi.
* Most of them seem to be the remains of previous cleanups or
refactors where someone has removed the function that used
it but forgot to remove the list or struct. Sometimes that happened
prior to the first commit, so it's always been dead in the tree.
* There's a few cases where people have added 'static' to a variable
to cleanup compiler warnings, but actually they just needed to
delete the variable.
* A harder problem is unused structure members; some I've spotted
by accident, some follow from what else I delete; e.g. if you
delete a LIST_HEAD, there's a good chance there's a struct somewhere
with the list entry in it that's no longer used.
* It's not just the kernel; I've just mopped up a few struct's in Mesa
as well; but different coding standards make the script harder in
places; e.g. X uses typedef struct... everywhere so then you have
the problem of hunting the use of the typedef name.
Anyway, that's way too long, all thoughts welcome.
(Reviews, even more welcome, as they get merged I'll work through my list
for a few more).
Scripts below,
Dave
(I've cc'd a few people at a guess for people who might suggest tools;
but please copy in anyone else who might)
* hacky script for finding unused LIST_HEAD
(ie print a count of times the name of the list is used in the same file;
if it's 1 it's worth looking at)
ag 'static LIST_HEAD'| sed -e 's/[():]/ /'g |
while read FNAME LINE STATIC DEF VARNAME TRAIL
do
echo ">>>" $FNAME ' : ' $VARNAME
echo -n "Count: "
grep $VARNAME $FNAME | wc -l
grep $VARNAME $FNAME
done
* hacky script for finding unused struct's
(ie print a count of time the name of the struct is used in the same file;
only bother with .c files; doesn't spot assignments to initialise the struct
on later lines, gets confused by struct's with short names etc).
grep -r '^struct [^(=]* {'| tr ':' ' ' |
while read FNAME STRUCT NAME TAIL
do
echo "$FNAME" | grep -q '[.]c$' || continue
echo ">>>" $FNAME ' : ' $NAME
echo -n "Count: "
grep $NAME $FNAME | wc -l
#grep $VARNAME $FNAME
done
--
-----Open up your eyes, open up your mind, open up your code -------
/ Dr. David Alan Gilbert | Running GNU/Linux | Happy \
\ dave @ treblig.org | | In Hex /
\ _________________________|_____ http://www.treblig.org |_______/
next reply other threads:[~2024-05-09 12:08 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-09 12:08 Dr. David Alan Gilbert [this message]
2024-05-15 0:14 ` thoughts wanted on dead code hunting? Kees Cook
2024-05-16 0:40 ` Dr. David Alan Gilbert
2024-05-16 3:24 ` Kees Cook
2024-05-16 11:56 ` Dr. David Alan Gilbert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Zjy82Ja6G2iIHl75@gallifrey \
--to=linux@treblig.org \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luc.vanoostenryck@gmail.com \
--cc=nathan@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox