From: Greg Kroah-Hartman Date: Wed, 3 Jun 2015 05:51:26 +0000 (+0900) Subject: 3.10-stable patches X-Git-Tag: v3.10.80~5 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=31ea162048b4695281d60a04692b57cabb8c9f7e;p=thirdparty%2Fkernel%2Fstable-queue.git 3.10-stable patches added patches: acpi-init-fix-the-ordering-of-acpi_reserve_resources.patch fs-binfmt_elf.c-load_elf_binary-return-einval-on-zero-length-mappings.patch input-elantech-fix-semi-mt-protocol-for-v3-hw.patch rtlwifi-rtl8192cu-fix-kernel-deadlock.patch vfs-read-file_handle-only-once-in-handle_to_path.patch --- diff --git a/queue-3.10/acpi-init-fix-the-ordering-of-acpi_reserve_resources.patch b/queue-3.10/acpi-init-fix-the-ordering-of-acpi_reserve_resources.patch new file mode 100644 index 00000000000..4869a64531c --- /dev/null +++ b/queue-3.10/acpi-init-fix-the-ordering-of-acpi_reserve_resources.patch @@ -0,0 +1,59 @@ +From b9a5e5e18fbf223502c0b2264c15024e393da928 Mon Sep 17 00:00:00 2001 +From: "Rafael J. Wysocki" +Date: Thu, 7 May 2015 21:19:39 +0200 +Subject: ACPI / init: Fix the ordering of acpi_reserve_resources() + +From: "Rafael J. Wysocki" + +commit b9a5e5e18fbf223502c0b2264c15024e393da928 upstream. + +Since acpi_reserve_resources() is defined as a device_initcall(), +there's no guarantee that it will be executed in the right order +with respect to the rest of the ACPI initialization code. On some +systems this leads to breakage if, for example, the address range +that should be reserved for the ACPI fixed registers is given to +the PCI host bridge instead if the race is won by the wrong code +path. + +Fix this by turning acpi_reserve_resources() into a void function +and calling it directly from within the ACPI initialization sequence. + +Reported-and-tested-by: George McCollister +Link: http://marc.info/?t=143092384600002&r=1&w=2 +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/acpi/osl.c | 6 ++---- + 1 file changed, 2 insertions(+), 4 deletions(-) + +--- a/drivers/acpi/osl.c ++++ b/drivers/acpi/osl.c +@@ -173,7 +173,7 @@ static void __init acpi_request_region ( + request_mem_region(addr, length, desc); + } + +-static int __init acpi_reserve_resources(void) ++static void __init acpi_reserve_resources(void) + { + acpi_request_region(&acpi_gbl_FADT.xpm1a_event_block, acpi_gbl_FADT.pm1_event_length, + "ACPI PM1a_EVT_BLK"); +@@ -202,10 +202,7 @@ static int __init acpi_reserve_resources + if (!(acpi_gbl_FADT.gpe1_block_length & 0x1)) + acpi_request_region(&acpi_gbl_FADT.xgpe1_block, + acpi_gbl_FADT.gpe1_block_length, "ACPI GPE1_BLK"); +- +- return 0; + } +-device_initcall(acpi_reserve_resources); + + void acpi_os_printf(const char *fmt, ...) + { +@@ -1727,6 +1724,7 @@ acpi_status __init acpi_os_initialize(vo + + acpi_status __init acpi_os_initialize1(void) + { ++ acpi_reserve_resources(); + kacpid_wq = alloc_workqueue("kacpid", 0, 1); + kacpi_notify_wq = alloc_workqueue("kacpi_notify", 0, 1); + kacpi_hotplug_wq = alloc_workqueue("kacpi_hotplug", 0, 1); diff --git a/queue-3.10/fs-binfmt_elf.c-load_elf_binary-return-einval-on-zero-length-mappings.patch b/queue-3.10/fs-binfmt_elf.c-load_elf_binary-return-einval-on-zero-length-mappings.patch new file mode 100644 index 00000000000..baa95008544 --- /dev/null +++ b/queue-3.10/fs-binfmt_elf.c-load_elf_binary-return-einval-on-zero-length-mappings.patch @@ -0,0 +1,33 @@ +From 2b1d3ae940acd11be44c6eced5873d47c2e00ffa Mon Sep 17 00:00:00 2001 +From: Andrew Morton +Date: Thu, 28 May 2015 15:44:24 -0700 +Subject: fs/binfmt_elf.c:load_elf_binary(): return -EINVAL on zero-length mappings + +From: Andrew Morton + +commit 2b1d3ae940acd11be44c6eced5873d47c2e00ffa upstream. + +load_elf_binary() returns `retval', not `error'. + +Fixes: a87938b2e246b81b4fb ("fs/binfmt_elf.c: fix bug in loading of PIE binaries") +Reported-by: James Hogan +Cc: Michael Davidson +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + fs/binfmt_elf.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/fs/binfmt_elf.c ++++ b/fs/binfmt_elf.c +@@ -824,7 +824,7 @@ static int load_elf_binary(struct linux_ + total_size = total_mapping_size(elf_phdata, + loc->elf_ex.e_phnum); + if (!total_size) { +- error = -EINVAL; ++ retval = -EINVAL; + goto out_free_dentry; + } + } diff --git a/queue-3.10/input-elantech-fix-semi-mt-protocol-for-v3-hw.patch b/queue-3.10/input-elantech-fix-semi-mt-protocol-for-v3-hw.patch new file mode 100644 index 00000000000..304672f62fc --- /dev/null +++ b/queue-3.10/input-elantech-fix-semi-mt-protocol-for-v3-hw.patch @@ -0,0 +1,38 @@ +From 3c0213d17a09601e0c6c0ae0e27caf70d988290f Mon Sep 17 00:00:00 2001 +From: Benjamin Tissoires +Date: Thu, 23 Apr 2015 09:08:43 -0700 +Subject: Input: elantech - fix semi-mt protocol for v3 HW + +From: Benjamin Tissoires + +commit 3c0213d17a09601e0c6c0ae0e27caf70d988290f upstream. + +When the v3 hardware sees more than one finger, it uses the semi-mt +protocol to report the touches. However, it currently works when +num_fingers is 0, 1 or 2, but when it is 3 and above, it sends only 1 +finger as if num_fingers was 1. + +This confuses userspace which knows how to deal with extra fingers +when all the slots are used, but not when some are missing. + +Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=90101 + +Signed-off-by: Benjamin Tissoires +Signed-off-by: Dmitry Torokhov +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/input/mouse/elantech.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/input/mouse/elantech.c ++++ b/drivers/input/mouse/elantech.c +@@ -314,7 +314,7 @@ static void elantech_report_semi_mt_data + unsigned int x2, unsigned int y2) + { + elantech_set_slot(dev, 0, num_fingers != 0, x1, y1); +- elantech_set_slot(dev, 1, num_fingers == 2, x2, y2); ++ elantech_set_slot(dev, 1, num_fingers >= 2, x2, y2); + } + + /* diff --git a/queue-3.10/rtlwifi-rtl8192cu-fix-kernel-deadlock.patch b/queue-3.10/rtlwifi-rtl8192cu-fix-kernel-deadlock.patch new file mode 100644 index 00000000000..c0d558344d1 --- /dev/null +++ b/queue-3.10/rtlwifi-rtl8192cu-fix-kernel-deadlock.patch @@ -0,0 +1,39 @@ +From 414b7e3b9ce8b0577f613e656fdbc36b34b444dd Mon Sep 17 00:00:00 2001 +From: Larry Finger +Date: Fri, 24 Apr 2015 11:03:37 -0500 +Subject: rtlwifi: rtl8192cu: Fix kernel deadlock + +From: Larry Finger + +commit 414b7e3b9ce8b0577f613e656fdbc36b34b444dd upstream. + +The USB mini-driver in rtlwifi, which is used by rtl8192cu, issues a call to +usb_control_msg() with a timeout value of 0. In some instances where the +interface is shutting down, this infinite wait results in a CPU deadlock. A +one second timeout fixes this problem without affecting any normal operations. + +This bug is reported at https://bugzilla.novell.com/show_bug.cgi?id=927786. + +Reported-by: Bernhard Wiedemann +Tested-by: Bernhard Wiedemann +Signed-off-by: Larry Finger +Cc: Bernhard Wiedemann +Cc: Takashi Iwai +Signed-off-by: Kalle Valo +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/net/wireless/rtlwifi/usb.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/net/wireless/rtlwifi/usb.c ++++ b/drivers/net/wireless/rtlwifi/usb.c +@@ -119,7 +119,7 @@ static int _usbctrl_vendorreq_sync_read( + + do { + status = usb_control_msg(udev, pipe, request, reqtype, value, +- index, pdata, len, 0); /*max. timeout*/ ++ index, pdata, len, 1000); + if (status < 0) { + /* firmware download is checksumed, don't retry */ + if ((value >= FW_8192C_START_ADDRESS && diff --git a/queue-3.10/series b/queue-3.10/series index 1bc98730e94..57ad6469198 100644 --- a/queue-3.10/series +++ b/queue-3.10/series @@ -39,3 +39,8 @@ arm-dts-imx27-only-map-4-kbyte-for-fec-registers.patch arm-fix-missing-syscall-trace-exit.patch svcrpc-fix-potential-gssx_accept_sec_context-decoding-failures.patch md-raid5-don-t-record-new-size-if-resize_stripes-fails.patch +rtlwifi-rtl8192cu-fix-kernel-deadlock.patch +input-elantech-fix-semi-mt-protocol-for-v3-hw.patch +acpi-init-fix-the-ordering-of-acpi_reserve_resources.patch +vfs-read-file_handle-only-once-in-handle_to_path.patch +fs-binfmt_elf.c-load_elf_binary-return-einval-on-zero-length-mappings.patch diff --git a/queue-3.10/vfs-read-file_handle-only-once-in-handle_to_path.patch b/queue-3.10/vfs-read-file_handle-only-once-in-handle_to_path.patch new file mode 100644 index 00000000000..d2a2ade1a7b --- /dev/null +++ b/queue-3.10/vfs-read-file_handle-only-once-in-handle_to_path.patch @@ -0,0 +1,43 @@ +From 161f873b89136eb1e69477c847d5a5033239d9ba Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 28 Jan 2015 15:30:43 -0500 +Subject: vfs: read file_handle only once in handle_to_path + +From: Sasha Levin + +commit 161f873b89136eb1e69477c847d5a5033239d9ba upstream. + +We used to read file_handle twice. Once to get the amount of extra +bytes, and once to fetch the entire structure. + +This may be problematic since we do size verifications only after the +first read, so if the number of extra bytes changes in userspace between +the first and second calls, we'll have an incoherent view of +file_handle. + +Instead, read the constant size once, and copy that over to the final +structure without having to re-read it again. + +Signed-off-by: Sasha Levin +Cc: Al Viro +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + fs/fhandle.c | 5 +++-- + 1 file changed, 3 insertions(+), 2 deletions(-) + +--- a/fs/fhandle.c ++++ b/fs/fhandle.c +@@ -195,8 +195,9 @@ static int handle_to_path(int mountdirfd + goto out_err; + } + /* copy the full handle */ +- if (copy_from_user(handle, ufh, +- sizeof(struct file_handle) + ++ *handle = f_handle; ++ if (copy_from_user(&handle->f_handle, ++ &ufh->f_handle, + f_handle.handle_bytes)) { + retval = -EFAULT; + goto out_handle;