Messages in this thread | | | Date | Fri, 22 Oct 1999 18:00:35 -0500 | From | Michael Elizabeth Chastain <> | Subject | Re: corrupt modversions.h built in 2.2.13 |
| |
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/
| |