kernel/linux.git, branch v2.6.23-rc9

Linux 2.6.23-rc9

2007-10-02T03:24:52+00:00

No, I didn't want to do this, but we had more stuff go in after -rc8 than we had in the previous -rc. Gaah.

Merge branch 'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-linus

2007-10-02T03:15:45+00:00

* 'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-linus: [MIPS] vmlinux.lds.S: Handle note sections [MIPS] Fix value of O_TRUNC

x86_64: increase VDSO_TEXT_OFFSET for ancient binutils

2007-10-02T02:21:30+00:00

For some reason old binutils genertate larger headers so increase the text offset of the vdso to avoid linker errors. Roland McGrath explains: "There are extra symbols in the '.dynsym' section that are responsible for the size difference (They also cause corresponding inflation in '.gnu.version') Older ld's wrongly generated these unneeded symbols in .dynsym. This was fixed not all that long ago (2006); binutils-2.17.50.0.6 might be the first fixed version, but I have not verified for sure where the cutoff was. The unneeded symbols et al from old ld add almost 700 bytes excess. This limits fairly tightly the amount by which the actual text and data in the vDSO can grow in the future without pushing the whole file over 4kb. If it does grow later on, we should consider changing the layout with a config option or something to pack it better without that padding, when building the kernel with newer binutils." Signed-off-by: Andi Kleen Cc: Roland McGrath Cc: Badari Pulavarty Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

Fix possible splice() mmap_sem deadlock

2007-10-01T20:17:28+00:00

Nick Piggin points out that splice isn't being good about the mmap semaphore: while two readers can nest inside each others, it does leave a possible deadlock if a writer (ie a new mmap()) comes in during that nesting. Original "just move the locking" patch by Nick, replaced by one by me based on an optimistic pagefault_disable(). And then Jens tested and updated that patch. Reported-by: Nick Piggin Tested-by: Jens Axboe Cc: Andrew Morton Signed-off-by: Linus Torvalds

Merge branch 'fixes-jgarzik' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6

2007-10-01T20:11:48+00:00

* 'fixes-jgarzik' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6: [PATCH] libertas: build problems when partially modular

Merge master.kernel.org:/home/rmk/linux-2.6-arm

2007-10-01T20:08:22+00:00

* master.kernel.org:/home/rmk/linux-2.6-arm: [ARM] Resolve PCI section warnings

Merge branch 'master' of ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/v4l-dvb

2007-10-01T15:02:57+00:00

* 'master' of ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/v4l-dvb: V4L/DVB (6052): ivtv: fix udma yuv bug

Merge branch 'for-linus' of git://oss.sgi.com:8090/xfs/xfs-2.6

2007-10-01T15:01:25+00:00

* 'for-linus' of git://oss.sgi.com:8090/xfs/xfs-2.6: Revert "[XFS] Avoid replaying inode buffer initialisation log items if .. [ Fixed it and added some commit messages by hand to that branch - Linus ] Signed-off-by: Linus Torvalds

Revert "[XFS] Avoid replaying inode buffer initialisation log items if on-disk version is newer."

2007-10-01T14:59:03+00:00

This reverts commit b394e43e995d08821588a22561c6a71a63b4ff27. Lachlan McIlroy says: It tried to fix an issue where log replay is replaying an inode cluster initialisation transaction that should not be replayed because the inode cluster on disk is more up to date. Since we don't log file sizes (we rely on inode flushing to get them to disk) then we can't just replay all the transations in the log and expect the inode to be completely restored. We lose file size updates. Unfortunately this fix is causing more (serious) problems than it is fixing. SGI-PV: 969656 SGI-Modid: xfs-linux-melb:xfs-kern:29804a Signed-off-by: Lachlan McIlroy Signed-off-by: Tim Shimmin

robust futex thread exit race

2007-10-01T14:52:23+00:00

Calling handle_futex_death in exit_robust_list for the different robust mutexes of a thread basically frees the mutex. Another thread might grab the lock immediately which updates the next pointer of the mutex. fetch_robust_entry over the next pointer might therefore branch into the robust mutex list of a different thread. This can cause two problems: 1) some mutexes held by the dead thread are not getting freed and 2) some mutexs held by a different thread are freed. The next point need to be read before calling handle_futex_death. Signed-off-by: Martin Schwidefsky Acked-by: Ingo Molnar Acked-by: Thomas Gleixner Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds