Hi guys, I've finished the latest set of patches. They're on github at http://github.com/andr345/module-init-tools/commits/elf_cleanup2/ but I am posting them here as well, so you can choose whatever is more convenient for you. The first two (trivial) patches are found in the elf_cleanup branch I started before. After writing those, I added a new branch, elf_cleanup2 before continuing. These tests were performed, and passed: 32-bit (Eee 901) 1. live boot (depmod, modprobe) 2. tests/runtests 64-bit (Core i7) 1. live boot (depmod, modprobe) 2. tests/runtests 3. tests/runtests --valgrind (full set, ~15 minutes) 4. modprobe --dump-modversions i915-32bit.ko 5. modprobe --dump-modversions i915-64bit.ko i915.ko is a random module (kernel/drivers/gpu/drm/i915) picked from the generic kernel in Jaunty, 2.6.28 Result 4 == 5 by the way, so things worked out as expected. I need your input on this patch: ------------------------------- [PATCH 09/16] modprobe: load modules with grab_elf_file_fd() In the old implementation, the loader didn't care about whether a file is an ELF-file or not, and let init_module() sort it out. In the new implementation, the loading fails with errno = ENOEXEC if the file isn't an ELF-file. However, the new logic does not pass the testing, specifically test-modprobe/10alias.sh. To work around this, the commit adds a hack that replicates the old way, when grab_elf_file_fd() does return errno = ENOEXEC. Obviously, this needs to be fixed. To replicate the problem, simply remove the hack. --------------------------------- So, when asked to load a file that is not an elf-file, what should modprobe do? 1. fail silently if (error == warn && !verbose) or 2. always fail noisily, same as if e.g the file didn't exist. Up to this point, case 1 is true. After applying the patch, case 2 would be true, if the hack didn't revert to the old behvior. I'm not sure what the right thing to do is here. Cheers, Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-modules" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
