commit bc4e1a77b06519a01e7aed1125695598e27ddeb2 Author: Willy Tarreau Date: Sat Mar 17 14:03:53 2012 +0100 Linux 2.6.27.62 Signed-off-by: Willy Tarreau commit c0a0cff0f5242f0485fb9a4689000c7be2db686c Author: Dan Carpenter Date: Mon Feb 6 10:20:45 2012 +0100 cdrom: use copy_to_user() without the underscores commit 822bfa51ce44f2c63c300fdb76dc99c4d5a5ca9f upstream. "nframes" comes from the user and "nframes * CD_FRAMESIZE_RAW" can wrap on 32 bit systems. That would have been ok if we used the same wrapped value for the copy, but we use a shifted value. We should just use the checked version of copy_to_user() because it's not going to make a difference to the speed. Signed-off-by: Dan Carpenter Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman Signed-off-by: Willy Tarreau commit aa6333a71faab8a2c4cddd883e252987d19c7bcc Author: Dan Carpenter Date: Fri Feb 10 09:03:58 2012 +0100 relay: prevent integer overflow in relay_open() commit f6302f1bcd75a042df69866d98b8d775a668f8f1 upstream. "subbuf_size" and "n_subbufs" come from the user and they need to be capped to prevent an integer overflow. Signed-off-by: Dan Carpenter Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman Signed-off-by: Willy Tarreau commit 15edbd9f8b8695868cf2d98f691264e058fbc2b7 Author: Wu Fengguang Date: Mon Jan 9 11:53:50 2012 -0600 lib: proportion: lower PROP_MAX_SHIFT to 32 on 64-bit kernel commit 3310225dfc71a35a2cc9340c15c0e08b14b3c754 upstream. PROP_MAX_SHIFT should be set to <=32 on 64-bit box. This fixes two bugs in the below lines of bdi_dirty_limit(): bdi_dirty *= numerator; do_div(bdi_dirty, denominator); 1) divide error: do_div() only uses the lower 32 bit of the denominator, which may trimmed to be 0 when PROP_MAX_SHIFT > 32. 2) overflow: (bdi_dirty * numerator) could easily overflow if numerator used up to 48 bits, leaving only 16 bits to bdi_dirty Cc: Peter Zijlstra Reported-by: Ilya Tumaykin Tested-by: Ilya Tumaykin Signed-off-by: Wu Fengguang Signed-off-by: Greg Kroah-Hartman Signed-off-by: Willy Tarreau commit 297d4c0544c9db7bb1cb8a9797fe873855fcc8aa Author: Hubert Feurstein Date: Mon Jan 9 17:23:57 2012 +0100 atmel_lcdfb: fix usage of CONTRAST_CTR in suspend/resume commit 9f1065032ceb7e86c7c9f16bb86518857e88a172 upstream. An error was existing in the saving of CONTRAST_CTR register across suspend/resume. Signed-off-by: Hubert Feurstein Signed-off-by: Nicolas Ferre Acked-by: Jean-Christophe PLAGNIOL-VILLARD Signed-off-by: Florian Tobias Schandinat Signed-off-by: Greg Kroah-Hartman Signed-off-by: Willy Tarreau commit 8c56853f92c1eb508c275373830e0ccefe1a7140 Author: Tyler Hicks Date: Fri Apr 29 16:26:27 2011 -0500 eCryptfs: Clear i_nlink in rmdir commit 07850552b92b3637fa56767b5e460b4238014447 upstream. eCryptfs wasn't clearing the eCryptfs inode's i_nlink after a successful vfs_rmdir() on the lower directory. This resulted in the inode evict and destroy paths to be missed. https://bugs.launchpad.net/ecryptfs/+bug/723518 Signed-off-by: Tyler Hicks Signed-off-by: Colin King Signed-off-by: Tim Gardner Signed-off-by: Greg Kroah-Hartman Signed-off-by: Willy Tarreau commit 3c153f95d2e8dd33c3cc8d5432a57194c7bda933 Author: Tyler Hicks Date: Tue Apr 12 11:21:36 2011 -0500 eCryptfs: Remove extra d_delete in ecryptfs_rmdir commit 35ffa948b2f7bdf79e488cd496232935d095087a upstream. vfs_rmdir() already calls d_delete() on the lower dentry. That was being duplicated in ecryptfs_rmdir() and caused a NULL pointer dereference when NFSv3 was the lower filesystem. BugLink: http://bugs.launchpad.net/bugs/723518 Signed-off-by: Tyler Hicks Signed-off-by: Colin King Signed-off-by: Tim Gardner Signed-off-by: Greg Kroah-Hartman Signed-off-by: Willy Tarreau commit 1663b5e456b6dc59d02224f93bd36d4580b94dd5 Author: Andy Whitcroft Date: Wed Feb 16 04:49:59 2011 +0000 ecryptfs: read on a directory should return EISDIR if not supported commit 323ef68faf1bbd9b1e66aea268fd09d358d7e8ab upstream. read() calls against a file descriptor connected to a directory are incorrectly returning EINVAL rather than EISDIR: [EISDIR] [XSI] [Option Start] The fildes argument refers to a directory and the implementation does not allow the directory to be read using read() or pread(). The readdir() function should be used instead. [Option End] This occurs because we do not have a .read operation defined for ecryptfs directories. Connect this up to generic_read_dir(). BugLink: http://bugs.launchpad.net/bugs/719691 Signed-off-by: Andy Whitcroft Signed-off-by: Tyler Hicks Signed-off-by: Willy Tarreau commit 63543d09044162d59381ca5ffd6dcf6f1d207e2f Author: Tyler Hicks Date: Wed Feb 15 11:32:31 2012 -0700 eCryptfs: Remove mmap from directory operations backported from 38e3eaeedcac75360af8a92e7b66956ec4f334e5 Adrian reported that mkfontscale didn't work inside of eCryptfs mounts. Strace revealed the following: open("./", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3 fcntl64(3, F_GETFD) = 0x1 (flags FD_CLOEXEC) open("./fonts.scale", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 4 getdents(3, /* 80 entries */, 32768) = 2304 open("./.", O_RDONLY) = 5 fcntl64(5, F_SETFD, FD_CLOEXEC) = 0 fstat64(5, {st_mode=S_IFDIR|0755, st_size=16384, ...}) = 0 mmap2(NULL, 16384, PROT_READ, MAP_PRIVATE, 5, 0) = 0xb7fcf000 close(5) = 0 --- SIGBUS (Bus error) @ 0 (0) --- +++ killed by SIGBUS +++ The mmap2() on a directory was successful, resulting in a SIGBUS signal later. This patch removes mmap() from the list of possible ecryptfs_dir_fops so that mmap() isn't possible on eCryptfs directory files. http://bugs.launchpad.net/bugs/400443 Reported-by: Adrian C. Signed-off-by: Tyler Hicks Signed-off-by: Colin Ian King Signed-off-by: Tim Gardner Signed-off-by: Greg Kroah-Hartman Signed-off-by: Willy Tarreau commit ee0cdfcb304a5c6aa6c23ee8c5cdefbf3170c2f5 Author: Li Wang Date: Thu Jan 19 09:44:36 2012 +0800 eCryptfs: Infinite loop due to overflow in ecryptfs_write() commit 684a3ff7e69acc7c678d1a1394fe9e757993fd34 upstream. ecryptfs_write() can enter an infinite loop when truncating a file to a size larger than 4G. This only happens on architectures where size_t is represented by 32 bits. This was caused by a size_t overflow due to it incorrectly being used to store the result of a calculation which uses potentially large values of type loff_t. [tyhicks@canonical.com: rewrite subject and commit message] Signed-off-by: Li Wang Signed-off-by: Yunchuan Wen Reviewed-by: Cong Wang Signed-off-by: Tyler Hicks Signed-off-by: Greg Kroah-Hartman Signed-off-by: Willy Tarreau commit c7da4ed95a78e38fdaffb06eaf1a3f3318b1add6 Author: Jan Kara Date: Fri Dec 23 11:53:07 2011 +0100 udf: Mark LVID buffer as uptodate before marking it dirty commit 853a0c25baf96b028de1654bea1e0c8857eadf3d upstream. When we hit EIO while writing LVID, the buffer uptodate bit is cleared. This then results in an anoying warning from mark_buffer_dirty() when we write the buffer again. So just set uptodate flag unconditionally. Reviewed-by: Namjae Jeon Signed-off-by: Jan Kara Cc: Dave Jones Signed-off-by: Greg Kroah-Hartman Signed-off-by: Willy Tarreau commit dda3caa2b2f242fd2d3a2a8310ccc878919ac730 Author: Carsten Otte Date: Fri Feb 3 15:37:14 2012 -0800 mm/filemap_xip.c: fix race condition in xip_file_fault() commit 99f02ef1f18631eb0a4e0ea0a3d56878dbcb4b90 upstream. Fix a race condition that shows in conjunction with xip_file_fault() when two threads of the same user process fault on the same memory page. In this case, the race winner will install the page table entry and the unlucky loser will cause an oops: xip_file_fault calls vm_insert_pfn (via vm_insert_mixed) which drops out at this check: retval = -EBUSY; if (!pte_none(*pte)) goto out_unlock; The resulting -EBUSY return value will trigger a BUG_ON() in xip_file_fault. This fix simply considers the fault as fixed in this case, because the race winner has successfully installed the pte. [akpm@linux-foundation.org: use conventional (and consistent) comment layout] Reported-by: David Sadler Signed-off-by: Carsten Otte Reported-by: Louis Alex Eisner Cc: Hugh Dickins Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman Signed-off-by: Willy Tarreau commit f924f0e623c86b0435df3dc918809cc31d567d9f Author: Jack Morgenstein Date: Thu Jan 26 16:41:33 2012 +0200 IB/mlx4: pass SMP vendor-specific attribute MADs to firmware commit a6f7feae6d19e84253918d88b04153af09d3a243 upstream. In the current code, vendor-specific MADs (e.g with the FDR-10 attribute) are silently dropped by the driver, resulting in timeouts at the sending side and inability to query/configure the relevant feature. However, the ConnectX firmware is able to handle such MADs. For unsupported attributes, the firmware returns a GET_RESPONSE MAD containing an error status. For example, for a FDR-10 node with LID 11: # ibstat mlx4_0 1 CA: 'mlx4_0' Port 1: State: Active Physical state: LinkUp Rate: 40 (FDR10) Base lid: 11 LMC: 0 SM lid: 24 Capability mask: 0x02514868 Port GUID: 0x0002c903002e65d1 Link layer: InfiniBand Extended Port Query (EPI) vendor mad timeouts before the patch: # smpquery MEPI 11 -d ibwarn: [4196] smp_query_via: attr 0xff90 mod 0x0 route Lid 11 ibwarn: [4196] _do_madrpc: retry 1 (timeout 1000 ms) ibwarn: [4196] _do_madrpc: retry 2 (timeout 1000 ms) ibwarn: [4196] _do_madrpc: timeout after 3 retries, 3000 ms ibwarn: [4196] mad_rpc: _do_madrpc failed; dport (Lid 11) smpquery: iberror: [pid 4196] main: failed: operation EPI: ext port info query failed EPI query works OK with the patch: # smpquery MEPI 11 -d ibwarn: [6548] smp_query_via: attr 0xff90 mod 0x0 route Lid 11 ibwarn: [6548] mad_rpc: data offs 64 sz 64 mad data 0000 0000 0000 0001 0000 0001 0000 0001 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 # Ext Port info: Lid 11 port 0 StateChangeEnable:...............0x00 LinkSpeedSupported:..............0x01 LinkSpeedEnabled:................0x01 LinkSpeedActive:.................0x01 Signed-off-by: Jack Morgenstein Signed-off-by: Or Gerlitz Acked-by: Ira Weiny Signed-off-by: Roland Dreier Signed-off-by: Greg Kroah-Hartman Signed-off-by: Willy Tarreau commit 92c74a5c6bea5451aec9d33fbb1ad54fa47775e3 Author: Michael Neuling Date: Mon Feb 13 11:52:02 2012 +1100 powerpc: Add more Power7 specific definitions stable-2.6.27.60 added c24cb8e5 which uses PV_POWER7 but it's not defined. Following patch adds these definitions. From: Benjamin Herrenschmidt commit 50fb8ebe7c4ad60d147700d253f78bd1e615a526 upstream powerpc: Add more Power7 specific definitions This adds more SPR definitions used on newer processors when running in hypervisor mode. Along with some other P7 specific bits and pieces Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Michael Neuling Signed-off-by: Willy Tarreau