Re: corrupt modversions.h built in 2.2.13

Michael Elizabeth Chastain (mec@shout.net)
Fri, 22 Oct 1999 18:00:35 -0500


Hi Steve,

> I came into this thread late. Yesterday I was bit by a corrupted
> modversions.h file on a make -j 4. This is the first time I've ever seen
> such a thing. Are you saying that the potential's been there all along?

Yes.

"make dep" rebuilds the file include/linux/modversions.h for every file
that has symbols. So if you parallelize "make dep", you will get hit
if the last "make dep" races with the next-to-last. This has been in the
CONFIG_MODVERSIONS design for years.

The race will also occur if a user modifies several files in several
different directories (for example, by applying a patch), and then
runs a parallel "make vmlinux" or "make bzImage", which rebuilds the
*.ver files and then rebuilds include/linux/modversions.h after each
one.

> Without getting into an off-topic debate about recursive makes, I'm
> wondering if there is any reasonable workaround.

My favorite workaround is to remove CONFIG_MODVERSIONS as a supported
feature. If I thought Linus would accept such a patch, I would write
it this weekend.

Short of that, here is a parallel-correct method of managing
include/linux/modversions.h:

(1) In 'make dep' create modversions.h in just one node at the
top of the rule tree. Specifically, do it in Makefile, not
in Rules.make.

(2) In Rules.make, go ahead and make modversions.h depend on
*.ver. *But do not modify the file*. modversions.h is shared
across directories and if you modify a shared file, you will
race.

(3) In Rules.make, if modversions.h is out-of-date with respect to
*.ver, issue an error and tell the user to run 'make dep' again.

(4) While you are in Makefile and Rules.make, put comments in the
top of the file indicating your e-mail address and what you
did to the file. These files need accountable engineering just
like any other portion of the source. Who designed CONFIG_MODVERSIONS,
anyways?

Any takers?

Cranky but not bitter,

Michael

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/