kernel, branch linux-2.6.27.y

Linux 2.6.27.62

2012-03-17T13:03:58Z

Signed-off-by: Willy Tarreau

cdrom: use copy_to_user() without the underscores

2012-03-17T13:03:58Z

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

relay: prevent integer overflow in relay_open()

2012-03-17T13:03:58Z

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

lib: proportion: lower PROP_MAX_SHIFT to 32 on 64-bit kernel

2012-03-17T13:03:57Z

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

atmel_lcdfb: fix usage of CONTRAST_CTR in suspend/resume

2012-03-17T13:03:57Z

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

eCryptfs: Clear i_nlink in rmdir

2012-03-17T13:03:56Z

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

eCryptfs: Remove extra d_delete in ecryptfs_rmdir

2012-03-17T13:03:56Z

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

ecryptfs: read on a directory should return EISDIR if not supported

2012-03-17T13:03:56Z

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

eCryptfs: Remove mmap from directory operations

2012-03-17T13:03:55Z

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

eCryptfs: Infinite loop due to overflow in ecryptfs_write()

2012-03-17T13:03:55Z

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