commit d1cd96416646e6d8c7d6f9667cae854e13c82ef9 Author: Greg Kroah-Hartman Date: Tue May 19 22:20:49 2009 -0700 Linux 2.6.27.24 commit 770908db2adb9dcfa2dabf739ac4d59be7f91ddc Author: Miklos Szeredi Date: Tue Apr 14 19:48:39 2009 +0200 ocfs2: fix i_mutex locking in ocfs2_splice_to_file() commit 328eaaba4e41a04c1dc4679d65bea3fee4349d86 upstream. Rearrange locking of i_mutex on destination and call to ocfs2_rw_lock() so locks are only held while buffers are copied with the pipe_to_file() actor, and not while waiting for more data on the pipe. Signed-off-by: Miklos Szeredi Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 1763c368233c8ebf9c5596cb3230a0e4942459b4 Author: Miklos Szeredi Date: Tue Apr 14 19:48:38 2009 +0200 splice: fix i_mutex locking in generic_splice_write() commit eb443e5a25d43996deb62b9bcee1a4ce5dea2ead upstream. Rearrange locking of i_mutex on destination so it's only held while buffers are copied with the pipe_to_file() actor, and not while waiting for more data on the pipe. Signed-off-by: Miklos Szeredi Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit dbda7d1d8a375ec42a6f7602263ec854d9fd7245 Author: Miklos Szeredi Date: Tue Apr 14 19:48:37 2009 +0200 splice: remove i_mutex locking in splice_from_pipe() commit 2933970b960223076d6affcf7a77e2bc546b8102 upstream. splice_from_pipe() is only called from two places: - generic_splice_sendpage() - splice_write_null() Neither of these require i_mutex to be taken on the destination inode. Signed-off-by: Miklos Szeredi Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 89fd89c80b4b78862f5e5fa5c73855aade0907c7 Author: Miklos Szeredi Date: Tue Apr 14 19:48:36 2009 +0200 splice: split up __splice_from_pipe() commit b3c2d2ddd63944ef2a1e4a43077b602288107e01 upstream. Split up __splice_from_pipe() into four helper functions: splice_from_pipe_begin() splice_from_pipe_next() splice_from_pipe_feed() splice_from_pipe_end() splice_from_pipe_next() will wait (if necessary) for more buffers to be added to the pipe. splice_from_pipe_feed() will feed the buffers to the supplied actor and return when there's no more data available (or if all of the requested data has been copied). This is necessary so that implementations can do locking around the non-waiting splice_from_pipe_feed(). This patch should not cause any change in behavior. Signed-off-by: Miklos Szeredi Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit c612d5a20e2ebb2a03404a9d81c0383bba096a79 Author: Grant Likely Date: Wed Feb 4 11:23:56 2009 -0700 powerpc/5200: Don't specify IRQF_SHARED in PSC UART driver commit d9f0c5f9bc74f16d0ea0f6c518b209e48783a796 upstream. The MPC5200 PSC device is wired up to a dedicated interrupt line which is never shared. This patch removes the IRQF_SHARED flag from the request_irq() call which eliminates the "IRQF_DISABLED is not guaranteed on shared IRQs" warning message from the console output. Signed-off-by: Grant Likely Reviewed-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit 81df41068f9610df82da8d6e58cdd1683a8ecd7d Author: Hannes Hering Date: Mon May 4 11:06:37 2009 -0700 ehea: fix invalid pointer access commit 0b2febf38a33d7c40fb7bb4a58c113a1fa33c412 upstream. This patch fixes an invalid pointer access in case the receive queue holds no pointer to the next skb when the queue is empty. Signed-off-by: Hannes Hering Signed-off-by: Jan-Bernd Themann Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 3dfc48ed4761449e83df1b24a6791a80fe5487a3 Author: Trond Myklebust Date: Thu Mar 19 15:35:49 2009 -0400 NFS: Fix the notifications when renaming onto an existing file commit b1e4adf4ea41bb8b5a7bfc1a7001f137e65495df upstream. NFS appears to be returning an unnecessary "delete" notification when we're doing an atomic rename. See http://bugzilla.gnome.org/show_bug.cgi?id=575684 The fix is to get rid of the redundant call to d_delete(). Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 7af264b6aab8c3bd89c61751b793a8f6a8e64173 Author: J. Bruce Fields Date: Tue May 5 19:04:29 2009 -0400 nfsd4: check for negative dentry before use in nfsv4 readdir commit b2c0cea6b1cb210e962f07047df602875564069e upstream. After 2f9092e1020246168b1309b35e085ecd7ff9ff72 "Fix i_mutex vs. readdir handling in nfsd" (and 14f7dd63 "Copy XFS readdir hack into nfsd code"), an entry may be removed between the first mutex_unlock and the second mutex_lock. In this case, lookup_one_len() will return a negative dentry. Check for this case to avoid a NULL dereference. Signed-off-by: J. Bruce Fields Reviewed-by: J. R. Okajima Signed-off-by: Greg Kroah-Hartman commit 6ee4627d39d5020bb7f75f6558a1f64b697556fc Author: Davide Libenzi Date: Tue May 12 13:19:44 2009 -0700 epoll: fix size check in epoll_create() commit bfe3891a5f5d3b78146a45f40e435d14f5ae39dd upstream. Fix a size check WRT the manual pages. This was inadvertently broken by commit 9fe5ad9c8cef9ad5873d8ee55d1cf00d9b607df0 ("flag parameters add-on: remove epoll_create size param"). Signed-off-by: Davide Libenzi Cc: Cc: rohit verma Cc: Ulrich Drepper Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit b577e5ee6c55dd8f5caafa6004aefcc868b14ecf Author: Jeff Layton Date: Sat May 9 11:34:21 2009 +0530 cifs: Fix unicode string area word alignment in session setup commit 27b87fe52baba0a55e9723030e76fce94fabcea4 refreshed. cifs: fix unicode string area word alignment in session setup The handling of unicode string area alignment is wrong. decode_unicode_ssetup improperly assumes that it will always be preceded by a pad byte. This isn't the case if the string area is already word-aligned. This problem, combined with the bad buffer sizing for the serverDomain string can cause memory corruption. The bad alignment can make it so that the alignment of the characters is off. This can make them translate to characters that are greater than 2 bytes each. If this happens we can overflow the allocation. Fix this by fixing the alignment in CIFS_SessSetup instead so we can verify it against the head of the response. Also, clean up the workaround for improperly terminated strings by checking for a odd-length unicode buffers and then forcibly terminating them. Finally, resize the buffer for serverDomain. Now that we've fixed the alignment, it's probably fine, but a malicious server could overflow it. A better solution for handling these strings is still needed, but this should be a suitable bandaid. Signed-off-by: Jeff Layton Signed-off-by: Steve French Cc: Suresh Jayaraman Signed-off-by: Greg Kroah-Hartman commit add2a4fc71859c94e9049a74ac93c895bb5d806e Author: Suresh Jayaraman Date: Sat May 9 11:33:12 2009 +0530 cifs: Fix buffer size in cifs_convertUCSpath Relevant commits 7fabf0c9479fef9fdb9528a5fbdb1cb744a744a4 and f58841666bc22e827ca0dcef7b71c7bc2758ce82. The upstream commits adds cifs_from_ucs2 that includes functionality of cifs_convertUCSpath and does cleanup. Reported-by: Jeff Layton Signed-off-by: Suresh Jayaraman Acked-by: Steve French Acked-by: Jeff Layton Signed-off-by: Greg Kroah-Hartman commit bd80f2c19e0bb66817d0c57015ea685d555ec2df Author: Suresh Jayaraman Date: Sat May 9 11:26:44 2009 +0530 cifs: Fix incorrect destination buffer size in cifs_strncpy_to_host Relevant commits 968460ebd8006d55661dec0fb86712b40d71c413 and 066ce6899484d9026acd6ba3a8dbbedb33d7ae1b. Minimal hunks to fix buffer size and fix an existing problem pointed out by Guenter Kukuk that length of src is used for NULL termination of dst. cifs: Rename cifs_strncpy_to_host and fix buffer size There is a possibility for the path_name and node_name buffers to overflow if they contain charcters that are >2 bytes in the local charset. Resize the buffer allocation so to avoid this possibility. Also, as pointed out by Jeff Layton, it would be appropriate to rename the function to cifs_strlcpy_to_host to reflect the fact that the copied string is always NULL terminated. Signed-off-by: Suresh Jayaraman Acked-by: Jeff Layton Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit f1e9ce644becc2ff8865a3abb43dcfadefef093f Author: Suresh Jayaraman Date: Sat May 9 11:22:47 2009 +0530 cifs: Increase size of tmp_buf in cifs_readdir to avoid potential overflows Commit 7b0c8fcff47a885743125dd843db64af41af5a61 refreshed and use a #define from commit f58841666bc22e827ca0dcef7b71c7bc2758ce82. cifs: Increase size of tmp_buf in cifs_readdir to avoid potential overflows Increase size of tmp_buf to possible maximum to avoid potential overflows. Also moved UNICODE_NAME_MAX definition so that it can be used elsewhere. Pointed-out-by: Jeff Layton Signed-off-by: Suresh Jayaraman Acked-by: Jeff Layton Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit b26a2233617941def73064bee3fffb97ab6f073b Author: Jeff Layton Date: Sat May 9 11:19:05 2009 +0530 cifs: Fix buffer size for tcon->nativeFileSystem field Commit f083def68f84b04fe3f97312498911afce79609e refreshed. cifs: fix buffer size for tcon->nativeFileSystem field The buffer for this was resized recently to fix a bug. It's still possible however that a malicious server could overflow this field by sending characters in it that are >2 bytes in the local charset. Double the size of the buffer to account for this possibility. Also get rid of some really strange and seemingly pointless NULL termination. It's NULL terminating the string in the source buffer, but by the time that happens, we've already copied the string. Signed-off-by: Jeff Layton Signed-off-by: Steve French Cc: Suresh Jayaraman Signed-off-by: Greg Kroah-Hartman commit 71cf4edb1d866d69773bce35f9761d1973b671c9 Author: Trond Myklebust Date: Tue May 12 16:23:52 2009 +1000 NFS: Close page_mkwrite() races commit 7fdf523067666b0eaff330f362401ee50ce187c4 upstream Follow up to Nick Piggin's patches to ensure that nfs_vm_page_mkwrite returns with the page lock held, and sets the VM_FAULT_LOCKED flag. See http://bugzilla.kernel.org/show_bug.cgi?id=12913 Signed-off-by: Trond Myklebust Signed-off-by: Linus Torvalds Cc: Nick Piggin Signed-off-by: Greg Kroah-Hartman commit 18b0560ccb3fcda54cc28718647599f494dc62b9 Author: Trond Myklebust Date: Tue May 12 16:23:51 2009 +1000 NFS: Fix the return value in nfs_page_mkwrite() commit 2b2ec7554cf7ec5e4412f89a5af6abe8ce950700 upstream Commit c2ec175c39f62949438354f603f4aa170846aabb ("mm: page_mkwrite change prototype to match fault") exposed a bug in the NFS implementation of page_mkwrite. We should be returning 0 on success... Signed-off-by: Trond Myklebust Signed-off-by: Linus Torvalds Cc: Nick Piggin Signed-off-by: Greg Kroah-Hartman commit b413c3438b84245825d03aeb80ecd9bae3af73a6 Author: Steven Whitehouse Date: Tue May 12 16:23:50 2009 +1000 GFS2: Fix page_mkwrite() return code commit e56985da455b9dc0591b8cb2006cc94b6f4fb0f4 upstream This allows for the possibility of returning VM_FAULT_OOM as well as VM_FAULT_SIGBUS. This ensures that the correct action is taken. Signed-off-by: Steven Whitehouse Cc: Nick Piggin Signed-off-by: Greg Kroah-Hartman commit 392cc66802e9dece47dd4a9ef241014dc2182c6b Author: Nick Piggin Date: Tue May 12 16:23:49 2009 +1000 mm: close page_mkwrite races commit b827e496c893de0c0f142abfaeb8730a2fd6b37f upstream mm: close page_mkwrite races Change page_mkwrite to allow implementations to return with the page locked, and also change it's callers (in page fault paths) to hold the lock until the page is marked dirty. This allows the filesystem to have full control of page dirtying events coming from the VM. Rather than simply hold the page locked over the page_mkwrite call, we call page_mkwrite with the page unlocked and allow callers to return with it locked, so filesystems can avoid LOR conditions with page lock. The problem with the current scheme is this: a filesystem that wants to associate some metadata with a page as long as the page is dirty, will perform this manipulation in its ->page_mkwrite. It currently then must return with the page unlocked and may not hold any other locks (according to existing page_mkwrite convention). In this window, the VM could write out the page, clearing page-dirty. The filesystem has no good way to detect that a dirty pte is about to be attached, so it will happily write out the page, at which point, the filesystem may manipulate the metadata to reflect that the page is no longer dirty. It is not always possible to perform the required metadata manipulation in ->set_page_dirty, because that function cannot block or fail. The filesystem may need to allocate some data structure, for example. And the VM cannot mark the pte dirty before page_mkwrite, because page_mkwrite is allowed to fail, so we must not allow any window where the page could be written to if page_mkwrite does fail. This solution of holding the page locked over the 3 critical operations (page_mkwrite, setting the pte dirty, and finally setting the page dirty) closes out races nicely, preventing page cleaning for writeout being initiated in that window. This provides the filesystem with a strong synchronisation against the VM here. - Sage needs this race closed for ceph filesystem. - Trond for NFS (http://bugzilla.kernel.org/show_bug.cgi?id=12913). - I need it for fsblock. - I suspect other filesystems may need it too (eg. btrfs). - I have converted buffer.c to the new locking. Even simple block allocation under dirty pages might be susceptible to i_size changing under partial page at the end of file (we also have a buffer.c-side problem here, but it cannot be fixed properly without this patch). - Other filesystems (eg. NFS, maybe btrfs) will need to change their page_mkwrite functions themselves. [ This also moves page_mkwrite another step closer to fault, which should eventually allow page_mkwrite to be moved into ->fault, and thus avoiding a filesystem calldown and page lock/unlock cycle in __do_fault. ] [akpm@linux-foundation.org: fix derefs of NULL ->mapping] Cc: Sage Weil Cc: Trond Myklebust Signed-off-by: Nick Piggin Cc: Valdis Kletnieks Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit b393309d52554679f3a6e4dd18c28eee627189ce Author: Nick Piggin Date: Tue May 12 16:23:48 2009 +1000 fs: fix page_mkwrite error cases in core code and btrfs commit 56a76f8275c379ed73c8a43cfa1dfa2f5e9cfa19 upstream fs: fix page_mkwrite error cases in core code and btrfs page_mkwrite is called with neither the page lock nor the ptl held. This means a page can be concurrently truncated or invalidated out from underneath it. Callers are supposed to prevent truncate races themselves, however previously the only thing they can do in case they hit one is to raise a SIGBUS. A sigbus is wrong for the case that the page has been invalidated or truncated within i_size (eg. hole punched). Callers may also have to perform memory allocations in this path, where again, SIGBUS would be wrong. The previous patch ("mm: page_mkwrite change prototype to match fault") made it possible to properly specify errors. Convert the generic buffer.c code and btrfs to return sane error values (in the case of page removed from pagecache, VM_FAULT_NOPAGE will cause the fault handler to exit without doing anything, and the fault will be retried properly). This fixes core code, and converts btrfs as a template/example. All other filesystems defining their own page_mkwrite should be fixed in a similar manner. Acked-by: Chris Mason Signed-off-by: Nick Piggin Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit be05b43969cfca5b15df6b558b65a24aec25e61a Author: Nick Piggin Date: Tue May 12 16:23:47 2009 +1000 mm: page_mkwrite change prototype to match fault commit c2ec175c39f62949438354f603f4aa170846aabb upstream mm: page_mkwrite change prototype to match fault Change the page_mkwrite prototype to take a struct vm_fault, and return VM_FAULT_xxx flags. There should be no functional change. This makes it possible to return much more detailed error information to the VM (and also can provide more information eg. virtual_address to the driver, which might be important in some special cases). This is required for a subsequent fix. And will also make it easier to merge page_mkwrite() with fault() in future. Signed-off-by: Nick Piggin Cc: Chris Mason Cc: Trond Myklebust Cc: Miklos Szeredi Cc: Steven Whitehouse Cc: Mark Fasheh Cc: Joel Becker Cc: Artem Bityutskiy Cc: Felix Blyakher Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 5e997eb367501a7c079fb5cb153ec59faf35d6d8 Author: Enrik Berkhan Date: Thu May 7 14:58:48 2009 +0200 i2c-algo-pca: Let PCA9564 recover from unacked data byte (state 0x30) commit 2196d1cf4afab93fb64c2e5b417096e49b661612 upstream Currently, the i2c-algo-pca driver does nothing if the chip enters state 0x30 (Data byte in I2CDAT has been transmitted; NOT ACK has been received). Thus, the i2c bus connected to the controller gets stuck afterwards. I have seen this kind of error on a custom board in certain load situations most probably caused by interference or noise. A possible reaction is to let the controller generate a STOP condition. This is documented in the PCA9564 data sheet (2006-09-01) and the same is done for other NACK states as well. Further, state 0x38 isn't handled completely, either. Try to do another START in this case like the data sheet says. As this couldn't be tested, I've added a comment to try to reset the chip if the START doesn't help as suggested by Wolfram Sang. Signed-off-by: Enrik Berkhan Reviewed-by: Wolfram Sang Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman commit 3db025f88475dd6eaa4b4881d21f7ab89c8b1ecd Author: Dave Airlie Date: Thu May 7 14:57:24 2009 +0200 i2c-algo-bit: Fix timeout test commit 0cdba07bb23cdd3e0d64357ec3d983e6b75e541f upstream When fetching DDC using i2c algo bit, we were often seeing timeouts before getting valid EDID on a retry. The VESA spec states 2ms is the DDC timeout, so when this translates into 1 jiffie and we are close to the end of the time period, it could return with a timeout less than 2ms. Change this code to use time_after instead of time_after_eq. Signed-off-by: Dave Airlie Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman commit bdc9a1caa2fae65d8b323c312f73b40d30ff4dae Author: Jeff Mahoney Date: Mon May 11 14:25:34 2009 -0400 dup2: Fix return value with oldfd == newfd and invalid fd commit 2b79bc4f7ebbd5af3c8b867968f9f15602d5f802 upstream. The return value of dup2 when oldfd == newfd and the fd isn't valid is not getting properly sign extended. We end up with 4294967287 instead of -EBADF. I've reproduced this on SLE11 (2.6.27.21), openSUSE Factory (2.6.29-rc5), and Ubuntu 9.04 (2.6.28). This patch uses a signed int for the error value so it is properly extended. Commit 6c5d0512a091480c9f981162227fdb1c9d70e555 introduced this regression. Reported-by: Jiri Dluhos Signed-off-by: Jeff Mahoney Signed-off-by: Linus Torvalds Cc: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 091fc4290d9d7c3bc56e0685f3b3baf8f80613f1 Author: Alan Stern Date: Mon Apr 27 13:22:40 2009 -0400 USB: Gadget: fix UTF conversion in the usbstring library commit 0f43158caddcbb110916212ebe4e39993ae70864 upstream. This patch (as1234) fixes a bug in the UTF8 -> UTF-16 conversion routine in the gadget/usbstring library. In a UTF-8 multi-byte sequence, all bytes after the first should have their high-order two bits set to 10, not 11. Signed-off-by: Alan Stern Acked-by: David Brownell Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 092a287e02d1e45f6894b4a0886a5ec9dbab4129 Author: NeilBrown Date: Thu May 7 12:50:57 2009 +1000 md: remove ability to explicit set an inactive array to 'clean'. commit 5bf295975416f8e97117bbbcfb0191c00bc3e2b4 upstream. Being able to write 'clean' to an 'array_state' of an inactive array to activate it in 'clean' mode is both unnecessary and inconvenient. It is unnecessary because the same can be achieved by writing 'active'. This activates and array, but it still remains 'clean' until the first write. It is inconvenient because writing 'clean' is more often used to cause an 'active' array to revert to 'clean' mode (thus blocking any writes until a 'write-pending' is promoted to 'active'). Allowing 'clean' to both activate an array and mark an active array as clean can lead to races: One program writes 'clean' to mark the active array as clean at the same time as another program writes 'inactive' to deactivate (stop) and active array. Depending on which writes first, the array could be deactivated and immediately reactivated which isn't what was desired. So just disable the use of 'clean' to activate an array. This avoids a race that can be triggered with mdadm-3.0 and external metadata, so it suitable for -stable. Reported-by: Rafal Marszewski Acked-by: Dan Williams Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit 10681e946a0f05731f280406cb674bd5d8b0187c Author: NeilBrown Date: Thu May 7 12:48:10 2009 +1000 md/raid10: don't clear bitmap during recovery if array will still be degraded. commit 18055569127253755d01733f6ecc004ed02f88d0 upstream. If we have a raid10 with multiple missing devices, and we recover just one of these to a spare, then we risk (depending on the bitmap and array chunk size) clearing bits of the bitmap for which recovery isn't complete (because a device is still missing). This can lead to a subsequent "re-add" being recovered without any IO happening, which would result in loss of data. This patch takes the safe approach of not clearing bitmap bits if the array will still be degraded. This patch is suitable for all active -stable kernels. Cc: stable@kernel.org Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit 47a0d1852bafea509dcec4599d72e1b662223e72 Author: NeilBrown Date: Thu May 7 12:49:06 2009 +1000 md: fix some (more) errors with bitmaps on devices larger than 2TB. commit db305e507d554430a69ede901a6308e6ecb72349 upstream. If a write intent bitmap covers more than 2TB, we sometimes work with values beyond 32bit, so these need to be sector_t. This patches add the required casts to some unsigned longs that are being shifted up. This will affect any raid10 larger than 2TB, or any raid1/4/5/6 with member devices that are larger than 2TB. Signed-off-by: NeilBrown Reported-by: "Mario 'BitKoenig' Holbe" Signed-off-by: Greg Kroah-Hartman commit ad18478ac7f372f641e195ad5129c3fd48a2ed56 Author: NeilBrown Date: Thu May 7 12:47:19 2009 +1000 md: fix loading of out-of-date bitmap. commit b74fd2826c5acce20e6f691437b2d19372bc2057 upstream. When md is loading a bitmap which it knows is out of date, it fills each page with 1s and writes it back out again. However the write_page call makes used of bitmap->file_pages and bitmap->last_page_size which haven't been set correctly yet. So this can sometimes fail. Move the setting of file_pages and last_page_size to before the call to write_page. This bug can cause the assembly on an array to fail, thus making the data inaccessible. Hence I think it is a suitable candidate for -stable. Reported-by: Vojtech Pavlik Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman