Message-ID: <Zjy82Ja6G2iIHl75@gallifrey>
Date: Thu, 9 May 2024 12:08:56 +0000
From: "Dr. David Alan Gilbert" <linux@...blig.org>
To: linux-kernel@...r.kernel.org
Cc: keescook@...omium.org, nathan@...nel.org, luc.vanoostenryck@...il.com
Subject: thoughts wanted on dead code hunting?

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

Powered by blists - more mailing lists