commit 07cd82c2b1608187a0d3fd402208a66958d7a960 Author: Greg Kroah-Hartman Date: Fri Feb 20 14:39:34 2009 -0800 Linux 2.6.27.19 commit 06331d79061a3fb0cc63a2e06c183a9c820c85b4 Author: Theodore Ts'o Date: Tue Feb 17 10:58:44 2009 -0500 ext4: Initialize the new group descriptor when resizing the filesystem (cherry picked from commit fdff73f094e7220602cc3f8959c7230517976412) Make sure all of the fields of the group descriptor are properly initialized. Previously, we allowed bg_flags field to be contain random garbage, which could trigger non-deterministic behavior, including a kernel OOPS. http://bugzilla.kernel.org/show_bug.cgi?id=12433 Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit c8b4b2de0fef78500097afb2a114fb632d2951ab Author: Theodore Ts'o Date: Tue Feb 17 10:58:43 2009 -0500 jbd2: On a __journal_expect() assertion failure printk "JBD2", not "EXT3-fs" (cherry picked from commit 08ec8c3878cea0bf91f2ba3c0badf44b383752d0) Otherwise it can be very confusing to find a "EXT3-fs: " failure in the middle of EXT4-fs failures, and it makes it harder to track the source of the failure. Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit fcc8a1931d3a0b7eeb875a9e5eb2e0ea7f32ce8a Author: Theodore Ts'o Date: Tue Feb 17 10:58:42 2009 -0500 ext4: Add sanity check to make_indexed_dir (cherry picked from commit e6b8bc09ba2075cd91fbffefcd2778b1a00bd76f) Make sure the rec_len field in the '..' entry is sane, lest we overrun the directory block and cause a kernel oops on a purposefully corrupted filesystem. Thanks to Sami Liedes for reporting this bug. http://bugzilla.kernel.org/show_bug.cgi?id=12430 Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit d5f85db686df375bd39168bd0032c4be6863f35c Author: Theodore Ts'o Date: Tue Feb 17 10:58:41 2009 -0500 ext4: only use i_size_high for regular files (cherry picked from commit 06a279d636734da32bb62dd2f7b0ade666f65d7c) Directories are not allowed to be bigger than 2GB, so don't use i_size_high for anything other than regular files. E2fsck should complain about these inodes, but the simplest thing to do for the kernel is to only use i_size_high for regular files. This prevents an intentially corrupted filesystem from causing the kernel to burn a huge amount of CPU and issuing error messages such as: EXT4-fs warning (device loop0): ext4_block_to_path: block 135090028 > max Thanks to David Maciejak from Fortinet's FortiGuard Global Security Research Team for reporting this issue. http://bugzilla.kernel.org/show_bug.cgi?id=12375 Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit 235cda408948bb340b37340056e55ca13bd3137f Author: Theodore Ts'o Date: Tue Feb 17 10:58:40 2009 -0500 ext4: Add sanity checks for the superblock before mounting the filesystem (cherry picked from commit 4ec110281379826c5cf6ed14735e47027c3c5765) This avoids insane superblock configurations that could lead to kernel oops due to null pointer derefences. http://bugzilla.kernel.org/show_bug.cgi?id=12371 Thanks to David Maciejak at Fortinet's FortiGuard Global Security Research Team who discovered this bug independently (but at approximately the same time) as Thiemo Nagel, who submitted the patch. Signed-off-by: Thiemo Nagel Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit f8d361c98a108815de00dec15c63a9d161005e9a Author: Aneesh Kumar K.V Date: Tue Feb 17 10:58:39 2009 -0500 ext4: Init the complete page while building buddy cache (cherry picked from commit 29eaf024980e07cc01f31ae4ea5d68c917f4b7da) We need to init the complete page during buddy cache init by setting the contents to '1'. Otherwise we can see the following errors after doing an online resize of the filesystem: EXT4-fs error (device sdb1): ext4_mb_mark_diskspace_used: Allocating block 1040385 in system zone of 127 group Signed-off-by: Aneesh Kumar K.V Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit c1f06cdd2d5f71f17751311631ca4d0ce6dabaf0 Author: Aneesh Kumar K.V Date: Tue Feb 17 10:58:38 2009 -0500 ext4: Don't allow new groups to be added during block allocation (cherry picked from commit 8556e8f3b6c4c11601ce1e9ea8090a6d8bd5daae) After we mark the blocks in the buddy cache as allocated, we need to ensure that we don't reinit the buddy cache until the block bitmap is updated. This commit achieves this by holding the group_info alloc_semaphore till ext4_mb_release_context Signed-off-by: Aneesh Kumar K.V Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit 1272ec19d2305c7b23c4a0b115a8d9530a810b03 Author: Aneesh Kumar K.V Date: Tue Feb 17 10:58:37 2009 -0500 ext4: mark the blocks/inode bitmap beyond end of group as used (cherry picked from commit 648f5879f5892dddd3ba71cd0d285599f40f2512) We need to mark the block/inode bitmap beyond the end of the group with '1'. Signed-off-by: Aneesh Kumar K.V Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit fb1ea4ccbb6c18f38cc5def0831545b2af2a4410 Author: Aneesh Kumar K.V Date: Tue Feb 17 10:58:36 2009 -0500 ext4: Use new buffer_head flag to check uninit group bitmaps initialization (cherry picked from commit 2ccb5fb9f113dae969d1ae9b6c10e80fa34f8cd3) For uninit block group, the ondisk bitmap is not initialized. That implies we cannot depend on the uptodate flag on the bitmap buffer_head to find bitmap validity. Use a new buffer_head flag which would be set after we properly initialize the bitmap. This also prevent the initializing the uninit group bitmap initialization every time we do a ext4_read_block_bitmap. Signed-off-by: Aneesh Kumar K.V Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit 81126650453afa545ce947f5cedbdde1ec78d837 Author: Mark Fasheh Date: Tue Feb 17 10:58:35 2009 -0500 jbd2: Add BH_JBDPrivateStart (cherry picked from commit e97fcd95a4778a8caf1980c6c72fdf68185a0838) Add this so that file systems using JBD2 can safely allocate unused b_state bits. In this case, we add it so that Ocfs2 can define a single bit for tracking the validation state of a buffer. Acked-by: "Theodore Ts'o" Signed-off-by: Mark Fasheh Signed-off-by: Greg Kroah-Hartman commit 783a21ed8a1cc3c64484438c20bbed0f1cca2682 Author: Aneesh Kumar K.V Date: Tue Feb 17 10:58:34 2009 -0500 ext4: Fix the race between read_inode_bitmap() and ext4_new_inode() (cherry picked from commit 393418676a7602e1d7d3f6e560159c65c8cbd50e) We need to make sure we update the inode bitmap and clear EXT4_BG_INODE_UNINIT flag with sb_bgl_lock held, since ext4_read_inode_bitmap() looks at EXT4_BG_INODE_UNINIT to decide whether to initialize the inode bitmap each time it is called. (introduced by commit c806e68f.) ext4_read_inode_bitmap does: spin_lock(sb_bgl_lock(EXT4_SB(sb), block_group)); if (desc->bg_flags & cpu_to_le16(EXT4_BG_INODE_UNINIT)) { ext4_init_inode_bitmap(sb, bh, block_group, desc); and ext4_new_inode does if (!ext4_set_bit_atomic(sb_bgl_lock(sbi, group), ino, inode_bitmap_bh->b_data)) ...... ... spin_lock(sb_bgl_lock(sbi, group)); gdp->bg_flags &= cpu_to_le16(~EXT4_BG_INODE_UNINIT); i.e., on allocation we update the bitmap then we take the sb_bgl_lock and clear the EXT4_BG_INODE_UNINIT flag. What can happen is a parallel ext4_read_inode_bitmap can zero out the bitmap in between the above ext4_set_bit_atomic and spin_lock(sb_bg_lock..) The race results in below user visible errors EXT4-fs error (device sdb1): ext4_free_inode: bit already cleared for inode 168449 EXT4-fs warning (device sdb1): ext4_unlink: Deleting nonexistent file ... EXT4-fs warning (device sdb1): ext4_rmdir: empty directory has too many links ... ls: /mnt/tmp/f/p369/d3/d6/d39/db2/dee/d10f/d3f/l71: Stale NFS file handle Signed-off-by: Aneesh Kumar K.V Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit a07daf9af79b827bff630f6f9be4729de3a54eea Author: Aneesh Kumar K.V Date: Tue Feb 17 10:58:33 2009 -0500 ext4: Fix race between read_block_bitmap() and mark_diskspace_used() (cherry picked from commit e8134b27e351e813414da3b95aa8eac6d3908088) We need to make sure we update the block bitmap and clear EXT4_BG_BLOCK_UNINIT flag with sb_bgl_lock held, since ext4_read_block_bitmap() looks at EXT4_BG_BLOCK_UNINIT to decide whether to initialize the block bitmap each time it is called (introduced by commit c806e68f), and this can race with block allocations in ext4_mb_mark_diskspace_used(). ext4_read_block_bitmap does: spin_lock(sb_bgl_lock(EXT4_SB(sb), block_group)); if (desc->bg_flags & cpu_to_le16(EXT4_BG_BLOCK_UNINIT)) { ext4_init_block_bitmap(sb, bh, block_group, desc); Now on the block allocation side we do mb_set_bits(sb_bgl_lock(sbi, ac->ac_b_ex.fe_group), bitmap_bh->b_data, ac->ac_b_ex.fe_start, ac->ac_b_ex.fe_len); .... spin_lock(sb_bgl_lock(sbi, ac->ac_b_ex.fe_group)); if (gdp->bg_flags & cpu_to_le16(EXT4_BG_BLOCK_UNINIT)) { gdp->bg_flags &= cpu_to_le16(~EXT4_BG_BLOCK_UNINIT); ie on allocation we update the bitmap then we take the sb_bgl_lock and clear the EXT4_BG_BLOCK_UNINIT flag. What can happen is a parallel ext4_read_block_bitmap can zero out the bitmap in between the above mb_set_bits and spin_lock(sb_bg_lock..) The race results in below user visible errors EXT4-fs error (device sdb1): ext4_mb_release_inode_pa: free 100, pa_free 105 EXT4-fs error (device sdb1): mb_free_blocks: double-free of inode 0's block .. Signed-off-by: Aneesh Kumar K.V Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit 919a7cd36ae67ccc0a5e44b7a44a96065b11aa01 Author: Aneesh Kumar K.V Date: Tue Feb 17 10:58:32 2009 -0500 ext4: don't use blocks freed but not yet committed in buddy cache init (cherry picked from commit 7a2fcbf7f85737735fd44eb34b62315bccf6d6e4) When we generate buddy cache (especially during resize) we need to make sure we don't use the blocks freed but not yet comitted. This makes sure we have the right value of free blocks count in the group info and also in the bitmap. This also ensures the ordered mode consistency Signed-off-by: Aneesh Kumar K.V Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit aa85265e767b75ac643c347763c2d8e0a7e5e79b Author: Aneesh Kumar K.V Date: Tue Feb 17 10:58:31 2009 -0500 ext4: Use an rbtree for tracking blocks freed during transaction. (cherry picked from commit c894058d66637c7720569fbe12957f4de64d9991 to allow commit e21675d4 to be included in 2.6.27.y) With this patch we track the block freed during a transaction using red-black tree. We also make sure contiguous blocks freed are collected in one node in the tree. Signed-off-by: Aneesh Kumar K.V Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 90cefd4942630062f76fbb6dd4f7fe4a7bb08c89 Author: Aneesh Kumar K.V Date: Tue Feb 17 10:58:30 2009 -0500 ext4: cleanup mballoc header files (cherry picked from commit c3a326a657562dab81acf05aee106dc1fe345eb4) Move some of the forward declaration of the static functions to mballoc.c where they are used. This enables us to include mballoc.h in other .c files. Also correct the buddy cache documentation. Signed-off-by: Aneesh Kumar K.V Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit c6663331bd67be8328f4b1120a0a972d2d77c8fc Author: Aneesh Kumar K.V Date: Tue Feb 17 10:58:29 2009 -0500 ext4: Use EXT4_GROUP_INFO_NEED_INIT_BIT during resize (cherry picked from commit 920313a726e04fef0f2c0bcb04ad8229c0e700d8) The new groups added during resize are flagged as need_init group. Make sure we properly initialize these groups. When we have block size < page size and we are adding new groups the page may still be marked uptodate even though we haven't initialized the group. While forcing the init of buddy cache we need to make sure other groups part of the same page of buddy cache is not using the cache. group_info->alloc_sem is added to ensure the same. Signed-off-by: Aneesh Kumar K.V Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit ad74730d9c36f6a2b96980319c087abb8e0eb63b Author: Aneesh Kumar K.V Date: Tue Feb 17 10:58:28 2009 -0500 ext4: Add blocks added during resize to bitmap (cherry picked from commit e21675d4b63975d09eb75c443c48ebe663d23e18) With this change new blocks added during resize are marked as free in the block bitmap and the group is flagged with EXT4_GROUP_INFO_NEED_INIT_BIT flag. This make sure when mballoc tries to allocate blocks from the new group we would reload the buddy information using the bitmap present in the disk. Signed-off-by: Aneesh Kumar K.V Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit 35c2e60c9f3eae8505c31ddd6166fa3ea0c76802 Author: Aneesh Kumar K.V Date: Tue Feb 17 10:58:27 2009 -0500 ext4: Don't overwrite allocation_context ac_status (cherry picked from commit 032115fcef837a00336ddf7bda584e89789ea498) We can call ext4_mb_check_limits even after successfully allocating the requested blocks. In that case, make sure we don't overwrite ac_status if it already has the status AC_STATUS_FOUND. This fixes the lockdep warning: ============================================= [ INFO: possible recursive locking detected ] 2.6.28-rc6-autokern1 #1 --------------------------------------------- fsstress/11948 is trying to acquire lock: (&meta_group_info[i]->alloc_sem){----}, at: [] ext4_mb_load_buddy+0x9f/0x278 ..... stack backtrace: ..... [] ext4_mb_regular_allocator+0xbb5/0xd44 ..... but task is already holding lock: (&meta_group_info[i]->alloc_sem){----}, at: [] ext4_mb_load_buddy+0x9f/0x278 Signed-off-by: Aneesh Kumar K.V Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit bd8a233eea26fc037aaf5cccc2bb9c5b814740a4 Author: Theodore Ts'o Date: Tue Feb 17 10:58:26 2009 -0500 jbd2: Add barrier not supported test to journal_wait_on_commit_record (cherry picked from commit fd98496f467b3d26d05ab1498f41718b5ef13de5) Xen doesn't report that barriers are not supported until buffer I/O is reported as completed, instead of when the buffer I/O is submitted. Add a check and a fallback codepath to journal_wait_on_commit_record() to detect this case, so that attempts to mount ext4 filesystems on LVM/devicemapper devices on Xen guests don't blow up with an "Aborting journal on device XXX"; "Remounting filesystem read-only" error. Thanks to Andreas Sundstrom for reporting this issue. Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit 16cde8908e8b7145d61a5e0e25505966df66d7ee Author: Yasunori Goto Date: Tue Feb 17 10:58:25 2009 -0500 ext4: Widen type of ext4_sb_info.s_mb_maxs[] (cherry picked from commit ff7ef329b268b603ea4a2303241ef1c3829fd574) I chased the cause of following ext4 oops report which is tested on ia64 box. http://bugzilla.kernel.org/show_bug.cgi?id=12018 The cause is the size of s_mb_maxs array that is defined as "unsigned short" in ext4_sb_info structure. If the file system's block size is 8k or greater, an unsigned short is not wide enough to contain the value fs->blocksize << 3. Signed-off-by: Yasunori Goto Signed-off-by: "Theodore Ts'o" Cc: Li Zefan Cc: Miao Xie Signed-off-by: Greg Kroah-Hartman commit cd61588ffacc0e13effc28feef1d762f3fd580b5 Author: Aneesh Kumar K.V Date: Tue Feb 17 10:58:24 2009 -0500 ext4: avoid ext4_error when mounting a fs with a single bg (cherry picked from commit 565a9617b2151e21b22700e97a8b04e70e103153) Remove some completely unneeded code which which caused an ext4_error to be generated when mounting a file system with only a single block group. Signed-off-by: Aneesh Kumar K.V Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit 5fc757c07fa5b4eab0e61f60b498cff66e619111 Author: Aneesh Kumar K.V Date: Tue Feb 17 10:58:23 2009 -0500 ext4: Fix the delalloc writepages to allocate blocks at the right offset. (cherry picked from commit 791b7f08954869d7b8ff438f3dac3cfb39778297) When iterating through the pages which have mapped buffer_heads, we failed to update the b_state value. This results in allocating blocks at logical offset 0. Signed-off-by: Aneesh Kumar K.V Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit 916d7904b539f8d44af818f54a41f63ef2a0e78f Author: Theodore Ts'o Date: Tue Feb 17 10:58:22 2009 -0500 ext4: tone down ext4_da_writepages warnings (cherry picked from commit 2a21e37e48b94388f2cc8c0392f104f5443d4bb8) If the filesystem has errors, ext4_da_writepages() will return a *lot* of errors, including lots and lots of stack dumps. While it's true that we are dropping user data on the floor, which is unfortunate, the stack dumps aren't helpful, and they tend to obscure the true original root cause of the problem. So in the case where the filesystem has aborted, return an EROFS right away. Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit 4836aa18f91a2bb43207810e0283285202f01fd7 Author: Theodore Ts'o Date: Tue Feb 17 10:58:21 2009 -0500 ext4: Add support for non-native signed/unsigned htree hash algorithms (cherry picked from commit f99b25897a86fcfff9140396a97261ae65fed872) The original ext3 hash algorithms assumed that variables of type char were signed, as God and K&R intended. Unfortunately, this assumption is not true on some architectures. Userspace support for marking filesystems with non-native signed/unsigned chars was added two years ago, but the kernel-side support was never added (until now). Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit f0bc833ff5ca8f4dba884b2eb95116e0da36185b Author: Jeremy Fitzhardinge Date: Wed Feb 11 09:32:19 2009 -0800 x86/cpa: make sure cpa is safe to call in lazy mmu mode commit 4f06b0436b2ddbd3b67b10e77098a6862787b3eb upstream. Impact: fix race leading to crash under KVM and Xen The CPA code may be called while we're in lazy mmu update mode - for example, when using DEBUG_PAGE_ALLOC and doing a slab allocation in an interrupt handler which interrupted a lazy mmu update. In this case, the in-memory pagetable state may be out of date due to pending queued updates. We need to flush any pending updates before inspecting the page table. Similarly, we must explicitly flush any modifications CPA may have made (which comes down to flushing queued operations when flushing the TLB). Signed-off-by: Jeremy Fitzhardinge Acked-by: Marcelo Tosatti Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit f5d4c866a840c054c7561caee0d77980c993a118 Author: Mike Christie Date: Fri Jan 16 12:36:51 2009 -0600 SCSI: libiscsi: fix iscsi pool leak commit 2f5899a39dcffb404c9a3d06ad438aff3e03bf04 upstream. I am not sure what happened. It looks like we have always leaked the q->queue that is allocated from the kfifo_init call. nab finally noticed that we were leaking and this patch fixes it by adding a kfree call to iscsi_pool_free. kfifo_free is not used per kfifo_init's instructions to use kfree. Signed-off-by: Mike Christie Signed-off-by: James Bottomley Cc: Jean Delvare Signed-off-by: Greg Kroah-Hartman commit 2e26581c7426e1dc716d1507422b6367c8b129b8 Author: Carsten Otte Date: Wed Feb 11 13:04:37 2009 -0800 ext2/xip: refuse to change xip flag during remount with busy inodes commit 0e4a9b59282914fe057ab17027f55123964bc2e2 upstream. For a reason that I was unable to understand in three months of debugging, mount ext2 -o remount stopped working properly when remounting from regular operation to xip, or the other way around. According to a git bisect search, the problem was introduced with the VM_MIXEDMAP/PTE_SPECIAL rework in the vm: commit 70688e4dd1647f0ceb502bbd5964fa344c5eb411 Author: Nick Piggin Date: Mon Apr 28 02:13:02 2008 -0700 xip: support non-struct page backed memory In the failing scenario, the filesystem is mounted read only via root= kernel parameter on s390x. During remount (in rc.sysinit), the inodes of the bash binary and its libraries are busy and cannot be invalidated (the bash which is running rc.sysinit resides on subject filesystem). Afterwards, another bash process (running ifup-eth) recurses into a subshell, runs dup_mm (via fork). Some of the mappings in this bash process were created from inodes that could not be invalidated during remount. Both parent and child process crash some time later due to inconsistencies in their address spaces. The issue seems to be timing sensitive, various attempts to recreate it have failed. This patch refuses to change the xip flag during remount in case some inodes cannot be invalidated. This patch keeps users from running into that issue. [akpm@linux-foundation.org: cleanup] Signed-off-by: Carsten Otte Cc: Nick Piggin Cc: Jared Hulbert Cc: Martin Schwidefsky Cc: Heiko Carstens Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit a307691bfb50cc184c1337abf15204af3e0f1685 Author: Sergio Luis Date: Sun Oct 26 23:08:48 2008 -0700 btsdio: free sk_buff with kfree_skb commit cbfd24a75f98fe731547d3bc995f3a1f1fed6b20 upstream. free sk_buff with kfree_skb, instead of kree Signed-off-by: Sergio Luis Signed-off-by: David S. Miller Cc: Tomas Winkler Signed-off-by: Greg Kroah-Hartman commit 0338cfe915f96ff15f1c2902ee19f9ee3c41478d Author: Tomas Winkler Date: Sun Nov 30 12:17:18 2008 +0100 Bluetooth: Fix TX error path in btsdio driver commit 7644d63d1348ec044ccd8f775fefe5eb7cbcac69 upstream. This patch fixes accumulating of the header in case packet was requeued in the error path. Signed-off-by: Tomas Winkler Signed-off-by: Marcel Holtmann Signed-off-by: Greg Kroah-Hartman commit 466909ba06d0bfd5423cd5ca9bea22e43384377e Author: Zlatko Calusic Date: Wed Feb 18 01:33:34 2009 +0100 Add support for VT6415 PCIE PATA IDE Host Controller commit 5955c7a2cfb6a35429adea5dc480002b15ca8cfc upstream. Signed-off-by: Zlatko Calusic Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 462fe2b74124670a344752861c2bccf3f15c95df Author: Roel Kluin Date: Thu Feb 12 16:52:31 2009 -0800 3c505: do not set pcb->data.raw beyond its size commit 501aa061bd68169a5b54c123641f8dfa9ad31545 upstream. Ensure that we do not set pcb->data.raw beyond its size, print an error message and return false if we attempt to. A timout message was printed one too early. Signed-off-by: Roel Kluin Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 2da462eba7e5b585d54c17d76c6a662e4fbb3c32 Author: Tejun Heo Date: Thu Feb 12 10:34:32 2009 +0900 sata_nv: give up hardreset on nf2 commit 7dac745b8e367c99175b8f0d014d996f0e5ed9e5 upstream. Kernel bz#12176 reports that nf2 hardreset simply doesn't work. Give up. Argh... Signed-off-by: Tejun Heo Cc: Robert Hancock Reported-by: Saro Signed-off-by: Jeff Garzik Signed-off-by: Greg Kroah-Hartman commit 308151183cd07fc0cbce0404dbd04259ac9d2a41 Author: Michael Neuling Date: Thu Feb 12 19:08:58 2009 +0000 powerpc/vsx: Fix VSX alignment handler for regs 32-63 commit 26456dcfb8d8e43b1b64b2a14710694cf7a72f05 upstream. Fix the VSX alignment handler for VSX registers > 32. 32-63 are stored in the VMX part of the thread_struct not the FPR part. Signed-off-by: Michael Neuling Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit 06d36fce36d9b5bd879f92db2dfe5ce755389d53 Author: David Woodhouse Date: Fri Feb 13 23:18:03 2009 +0000 Fix Intel IOMMU write-buffer flushing commit ca77fde8e62cecb2c0769052228d15b901367af8 upstream. This is the cause of the DMA faults and disk corruption that people have been seeing. Some chipsets neglect to report the RWBF "capability" -- the flag which says that we need to flush the chipset write-buffer when changing the DMA page tables, to ensure that the change is visible to the IOMMU. Override that bit on the affected chipsets, and everything is happy again. Thanks to Chris and Bhavesh and others for helping to debug. Signed-off-by: David Woodhouse Tested-by: Chris Wright Reviewed-by: Bhavesh Davda Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 727cfccf7228713b733297207ae26aa97858f126 Author: Sukadev Bhattiprolu Date: Wed Jan 7 18:08:50 2009 -0800 mqueue: fix si_pid value in mqueue do_notify() commit a6684999f7c6bddd75cf9755ad7ff44435f72fff upstream. If a process registers for asynchronous notification on a POSIX message queue, it gets a signal and a siginfo_t structure when a message arrives on the message queue. The si_pid in the siginfo_t structure is set to the PID of the process that sent the message to the message queue. The principle is the following: . when mq_notify(SIGEV_SIGNAL) is called, the caller registers for notification when a msg arrives. The associated pid structure is stroed into inode_info->notify_owner. Let's call this process P1. . when mq_send() is called by say P2, P2 sends a signal to P1 to notify him about msg arrival. The way .si_pid is set today is not correct, since it doesn't take into account the fact that the process that is sending the message might not be in the same namespace as the notified one. This patch proposes to set si_pid to the sender's pid into the notify_owner namespace. Signed-off-by: Nadia Derbey Signed-off-by: Sukadev Bhattiprolu Acked-by: Oleg Nesterov Cc: Roland McGrath Cc: Bastian Blank Cc: Pavel Emelyanov Cc: Eric W. Biederman Acked-by: Serge Hallyn Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 724313bf0904f351b8e1c099e14e00f10fe15242 Author: Eric W. Biederman Date: Wed Jan 7 18:08:46 2009 -0800 pid: implement ns_of_pid commit f9fb860f67b9542cd78d1558dec7058092b57d8e upstream. A current problem with the pid namespace is that it is easy to do pid related work after exit_task_namespaces which drops the nsproxy pointer. However if we are doing pid namespace related work we are always operating on some struct pid which retains the pid_namespace pointer of the pid namespace it was allocated in. So provide ns_of_pid which allows us to find the pid namespace a pid was allocated in. Using this we have the needed infrastructure to do pid namespace related work at anytime we have a struct pid, removing the chance of accidentally having a NULL pointer dereference when accessing current->nsproxy. Signed-off-by: Eric W. Biederman Signed-off-by: Sukadev Bhattiprolu Cc: Oleg Nesterov Cc: Roland McGrath Cc: Bastian Blank Cc: Pavel Emelyanov Cc: Nadia Derbey Acked-by: Serge Hallyn Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman