kernel/scripts, branch linux-2.6.29.y

kbuild: fix Module.markers permission error under cygwin

2009-05-08T22:45:04Z

commit 99e3a1eb3c22bb671c6f3d22d8244bfc9fad8185 upstream. While building the kernel, we end-up calling modpost with -K and -M options for the same file (Modules.markers). This is resulting in modpost's main function calling read_markers() and then write_markers() on the same file. We then have read_markers() mmap'ing the file, and writer_markers() opening that same file for writing. The issue is that read_markers() exits without munmap'ing the file and is as a matter holding a reference on Modules.markers. When write_markers() is opening that very same file for writing, we still have a reference on it and cygwin (Windows?) is then making fopen() fail with EPERM. Calling release_file() before exiting read_markers() clears that reference (and memory leak) and fopen() then succeeds. Tested on both cygwin (1.3.22) and Linux. Also ran modpost within valgrind on Linux to make sure that the munmap'ed file was not accessed after read_markers() Signed-off-by: Cedric Hombourger Cc: Signed-off-by: Andrew Morton Signed-off-by: Sam Ravnborg Signed-off-by: Greg Kroah-Hartman

kconfig: improve seed in randconfig

2009-03-15T22:02:07Z

'make randconfig' uses glibc's rand function, and the seed of that PRNG is set via: srand(time(NULL)); But 'time()' only increases once every second - freezing the randconfig result within a single second. My Nehalem testbox does randconfig much faster than 1 second and i have a few scripts that do 'randconfig until condition X' loops. Those scripts currently waste a lot of CPU time due to randconfig changing its seed only once per second currently. Change the seed to be micrseconds based. (I checked the statistical spread of the seed - the now.tv_sec*now.tv_usec multiplication there further improves it.) Signed-off-by: Ingo Molnar Cc: Roman Zippel [sam: fix for systems where usec is zero - noticed by Geert Uytterhoeven] Signed-off-by: Sam Ravnborg

kconfig: fix randconfig for choice blocks

2009-03-15T21:54:57Z

Ingo Molnar reported that 'make randconfig' was not covering choice blocks properly, resulting in certain config options being left out of randconfig testing altogether. With the following patch we: - properly randomize choice value for normal choice blocks - properly randomize for multi choice blocks - added several comments to explain what is going on The root cause of the bug was that SYMBOL_VALID was set on the symbol representing the choice block so clearing this did the trick initially. But testign revealed a few more issues that is now fixed. Reported-by: Ingo Molnar Cc: Ingo Molnar Cc: Roman Zippel Signed-off-by: Sam Ravnborg

kbuild: fix 'make rpm' when CONFIG_LOCALVERSION_AUTO=y and using SCM tree

2009-03-07T12:55:38Z

