commit 7ee47d833ea1539f6a64e6945bc4fb55865768ed Author: Greg Kroah-Hartman Date: Fri Aug 13 14:02:40 2010 -0700 Linux 2.6.27.51 commit cc3a4347f0c919f23694e6d5762a97bfdc60d353 Author: Andrew Morton Date: Tue Dec 9 13:14:06 2008 -0800 mm/backing-dev.c: remove recently-added WARN_ON() commit 69fc208be5b7eb18d22d1eca185b201400fd5ffc upstream. On second thoughts, this is just going to disturb people while telling us things which we already knew. Cc: Peter Korsgaard Cc: Peter Zijlstra Cc: Kay Sievers Cc: David Woodhouse Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Cc: Ben Hutchings Signed-off-by: Greg Kroah-Hartman commit e3af6cabe0a0c3f00c5b6b6a8324f8c48963c9a9 Author: Kay Sievers Date: Tue Dec 2 10:31:50 2008 -0800 bdi: register sysfs bdi device only once per queue commit f1d0b063d993527754f062c589b73f125024d216 upstream. Devices which share the same queue, like floppies and mtd devices, get registered multiple times in the bdi interface, but bdi accounts only the last registered device of the devices sharing one queue. On remove, all earlier registered devices leak, stay around in sysfs, and cause "duplicate filename" errors if the devices are re-created. This prevents the creation of multiple bdi interfaces per queue, and the bdi device will carry the dev_t name of the block device which is the first one registered, of the pool of devices using the same queue. [akpm@linux-foundation.org: add a WARN_ON so we know which drivers are misbehaving] Tested-by: Peter Korsgaard Acked-by: Peter Zijlstra Signed-off-by: Kay Sievers Cc: David Woodhouse Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Cc: Ben Hutchings Signed-off-by: Greg Kroah-Hartman commit 411643192e5ba25993b5221326abac6d96df4ad0 Author: Jeremy Fitzhardinge Date: Mon Jul 12 11:49:59 2010 -0700 xen: drop xen_sched_clock in favour of using plain wallclock time commit 8a22b9996b001c88f2bfb54c6de6a05fc39e177a upstream. xen_sched_clock only counts unstolen time. In principle this should be useful to the Linux scheduler so that it knows how much time a process actually consumed. But in practice this doesn't work very well as the scheduler expects the sched_clock time to be synchronized between cpus. It also uses sched_clock to measure the time a task spends sleeping, in which case "unstolen time" isn't meaningful. So just use plain xen_clocksource_read to return wallclock nanoseconds for sched_clock. Signed-off-by: Jeremy Fitzhardinge Signed-off-by: Greg Kroah-Hartman commit 8d026ff8f0ab31c83e67d617a9243cad1bf9f2d9 Author: Dave Kleikamp Date: Mon Aug 9 15:57:38 2010 -0500 jfs: don't allow os2 xattr namespace overlap with others commit aca0fa34bdaba39bfddddba8ca70dba4782e8fe6 upstream. It's currently possible to bypass xattr namespace access rules by prefixing valid xattr names with "os2.", since the os2 namespace stores extended attributes in a legacy format with no prefix. This patch adds checking to deny access to any valid namespace prefix following "os2.". Signed-off-by: Dave Kleikamp Reported-by: Sergey Vlasov Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit fb522b653dae079c79ce1cbaf32d307d3d4088f0 Author: Nathan Lynch Date: Tue Aug 10 18:03:08 2010 -0700 signalfd: fill in ssi_int for posix timers and message queues commit a2a20c412c86e0bb46a9ab0dd31bcfe6d201b913 upstream. If signalfd is used to consume a signal generated by a POSIX interval timer or POSIX message queue, the ssi_int field does not reflect the data (sigevent->sigev_value) supplied to timer_create(2) or mq_notify(3). (The ssi_ptr field, however, is filled in.) This behavior differs from signalfd's treatment of sigqueue-generated signals -- see the default case in signalfd_copyinfo. It also gives results that differ from the case when a signal is handled conventionally via a sigaction-registered handler. So, set signalfd_siginfo->ssi_int in the remaining cases (__SI_TIMER, __SI_MESGQ) where ssi_ptr is set. akpm: a non-back-compatible change. Merge into -stable to minimise the number of kernels which are in the field and which miss this feature. Signed-off-by: Nathan Lynch Acked-by: Davide Libenzi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 0dd272ef0b3f6023712e80cb56626b3020ab8d87 Author: Julia Lawall Date: Fri Aug 6 22:58:49 2010 +0200 fs/ecryptfs/file.c: introduce missing free commit ceeab92971e8af05c1e81a4ff2c271124b55bb9b upstream. The comments in the code indicate that file_info should be released if the function fails. This releasing is done at the label out_free, not out. The semantic match that finds this problem is as follows: (http://www.emn.fr/x-info/coccinelle/) // @r exists@ local idexpression x; statement S; expression E; identifier f,f1,l; position p1,p2; expression *ptr != NULL; @@ x@p1 = kmem_cache_zalloc(...); ... if (x == NULL) S <... when != x when != if (...) { <+...x...+> } ( x->f1 = E | (x->f1 == NULL || ...) | f(...,x->f1,...) ) ...> ( return <+...x...+>; | return@p2 ...; ) @script:python@ p1 << r.p1; p2 << r.p2; @@ print "* file: %s kmem_cache_zalloc %s" % (p1[0].file,p1[0].line) // Signed-off-by: Julia Lawall Signed-off-by: Tyler Hicks Signed-off-by: Greg Kroah-Hartman commit 1fef595f75ceb07fe1334d918feff6f788c2d8ba Author: Tyler Hicks Date: Tue Nov 3 11:45:11 2009 -0600 eCryptfs: Handle ioctl calls with unlocked and compat functions commit c43f7b8fb03be8bcc579bfc4e6ab70eac887ab55 upstream. Lower filesystems that only implemented unlocked_ioctl weren't being passed ioctl calls because eCryptfs only checked for lower_file->f_op->ioctl and returned -ENOTTY if it was NULL. eCryptfs shouldn't implement ioctl(), since it doesn't require the BKL. This patch introduces ecryptfs_unlocked_ioctl() and ecryptfs_compat_ioctl(), which passes the calls on to the lower file system. https://bugs.launchpad.net/ecryptfs/+bug/469664 Reported-by: James Dupin Signed-off-by: Tyler Hicks Signed-off-by: Greg Kroah-Hartman commit ea77f594f059adbc1f5b92650890a86b8464151b Author: NeilBrown Date: Sat Aug 7 21:17:00 2010 +1000 md/raid10: fix deadlock with unaligned read during resync commit 51e9ac77035a3dfcb6fc0a88a0d80b6f99b5edb1 upstream. If the 'bio_split' path in raid10-read is used while resync/recovery is happening it is possible to deadlock. Fix this be elevating ->nr_waiting for the duration of both parts of the split request. This fixes a bug that has been present since 2.6.22 but has only started manifesting recently for unknown reasons. It is suitable for and -stable since then. Reported-by: Justin Bronder Tested-by: Justin Bronder Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit 0945d6a3e9242b63be63c31f4759098f94accf9e Author: Tejun Heo Date: Sun May 23 10:22:55 2010 +0200 PCI: disable MSI on VIA K8M800 commit 549e15611b4ac1de51ef0e0a79c2704f50a638a2 upstream. MSI delivery from on-board ahci controller doesn't work on K8M800. At this point, it's unclear whether the culprit is with the ahci controller or the host bridge. Given the track record and considering the rather minimal impact of MSI, disabling it seems reasonable. Signed-off-by: Tejun Heo Reported-by: Rainer Hurtado Navarro Signed-off-by: Jesse Barnes Signed-off-by: Greg Kroah-Hartman commit cb8e5c9cd0302918af1c4baa1e9096f5da88842b Author: Miklos Szeredi Date: Tue Aug 3 12:48:50 2010 +0200 splice: fix misuse of SPLICE_F_NONBLOCK commit 6965031d331a642e31278fa1b5bd47f372ffdd5d upstream. SPLICE_F_NONBLOCK is clearly documented to only affect blocking on the pipe. In __generic_file_splice_read(), however, it causes an EAGAIN if the page is currently being read. This makes it impossible to write an application that only wants failure if the pipe is full. For example if the same process is handling both ends of a pipe and isn't otherwise able to determine whether a splice to the pipe will fill it or not. We could make the read non-blocking on O_NONBLOCK or some other splice flag, but for now this is the simplest fix. Signed-off-by: Miklos Szeredi Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 8f0b4f678e7f82e415413643a22604925929a157 Author: H. Peter Anvin Date: Fri Dec 11 15:48:23 2009 -0800 nvram: Fix write beyond end condition; prove to gcc copy is safe commit a01c7800420d2c294ca403988488a635d4087a6d upstream. In nvram_write, first of all, correctly handle the case where the file pointer is already beyond the end; we should return EOF in that case. Second, make the logic a bit more explicit so that gcc can statically prove that the copy_from_user() is safe. Once the condition of the beyond-end filepointer is eliminated, the copy is safe but gcc can't prove it, causing build failures for i386 allyesconfig. Third, eliminate the entirely superfluous variable "len", and just use the passed-in variable "count" instead. Signed-off-by: H. Peter Anvin Cc: Arjan van de Ven Cc: Andrew Morton Cc: Wim Van Sebroeck Cc: Frederic Weisbecker LKML-Reference: Cc: Stephen Hemminger Signed-off-by: Greg Kroah-Hartman