~thopiekar/linux/+git/linux-stable:linux-2.6.27.y

Branch merges

Related source package recipes

No recipes using this branch. (?)

Create packaging recipe

Related snap packages

Related charm recipes

bc4e1a7... by Willy Tarreau <w@1wt.eu> on 2012-03-17

Linux 2.6.27.62

Signed-off-by: Willy Tarreau <w@1wt.eu>

c0a0cff... by Dan Carpenter <email address hidden> on 2012-02-06

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 <email address hidden>
Signed-off-by: Jens Axboe <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
Signed-off-by: Willy Tarreau <w@1wt.eu>

aa6333a... by Dan Carpenter <email address hidden> on 2012-02-10

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 <email address hidden>
Signed-off-by: Jens Axboe <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
Signed-off-by: Willy Tarreau <w@1wt.eu>

15edbd9... by Wu Fengguang on 2012-01-09

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 <email address hidden>
Reported-by: Ilya Tumaykin <email address hidden>
Tested-by: Ilya Tumaykin <email address hidden>
Signed-off-by: Wu Fengguang <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
Signed-off-by: Willy Tarreau <w@1wt.eu>

297d4c0... by Hubert Feurstein <email address hidden> on 2012-01-09

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 <email address hidden>
Signed-off-by: Nicolas Ferre <email address hidden>
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <email address hidden>
Signed-off-by: Florian Tobias Schandinat <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
Signed-off-by: Willy Tarreau <w@1wt.eu>

8c56853... by Tyler Hicks on 2011-04-29

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 <email address hidden>
Signed-off-by: Colin King <email address hidden>
Signed-off-by: Tim Gardner <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
Signed-off-by: Willy Tarreau <w@1wt.eu>

3c153f9... by Tyler Hicks on 2011-04-12

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 <email address hidden>
Signed-off-by: Colin King <email address hidden>
Signed-off-by: Tim Gardner <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
Signed-off-by: Willy Tarreau <w@1wt.eu>

1663b5e... by Andy Whitcroft on 2011-02-16

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 <email address hidden>
Signed-off-by: Tyler Hicks <email address hidden>
Signed-off-by: Willy Tarreau <w@1wt.eu>

63543d0... by Tyler Hicks on 2012-02-15

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. <email address hidden>
Signed-off-by: Tyler Hicks <email address hidden>
Signed-off-by: Colin Ian King <email address hidden>
Signed-off-by: Tim Gardner <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
Signed-off-by: Willy Tarreau <w@1wt.eu>

ee0cdfc... by Li Wang <email address hidden> on 2012-01-19

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.

[<email address hidden>: rewrite subject and commit message]
Signed-off-by: Li Wang <email address hidden>
Signed-off-by: Yunchuan Wen <email address hidden>
Reviewed-by: Cong Wang <email address hidden>
Signed-off-by: Tyler Hicks <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>

Signed-off-by: Willy Tarreau <w@1wt.eu>