Running 'make rpm' fails when CONFIG_LOCALVERSION_AUTO=y and using a kernel source tree under SCM. This is due to KERNELRELEASE being different when the initial make is run and when make is run from rpmbuild. mkspec creates kernel.spec using KERNELRELEASE: echo "%files" echo '%defattr (-, root, root)' echo "%dir /lib/modules" echo "/lib/modules/$KERNELRELEASE" echo "/lib/firmware" echo "/boot/*" echo "" When CONFIG_LOCALVERSION_AUTO=y scripts/setlocalversion is called and grabs any additional version info from SCM. Next, the srctree is tarred up and SCM information is excluded. rpmbuild reruns make and in the process generates a new include/config/kernel.release and thus a new KERNELRELEASE. However this time the SCM information is gone so KERNELRELEASE no longer has the additional version information. When "make modules_install" runs, it uses the new KERNELRELEASE value to determine where to install the modules. This conflicts with where the spec file assumes they are going because of the mis-matching KERNELRELEASE versions. + INSTALL_MOD_PATH=/var/tmp/kernel-2.6.29rc4tip01479g5d85422-root + make -j16 modules_install INSTALL crypto/aead.ko INSTALL crypto/cbc.ko INSTALL crypto/chainiv.ko INSTALL crypto/crc32c.ko INSTALL crypto/crypto_algapi.ko INSTALL crypto/crypto_blkcipher.ko INSTALL crypto/crypto_hash.ko INSTALL crypto/cryptomgr.ko INSTALL crypto/ecb.ko INSTALL crypto/eseqiv.ko INSTALL crypto/krng.ko INSTALL crypto/md5.ko INSTALL crypto/pcbc.ko INSTALL crypto/rng.ko INSTALL drivers/block/cciss.ko INSTALL drivers/hid/hid-dummy.ko INSTALL drivers/scsi/iscsi_tcp.ko INSTALL drivers/scsi/libiscsi.ko INSTALL drivers/scsi/libiscsi_tcp.ko INSTALL drivers/scsi/scsi_transport_iscsi.ko INSTALL drivers/scsi/scsi_wait_scan.ko INSTALL fs/lockd/lockd.ko INSTALL fs/nfs/nfs.ko INSTALL fs/nfsd/nfsd.ko INSTALL lib/libcrc32c.ko INSTALL net/sunrpc/sunrpc.ko DEPMOD 2.6.29-rc4-tip + cp arch/x86/boot/bzImage /var/tmp/kernel-2.6.29rc4tip01479g5d85422-root/boot/vmlinuz-2.6.29-rc4-tip-01479-g5d85422 + cp System.map /var/tmp/kernel-2.6.29rc4tip01479g5d85422-root/boot/System.map-2.6.29-rc4-tip-01479-g5d85422 + cp .config /var/tmp/kernel-2.6.29rc4tip01479g5d85422-root/boot/config-2.6.29-rc4-tip-01479-g5d85422 + cp vmlinux vmlinux.orig + bzip2 -9 vmlinux + mv vmlinux.bz2 /var/tmp/kernel-2.6.29rc4tip01479g5d85422-root/boot/vmlinux-2.6.29-rc4-tip-01479-g5d85422.bz2 + mv vmlinux.orig vmlinux + /usr/lib/rpm/brp-compress Processing files: kernel-2.6.29rc4tip01479g5d85422-2 error: File not found: /var/tmp/kernel-2.6.29rc4tip01479g5d85422-root/lib/modules/2.6.29-rc4-tip-01479-g5d85422 RPM build errors: File not found: /var/tmp/kernel-2.6.29rc4tip01479g5d85422-root/lib/modules/2.6.29-rc4-tip-01479-g5d85422 make[1]: *** [rpm] Error 1 make: *** [rpm] Error 2 I have tested this patch on git -tip, Linus' git tree, and the kernel.org tar files, both with and without CONFIG_LOCALVERSION_AUTO=y. Signed-off-by: Josh Hunt Signed-off-by: Sam Ravnborg ----

kbuild: fix mkspec to cleanup RPM_BUILD_ROOT

2009-03-07T12:53:21Z

The contents of the %clean section in mkspec is currently commented out leaving RPM_BUILD_ROOT and its contents on the build machine. This patch removes it once the rpm build process is complete. Signed-off-by: Josh Hunt Signed-off-by: Sam Ravnborg

kbuild: fix C libary confusion in unifdef.c due to getline()

2009-03-07T12:31:29Z

This fixes an error when compiling the kernel. CHK include/linux/version.h HOSTCC scripts/unifdef scripts/unifdef.c:209: error: conflicting types for 'getline' /usr/include/stdio.h:651: note: previous declaration of 'getline' was here make[1]: *** [scripts/unifdef] Error 1 make: *** [__headers] Error 2 Signed-off-by: Justin P. Mattock Cc: Frederic Weisbecker Signed-off-by: Andrew Morton Signed-off-by: Sam Ravnborg

checkpatch: version 0.28

2009-02-28T00:26:22Z

Signed-off-by: Andy Whitcroft Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

checkpatch: add __ref as a sparse modifier

2009-02-28T00:26:22Z

Add __ref as a sparse modifier. Signed-off-by: Andy Whitcroft Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

checkpatch: extend attribute testing to all modifiers

2009-02-28T00:26:22Z

We should allow testing of all modifiers not just attributes. Extend testing and test for all the know modifiers. Signed-off-by: Andy Whitcroft Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

checkpatch: a modifier is not an identifier at the end of a type

2009-02-28T00:26:22Z

We must make sure we do not misrecognise a modifier as an Identifier when trying to match types. Prevent us matching this: void * __ref Signed-off-by: Andy Whitcroft Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds