commit 90592c1e43aaea1d02ef309a00e9215f30624dd6 Author: Jiri Slaby Date: Mon Nov 23 14:04:07 2015 +0100 Linux 3.12.51 commit 5f2f951264d00b7abbba4ce95ead10d5ff25c0da Author: Yasuaki Ishimatsu Date: Fri Aug 22 13:27:34 2014 -0700 x86/mm/hotplug: Modify PGD entry when removing memory commit 9661d5bcd058fe15b4138a00d96bd36516134543 upstream. When hot-adding/removing memory, sync_global_pgds() is called for synchronizing PGD to PGD entries of all processes MM. But when hot-removing memory, sync_global_pgds() does not work correctly. At first, sync_global_pgds() checks whether target PGD is none or not. And if PGD is none, the PGD is skipped. But when hot-removing memory, PGD may be none since PGD may be cleared by free_pud_table(). So when sync_global_pgds() is called after hot-removing memory, sync_global_pgds() should not skip PGD even if the PGD is none. And sync_global_pgds() must clear PGD entries of all processes MM. Currently sync_global_pgds() does not clear PGD entries of all processes MM when hot-removing memory. So when hot adding memory which is same memory range as removed memory after hot-removing memory, following call traces are shown: kernel BUG at arch/x86/mm/init_64.c:206! ... [] kernel_physical_mapping_init+0x1b2/0x1d2 [] init_memory_mapping+0x1d4/0x380 [] arch_add_memory+0x3d/0xd0 [] add_memory+0xb9/0x1b0 [] acpi_memory_device_add+0x1af/0x28e [] acpi_bus_device_attach+0x8c/0xf0 [] acpi_ns_walk_namespace+0xc8/0x17f [] ? acpi_bus_type_and_status+0xb7/0xb7 [] ? acpi_bus_type_and_status+0xb7/0xb7 [] acpi_walk_namespace+0x95/0xc5 [] acpi_bus_scan+0x9a/0xc2 [] acpi_scan_bus_device_check+0x8b/0x12e [] acpi_scan_device_check+0x13/0x15 [] acpi_os_execute_deferred+0x25/0x32 [] process_one_work+0x17b/0x460 [] worker_thread+0x11b/0x400 [] ? rescuer_thread+0x400/0x400 [] kthread+0xcf/0xe0 [] ? kthread_create_on_node+0x140/0x140 [] ret_from_fork+0x7c/0xb0 [] ? kthread_create_on_node+0x140/0x140 This patch clears PGD entries of all processes MM when sync_global_pgds() is called after hot-removing memory Signed-off-by: Yasuaki Ishimatsu Acked-by: Toshi Kani Signed-off-by: Andrew Morton Cc: Tang Chen Cc: Gu Zheng Cc: Zhang Yanfei Cc: Linus Torvalds Signed-off-by: Ingo Molnar Cc: Vlastimil Babka Signed-off-by: Jiri Slaby commit 3434ce3d38e41b0c46c932b1b06913cb42197f9c Author: Yasuaki Ishimatsu Date: Fri Aug 22 13:27:31 2014 -0700 x86/mm/hotplug: Pass sync_global_pgds() a correct argument in remove_pagetable() commit 5255e0a79fcc0ff47b387af92bd9ef5729b1b859 upstream. When hot-adding memory after hot-removing memory, following call traces are shown: kernel BUG at arch/x86/mm/init_64.c:206! ... [] kernel_physical_mapping_init+0x1b2/0x1d2 [] init_memory_mapping+0x1d4/0x380 [] arch_add_memory+0x3d/0xd0 [] add_memory+0xb9/0x1b0 [] acpi_memory_device_add+0x1af/0x28e [] acpi_bus_device_attach+0x8c/0xf0 [] acpi_ns_walk_namespace+0xc8/0x17f [] ? acpi_bus_type_and_status+0xb7/0xb7 [] ? acpi_bus_type_and_status+0xb7/0xb7 [] acpi_walk_namespace+0x95/0xc5 [] acpi_bus_scan+0x9a/0xc2 [] acpi_scan_bus_device_check+0x8b/0x12e [] acpi_scan_device_check+0x13/0x15 [] acpi_os_execute_deferred+0x25/0x32 [] process_one_work+0x17b/0x460 [] worker_thread+0x11b/0x400 [] ? rescuer_thread+0x400/0x400 [] kthread+0xcf/0xe0 [] ? kthread_create_on_node+0x140/0x140 [] ret_from_fork+0x7c/0xb0 [] ? kthread_create_on_node+0x140/0x140 The patch-set fixes the issue. This patch (of 2): remove_pagetable() gets start argument and passes the argument to sync_global_pgds(). In this case, the argument must not be modified. If the argument is modified and passed to sync_global_pgds(), sync_global_pgds() does not correctly synchronize PGD to PGD entries of all processes MM since synchronized range of memory [start, end] is wrong. Unfortunately the start argument is modified in remove_pagetable(). So this patch fixes the issue. Signed-off-by: Yasuaki Ishimatsu Acked-by: Toshi Kani Signed-off-by: Andrew Morton Cc: Tang Chen Cc: Gu Zheng Cc: Zhang Yanfei Cc: Linus Torvalds Signed-off-by: Ingo Molnar Cc: Vlastimil Babka Signed-off-by: Jiri Slaby commit 49f9add06964fe16997aa34099e7bb31c39b0314 Author: Marcelo Leitner Date: Mon Feb 23 11:17:13 2015 -0300 ipv6: addrconf: validate new MTU before applying it commit 77751427a1ff25b27d47a4c36b12c3c8667855ac upstream. Currently we don't check if the new MTU is valid or not and this allows one to configure a smaller than minimum allowed by RFCs or even bigger than interface own MTU, which is a problem as it may lead to packet drops. If you have a daemon like NetworkManager running, this may be exploited by remote attackers by forging RA packets with an invalid MTU, possibly leading to a DoS. (NetworkManager currently only validates for values too small, but not for too big ones.) The fix is just to make sure the new value is valid. That is, between IPV6_MIN_MTU and interface's MTU. Note that similar check is already performed at ndisc_router_discovery(), for when kernel itself parses the RA. Signed-off-by: Marcelo Ricardo Leitner Signed-off-by: Sabrina Dubroca Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 2b27106cd93020563185ea94618ea5019308226b Author: Nadav Amit Date: Thu Sep 18 22:39:40 2014 +0300 KVM: x86: Use new is_noncanonical_address in _linearize commit 4be4de7ef9fd3a4d77320d4713970299ffecd286 upstream. Replace the current canonical address check with the new function which is identical. Signed-off-by: Nadav Amit Signed-off-by: Paolo Bonzini Signed-off-by: Jiri Slaby commit e4bcfa44c82cb5bcfb44a4722c80686096c2e181 Author: Nadav Amit Date: Tue Oct 28 00:03:43 2014 +0200 KVM: x86: Fix far-jump to non-canonical check commit 7e46dddd6f6cd5dbf3c7bd04a7e75d19475ac9f2 upstream. Commit d1442d85cc30 ("KVM: x86: Handle errors when RIP is set during far jumps") introduced a bug that caused the fix to be incomplete. Due to incorrect evaluation, far jump to segment with L bit cleared (i.e., 32-bit segment) and RIP with any of the high bits set (i.e, RIP[63:32] != 0) set may not trigger #GP. As we know, this imposes a security problem. In addition, the condition for two warnings was incorrect. Fixes: d1442d85cc30ea75f7d399474ca738e0bc96f715 Reported-by: Dan Carpenter Signed-off-by: Nadav Amit [Add #ifdef CONFIG_X86_64 to avoid complaints of undefined behavior. - Paolo] Signed-off-by: Paolo Bonzini Signed-off-by: Jiri Slaby commit 4c6a0e0edfe824edd777a496f46817b4fb465cbd Author: Paolo Bonzini Date: Tue Nov 10 09:14:39 2015 +0100 KVM: svm: unconditionally intercept #DB commit cbdb967af3d54993f5814f1cee0ed311a055377d upstream. This is needed to avoid the possibility that the guest triggers an infinite stream of #DB exceptions (CVE-2015-8104). VMX is not affected: because it does not save DR6 in the VMCS, it already intercepts #DB unconditionally. Reported-by: Jan Beulich Signed-off-by: Paolo Bonzini Signed-off-by: Jiri Slaby commit 0ccaee7be83eb288e8baacf6eebd4d8b8593f462 Author: Eric Northup Date: Tue Nov 3 18:03:53 2015 +0100 KVM: x86: work around infinite loop in microcode when #AC is delivered commit 54a20552e1eae07aa240fa370a0293e006b5faed upstream. It was found that a guest can DoS a host by triggering an infinite stream of "alignment check" (#AC) exceptions. This causes the microcode to enter an infinite loop where the core never receives another interrupt. The host kernel panics pretty quickly due to the effects (CVE-2015-5307). Signed-off-by: Eric Northup Signed-off-by: Paolo Bonzini Signed-off-by: Jiri Slaby commit 97a51976c67e9dd841026a60f200f41c292fce37 Author: Nadav Amit Date: Mon Jul 21 14:37:24 2014 +0300 KVM: x86: Defining missing x86 vectors commit c9cdd085bb75226879fd468b88e2e7eb467325b7 upstream. Defining XE, XM and VE vector numbers. Signed-off-by: Nadav Amit Signed-off-by: Paolo Bonzini Signed-off-by: Jiri Slaby commit bd6e04696299ce030e8650a96151fe383c431dce Author: David Howells Date: Thu Oct 15 17:21:37 2015 +0100 KEYS: Fix crash when attempt to garbage collect an uninstantiated keyring commit f05819df10d7b09f6d1eb6f8534a8f68e5a4fe61 upstream. The following sequence of commands: i=`keyctl add user a a @s` keyctl request2 keyring foo bar @t keyctl unlink $i @s tries to invoke an upcall to instantiate a keyring if one doesn't already exist by that name within the user's keyring set. However, if the upcall fails, the code sets keyring->type_data.reject_error to -ENOKEY or some other error code. When the key is garbage collected, the key destroy function is called unconditionally and keyring_destroy() uses list_empty() on keyring->type_data.link - which is in a union with reject_error. Subsequently, the kernel tries to unlink the keyring from the keyring names list - which oopses like this: BUG: unable to handle kernel paging request at 00000000ffffff8a IP: [] keyring_destroy+0x3d/0x88 ... Workqueue: events key_garbage_collector ... RIP: 0010:[] keyring_destroy+0x3d/0x88 RSP: 0018:ffff88003e2f3d30 EFLAGS: 00010203 RAX: 00000000ffffff82 RBX: ffff88003bf1a900 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 000000003bfc6901 RDI: ffffffff81a73a40 RBP: ffff88003e2f3d38 R08: 0000000000000152 R09: 0000000000000000 R10: ffff88003e2f3c18 R11: 000000000000865b R12: ffff88003bf1a900 R13: 0000000000000000 R14: ffff88003bf1a908 R15: ffff88003e2f4000 ... CR2: 00000000ffffff8a CR3: 000000003e3ec000 CR4: 00000000000006f0 ... Call Trace: [] key_gc_unused_keys.constprop.1+0x5d/0x10f [] key_garbage_collector+0x1fa/0x351 [] process_one_work+0x28e/0x547 [] worker_thread+0x26e/0x361 [] ? rescuer_thread+0x2a8/0x2a8 [] kthread+0xf3/0xfb [] ? kthread_create_on_node+0x1c2/0x1c2 [] ret_from_fork+0x3f/0x70 [] ? kthread_create_on_node+0x1c2/0x1c2 Note the value in RAX. This is a 32-bit representation of -ENOKEY. The solution is to only call ->destroy() if the key was successfully instantiated. Reported-by: Dmitry Vyukov Signed-off-by: David Howells Tested-by: Dmitry Vyukov Signed-off-by: Jiri Slaby commit f4562591c143cc272eab0d95be01dcca528627b9 Author: David Howells Date: Fri Sep 25 16:30:08 2015 +0100 KEYS: Fix race between key destruction and finding a keyring by name commit 94c4554ba07adbdde396748ee7ae01e86cf2d8d7 upstream. There appears to be a race between: (1) key_gc_unused_keys() which frees key->security and then calls keyring_destroy() to unlink the name from the name list (2) find_keyring_by_name() which calls key_permission(), thus accessing key->security, on a key before checking to see whether the key usage is 0 (ie. the key is dead and might be cleaned up). Fix this by calling ->destroy() before cleaning up the core key data - including key->security. Reported-by: Petr Matousek Signed-off-by: David Howells Signed-off-by: Jiri Slaby commit 9df1a69674639ed58d04437f8b66942ca0ef72cc Author: Ilya Dryomov Date: Sun Oct 11 19:38:00 2015 +0200 rbd: prevent kernel stack blow up on rbd map commit 6d69bb536bac0d403d83db1ca841444981b280cd upstream. Mapping an image with a long parent chain (e.g. image foo, whose parent is bar, whose parent is baz, etc) currently leads to a kernel stack overflow, due to the following recursion in the reply path: rbd_osd_req_callback() rbd_obj_request_complete() rbd_img_obj_callback() rbd_img_parent_read_callback() rbd_obj_request_complete() ... Limit the parent chain to 16 images, which is ~5K worth of stack. When the above recursion is eliminated, this limit can be lifted. Fixes: http://tracker.ceph.com/issues/12538 Signed-off-by: Ilya Dryomov Reviewed-by: Josh Durgin [idryomov@gmail.com: backport to 3.10: rbd_dev->opts, context] Signed-off-by: Greg Kroah-Hartman Signed-off-by: Jiri Slaby commit a436ef7ab775920b278b3485526455a97736c4e3 Author: Ilya Dryomov Date: Sun Oct 11 19:38:00 2015 +0200 rbd: don't leak parent_spec in rbd_dev_probe_parent() commit 1f2c6651f69c14d0d3a9cfbda44ea101b02160ba upstream. Currently we leak parent_spec and trigger a "parent reference underflow" warning if rbd_dev_create() in rbd_dev_probe_parent() fails. The problem is we take the !parent out_err branch and that only drops refcounts; parent_spec that would've been freed had we called rbd_dev_unparent() remains and triggers rbd_warn() in rbd_dev_parent_put() - at that point we have parent_spec != NULL and parent_ref == 0, so counter ends up being -1 after the decrement. Redo rbd_dev_probe_parent() to fix this. Signed-off-by: Ilya Dryomov [idryomov@gmail.com: backport to < 4.2: rbd_dev->opts] Reviewed-by: Alex Elder Signed-off-by: Greg Kroah-Hartman Signed-off-by: Jiri Slaby commit 6c2295ef2fb999cc0bed5e722e6eddcc56742e14 Author: Florian Fainelli Date: Sat Oct 3 13:03:47 2015 -0700 ARM: orion: Fix DSA platform device after mvmdio conversion commit d836ace65ee98d7079bc3c5afdbcc0e27dca20a3 upstream. DSA expects the host_dev pointer to be the device structure associated with the MDIO bus controller driver. First commit breaking that was c3a07134e6aa ("mv643xx_eth: convert to use the Marvell Orion MDIO driver"), and then, it got completely under the radar for a while. Reported-by: Frans van de Wiel Fixes: c3a07134e6aa ("mv643xx_eth: convert to use the Marvell Orion MDIO driver") CC: stable@vger.kernel.org Signed-off-by: Florian Fainelli Signed-off-by: Gregory CLEMENT Signed-off-by: Jiri Slaby commit 9bc623ed14f83e2facf5ada94405d39c2a7be3fd Author: Peter Hurley Date: Wed Mar 11 09:19:16 2015 -0400 serial: 8250_dw: Fix deadlock in LCR workaround commit 7fd6f640f2dd17dac6ddd6702c378cb0bb9cfa11 upstream. Trying to write console output from within the serial console driver while the port->lock is held causes recursive deadlock: CPU 0 spin_lock_irqsave(&port->lock) printk() console_unlock() call_console_drivers() serial8250_console_write() spin_lock_irqsave(&port->lock) ** DEADLOCK ** The 8250_dw i/o accessors try to write a console error message if the LCR workaround was unsuccessful. When the port->lock is already held (eg., when called from serial8250_set_termios()), this deadlocks. Make the error message a FIXME until a general solution is devised. Cc: Tim Kryger Reported-by: Zhang Zhen Signed-off-by: Peter Hurley Signed-off-by: Greg Kroah-Hartman Signed-off-by: Jiri Slaby commit 30dd76cda0dccffcfa12f66913c6fe8b1b8ef396 Author: hayeswang Date: Wed Jul 9 14:52:51 2014 +0800 r8169: disable L23 commit b51ecea852b712618796d9eab8428a7d5f1f106f upstream. For RTL8411, RTL8111G, RTL8402, RTL8105, and RTL8106, disable the feature of entering the L2/L3 link state of the PCIe. When the nic starts the process of entering the L2/L3 link state and the PCI reset occurs before the work is finished, the work would be queued and continue after the next the PCI reset occurs. This causes the device stays in L2/L3 link state, and the system couldn't find the device. Signed-off-by: Hayes Wang Acked-by: Francois Romieu Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit e63bb8210a3cd08aebd01c8dd55e18754ef9c4ea Author: hayeswang Date: Tue Mar 11 15:11:59 2014 +0800 r8169: fix the incorrect tx descriptor version commit f75761b6b5bf6277296505941d2dd8e11f9b5c35 upstream. The tx descriptor version of RTL8111B belong to RTL_TD_0. Signed-off-by: Hayes Wang Acked-by: Francois Romieu Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 9512204c65e6b7d2a30031e9f1594e099bb5a558 Author: Wei Yongjun Date: Mon Nov 11 14:16:16 2013 +0800 macmace: add missing platform_set_drvdata() in mace_probe() commit 06a2feb9e3bd0d2d555ccb19607ff5583cfa03e8 upstream. Add missing platform_set_drvdata() in mace_probe(), otherwise calling platform_get_drvdata() in mac_mace_device_remove() may returns NULL. Signed-off-by: Wei Yongjun Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 8556e3af49a4bcc5bbfd3582a20a4e4163f8b455 Author: Marc Zyngier Date: Tue Aug 5 16:44:39 2014 +0100 net: sun4i-emac: fix memory leak on bad packet commit 2670cc699a66c4cf268cb3e3f6dfc325ec14f224 upstream. Upon reception of a new frame, the emac driver checks for a number of error conditions, and flag the packet as "bad" if any of these are present. It then allocates a skb unconditionally, but only uses it if the packet is "good". On the error path, the skb is just forgotten, and the system leaks memory. The piece of junk I have on my desk seems to encounter such error frequently enough so that the box goes OOM after a couple of days, which makes me grumpy. Fix this by moving the allocation on the "good_packet" path (and convert it to netdev_alloc_skb while we're at it). Tested on a random Allwinner A20 board. Cc: Stefan Roese Cc: Maxime Ripard Signed-off-by: Marc Zyngier Acked-by: Maxime Ripard Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 79f4fd24076c15fa1d59cc5dfa4646d550c3432b Author: Yan, Zheng Date: Wed Jul 30 10:12:47 2014 +0800 ceph: fix kick_requests() commit 282c105225ec3229f344c5fced795b9e1e634440 upstream. __do_request() may unregister the request. So we should update iterator 'p' before calling __do_request() Signed-off-by: "Yan, Zheng" Signed-off-by: Jiri Slaby commit 3057240acb6d1cc2f41d27f80f4a35bc85d949ae Author: Yan, Zheng Date: Thu Sep 11 14:25:18 2014 +0800 ceph: protect kick_requests() with mdsc->mutex commit 656e4382948d4b2c81bdaf707f1400f53eff2625 upstream. Signed-off-by: "Yan, Zheng" Reviewed-by: Sage Weil Signed-off-by: Jiri Slaby commit fcd082c0640d0f8eef3d0d2a17a62c9446a77cf2 Author: Yan, Zheng Date: Thu Sep 11 14:28:56 2014 +0800 ceph: make sure request isn't in any waiting list when kicking request. commit 03974e8177b36d672eb59658f976f03cb77c1129 upstream. we may corrupt waiting list if a request in the waiting list is kicked. Signed-off-by: "Yan, Zheng" Reviewed-by: Sage Weil Signed-off-by: Jiri Slaby commit dbbcea97ecdcee66c453ac4127cdf9bc6c8481a0 Author: Ani Sinha Date: Mon Sep 8 14:49:59 2014 -0700 net:socket: set msg_namelen to 0 if msg_name is passed as NULL in msghdr struct from userland. commit 6a2a2b3ae0759843b22c929881cc184b00cc63ff upstream. Linux manpage for recvmsg and sendmsg calls does not explicitly mention setting msg_namelen to 0 when msg_name passed set as NULL. When developers don't set msg_namelen member in msghdr, it might contain garbage value which will fail the validation check and sendmsg and recvmsg calls from kernel will return EINVAL. This will break old binaries and any code for which there is no access to source code. To fix this, we set msg_namelen to 0 when msg_name is passed as NULL from userland. Signed-off-by: Ani Sinha Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 5d7af5b07a42bf3292ca1d359c89b1fdd0ef534e Author: Vasily Averin Date: Mon May 5 00:17:48 2014 +0400 bridge: superfluous skb->nfct check in br_nf_dev_queue_xmit commit aff09ce303f83bd370772349238482ae422a2341 upstream. Currently bridge can silently drop ipv4 fragments. If node have loaded nf_defrag_ipv4 module but have no nf_conntrack_ipv4, br_nf_pre_routing defragments incoming ipv4 fragments but nfct check in br_nf_dev_queue_xmit does not allow re-fragment combined packet back, and therefore it is dropped in br_dev_queue_push_xmit without incrementing of any failcounters It seems the only way to hit the ip_fragment code in the bridge xmit path is to have a fragment list whose reassembled fragments go over the mtu. This only happens if nf_defrag is enabled. Thanks to Florian Westphal for providing feedback to clarify this. Defragmentation ipv4 is required not only in conntracks but at least in TPROXY target and socket match, therefore #ifdef is changed from NF_CONNTRACK_IPV4 to NF_DEFRAG_IPV4 Signed-off-by: Vasily Averin Signed-off-by: Pablo Neira Ayuso Signed-off-by: Jiri Slaby commit 594a70103f91b679da58cefa6c6ca14f9afb5838 Author: Anton Blanchard Date: Sun Oct 20 10:26:20 2013 +1100 powerpc/pseries: Fix dedicated processor partition detection commit 733187e29576041ceccf3b82092ca900fc929170 upstream. commit f13c13a00512 (powerpc: Stop using non-architected shared_proc field in lppaca) fixed a potential issue with shared/dedicated partition detection. The old method of detection relied on an unarchitected field (shared_proc), and this patch switched to using something architected (a non zero yield_count). Unfortunately the assertion in the Linux header that yield_count is only non zero on shared processor partitions is not true. It turns out dedicated processor partitions can increment yield_count and as such we falsely detect dedicated partitions as shared. Fix the comment, and switch back to using the old method. Signed-off-by: Anton Blanchard Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Jiri Slaby commit 09f041d02b9d5407d544d6fd5a9026072c44956f Author: Holger Eitzenberger Date: Mon Oct 28 14:42:33 2013 +0100 netfilter: xt_NFQUEUE: fix --queue-bypass regression commit d954777324ffcba0b2f8119c102237426c654eeb upstream. V3 of the NFQUEUE target ignores the --queue-bypass flag, causing packets to be dropped when the userspace listener isn't running. Regression is in since 8746ddcf12bb26 ("netfilter: xt_NFQUEUE: introduce CPU fanout"). Reported-by: Florian Westphal Signed-off-by: Holger Eitzenberger Signed-off-by: Pablo Neira Ayuso Signed-off-by: Jiri Slaby commit 2a3466123f0cb310c2201f0ae4ad3f72905b061b Author: Sasha Levin Date: Tue Sep 8 10:53:40 2015 -0400 RDS: verify the underlying transport exists before creating a connection [ Upstream commit 74e98eb085889b0d2d4908f59f6e00026063014f ] There was no verification that an underlying transport exists when creating a connection, this would cause dereferencing a NULL ptr. It might happen on sockets that weren't properly bound before attempting to send a message, which will cause a NULL ptr deref: [135546.047719] kasan: GPF could be caused by NULL-ptr deref or user memory accessgeneral protection fault: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN [135546.051270] Modules linked in: [135546.051781] CPU: 4 PID: 15650 Comm: trinity-c4 Not tainted 4.2.0-next-20150902-sasha-00041-gbaa1222-dirty #2527 [135546.053217] task: ffff8800835bc000 ti: ffff8800bc708000 task.ti: ffff8800bc708000 [135546.054291] RIP: __rds_conn_create (net/rds/connection.c:194) [135546.055666] RSP: 0018:ffff8800bc70fab0 EFLAGS: 00010202 [135546.056457] RAX: dffffc0000000000 RBX: 0000000000000f2c RCX: ffff8800835bc000 [135546.057494] RDX: 0000000000000007 RSI: ffff8800835bccd8 RDI: 0000000000000038 [135546.058530] RBP: ffff8800bc70fb18 R08: 0000000000000001 R09: 0000000000000000 [135546.059556] R10: ffffed014d7a3a23 R11: ffffed014d7a3a21 R12: 0000000000000000 [135546.060614] R13: 0000000000000001 R14: ffff8801ec3d0000 R15: 0000000000000000 [135546.061668] FS: 00007faad4ffb700(0000) GS:ffff880252000000(0000) knlGS:0000000000000000 [135546.062836] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [135546.063682] CR2: 000000000000846a CR3: 000000009d137000 CR4: 00000000000006a0 [135546.064723] Stack: [135546.065048] ffffffffafe2055c ffffffffafe23fc1 ffffed00493097bf ffff8801ec3d0008 [135546.066247] 0000000000000000 00000000000000d0 0000000000000000 ac194a24c0586342 [135546.067438] 1ffff100178e1f78 ffff880320581b00 ffff8800bc70fdd0 ffff880320581b00 [135546.068629] Call Trace: [135546.069028] ? __rds_conn_create (include/linux/rcupdate.h:856 net/rds/connection.c:134) [135546.069989] ? rds_message_copy_from_user (net/rds/message.c:298) [135546.071021] rds_conn_create_outgoing (net/rds/connection.c:278) [135546.071981] rds_sendmsg (net/rds/send.c:1058) [135546.072858] ? perf_trace_lock (include/trace/events/lock.h:38) [135546.073744] ? lockdep_init (kernel/locking/lockdep.c:3298) [135546.074577] ? rds_send_drop_to (net/rds/send.c:976) [135546.075508] ? __might_fault (./arch/x86/include/asm/current.h:14 mm/memory.c:3795) [135546.076349] ? __might_fault (mm/memory.c:3795) [135546.077179] ? rds_send_drop_to (net/rds/send.c:976) [135546.078114] sock_sendmsg (net/socket.c:611 net/socket.c:620) [135546.078856] SYSC_sendto (net/socket.c:1657) [135546.079596] ? SYSC_connect (net/socket.c:1628) [135546.080510] ? trace_dump_stack (kernel/trace/trace.c:1926) [135546.081397] ? ring_buffer_unlock_commit (kernel/trace/ring_buffer.c:2479 kernel/trace/ring_buffer.c:2558 kernel/trace/ring_buffer.c:2674) [135546.082390] ? trace_buffer_unlock_commit (kernel/trace/trace.c:1749) [135546.083410] ? trace_event_raw_event_sys_enter (include/trace/events/syscalls.h:16) [135546.084481] ? do_audit_syscall_entry (include/trace/events/syscalls.h:16) [135546.085438] ? trace_buffer_unlock_commit (kernel/trace/trace.c:1749) [135546.085515] rds_ib_laddr_check(): addr 36.74.25.172 ret -99 node type -1 Acked-by: Santosh Shilimkar Signed-off-by: Sasha Levin Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 7c11e86ec40e52468fe65acf89c6da7a6d833a44 Author: Jason Wang Date: Wed Aug 5 10:34:04 2015 +0800 virtio-net: drop NETIF_F_FRAGLIST [ Upstream commit 48900cb6af4282fa0fb6ff4d72a81aa3dadb5c39 ] virtio declares support for NETIF_F_FRAGLIST, but assumes that there are at most MAX_SKB_FRAGS + 2 fragments which isn't always true with a fraglist. A longer fraglist in the skb will make the call to skb_to_sgvec overflow the sg array, leading to memory corruption. Drop NETIF_F_FRAGLIST so we only get what we can handle. Cc: Michael S. Tsirkin Signed-off-by: Jason Wang Acked-by: Michael S. Tsirkin Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit e98b2397a2181f4d066342beb6a220e43c404e44 Author: Eric Dumazet Date: Mon Nov 9 17:51:23 2015 -0800 net: fix a race in dst_release() [ Upstream commit d69bbf88c8d0b367cf3e3a052f6daadf630ee566 ] Only cpu seeing dst refcount going to 0 can safely dereference dst->flags. Otherwise an other cpu might already have freed the dst. Fixes: 27b75c95f10d ("net: avoid RCU for NOCACHE dst") Reported-by: Greg Thelen Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 6651ab3cd17428ac02a53a2f0e90f089a203f03c Author: Eric Dumazet Date: Fri Oct 2 16:54:31 2015 -0700 net: avoid NULL deref in inet_ctl_sock_destroy() [ Upstream commit 8fa677d2706d325d71dab91bf6e6512c05214e37 ] Under low memory conditions, tcp_sk_init() and icmp_sk_init() can both iterate on all possible cpus and call inet_ctl_sock_destroy(), with eventual NULL pointer. Signed-off-by: Eric Dumazet Reported-by: Dmitry Vyukov Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 1df1b617c4884a39627da12a64caf5755951b026 Author: Eric Dumazet Date: Fri Oct 2 16:54:31 2015 -0700 sit: fix sit0 percpu double allocations [ Upstream commit 4ece9009774596ee3df0acba65a324b7ea79387c ] sit0 device allocates its percpu storage twice : - One time in ipip6_tunnel_init() - One time in ipip6_fb_tunnel_init() Thus we leak 48 bytes per possible cpu per network namespace dismantle. ipip6_fb_tunnel_init() can be much simpler and does not return an error, and should be called after register_netdev() Note that ipip6_tunnel_clone_6rd() also needs to be called after register_netdev() (calling ipip6_tunnel_init()) Fixes: ebe084aafb7e ("sit: Use ipip6_tunnel_init as the ndo_init function.") Signed-off-by: Eric Dumazet Reported-by: Dmitry Vyukov Cc: Steffen Klassert Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 33b0e82c27c542d0b7002f4f253b257ab37a2faf Author: Bjørn Mork Date: Thu Oct 1 16:54:31 2015 -0700 qmi_wwan: fix entry for HP lt4112 LTE/HSPA+ Gobi 4G Module [ Upstream commit 70910791731b5956171e1bfcad707766b8e18fee ] The lt4112 is a HP branded Huawei me906e modem. Like other Huawei modems, it does not have a fixed interface to function mapping. Instead it uses a Huawei specific scheme: functions are mapped by subclass and protocol. However, the HP vendor ID is used for modems from many different manufacturers using different schemes, so we cannot apply a generic vendor rule like we do for the Huawei vendor ID. Replace the previous lt4112 entry pointing to an arbitrary interface number with a device specific subclass + protocol match. Reported-and-tested-by: Muri Nicanor Tested-by: Martin Hauke Fixes: bb2bdeb83fb1 ("qmi_wwan: Add support for HP lt4112 LTE/HSPA+ Gobi 4G Modem") Signed-off-by: Bjørn Mork Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 7b831da141a97f9bc60d3b6ef0b21dcaf596ec74 Author: Ani Sinha Date: Fri Oct 30 16:54:31 2015 -0700 ipmr: fix possible race resulting from improper usage of IP_INC_STATS_BH() in preemptible context. [ Upstream commit 44f49dd8b5a606870a1f21101522a0f9c4414784 ] Fixes the following kernel BUG : BUG: using __this_cpu_add() in preemptible [00000000] code: bash/2758 caller is __this_cpu_preempt_check+0x13/0x15 CPU: 0 PID: 2758 Comm: bash Tainted: P O 3.18.19 #2 ffffffff8170eaca ffff880110d1b788 ffffffff81482b2a 0000000000000000 0000000000000000 ffff880110d1b7b8 ffffffff812010ae ffff880007cab800 ffff88001a060800 ffff88013a899108 ffff880108b84240 ffff880110d1b7c8 Call Trace: [] dump_stack+0x52/0x80 [] check_preemption_disabled+0xce/0xe1 [] __this_cpu_preempt_check+0x13/0x15 [] ipmr_queue_xmit+0x647/0x70c [] ip_mr_forward+0x32f/0x34e [] ip_mroute_setsockopt+0xe03/0x108c [] ? get_parent_ip+0x11/0x42 [] ? pollwake+0x4d/0x51 [] ? default_wake_function+0x0/0xf [] ? get_parent_ip+0x11/0x42 [] ? __wake_up_common+0x45/0x77 [] ? _raw_spin_unlock_irqrestore+0x1d/0x32 [] ? __wake_up_sync_key+0x4a/0x53 [] ? sock_def_readable+0x71/0x75 [] do_ip_setsockopt+0x9d/0xb55 [] ? unix_seqpacket_sendmsg+0x3f/0x41 [] ? sock_sendmsg+0x6d/0x86 [] ? sockfd_lookup_light+0x12/0x5d [] ? SyS_sendto+0xf3/0x11b [] ? new_sync_read+0x82/0xaa [] compat_ip_setsockopt+0x3b/0x99 [] compat_raw_setsockopt+0x11/0x32 [] compat_sock_common_setsockopt+0x18/0x1f [] compat_SyS_setsockopt+0x1a9/0x1cf [] compat_SyS_socketcall+0x180/0x1e3 [] cstar_dispatch+0x7/0x1e Signed-off-by: Ani Sinha Acked-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit f1004ea754724fbab6aed11d6366f90dc205725e Author: Phil Reid Date: Fri Oct 30 16:43:55 2015 +0800 stmmac: Correctly report PTP capabilities. [ Upstream commit e6dbe1eb2db0d7a14991c06278dd3030c45fb825 ] priv->hwts_*_en indicate if timestamping is enabled/disabled at run time. But priv->dma_cap.time_stamp and priv->dma_cap.atime_stamp indicates HW is support for PTPv1/PTPv2. Signed-off-by: Phil Reid Acked-by: Richard Cochran Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 492ee74a9ab0c953e82cbcb2a4e801e7b5c886de Author: Carol L Soto Date: Tue Oct 27 17:36:20 2015 +0200 net/mlx4: Copy/set only sizeof struct mlx4_eqe bytes [ Upstream commit c02b05011fadf8e409e41910217ca689f2fc9d91 ] When doing memcpy/memset of EQEs, we should use sizeof struct mlx4_eqe as the base size and not caps.eqe_size which could be bigger. If caps.eqe_size is bigger than the struct mlx4_eqe then we corrupt data in the master context. When using a 64 byte stride, the memcpy copied over 63 bytes to the slave_eq structure. This resulted in copying over the entire eqe of interest, including its ownership bit -- and also 31 bytes of garbage into the next WQE in the slave EQ -- which did NOT include the ownership bit (and therefore had no impact). However, once the stride is increased to 128, we are overwriting the ownership bits of *three* eqes in the slave_eq struct. This results in an incorrect ownership bit for those eqes, which causes the eq to seem to be full. The issue therefore surfaced only once 128-byte EQEs started being used in SRIOV and (overarchitectures that have 128/256 byte cache-lines such as PPC) - e.g after commit 77507aa249ae "net/mlx4_core: Enable CQE/EQE stride support". Fixes: 08ff32352d6f ('mlx4: 64-byte CQE/EQE support') Signed-off-by: Carol L Soto Signed-off-by: Jack Morgenstein Signed-off-by: Or Gerlitz Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit c03f8638ebfbc9c9ddc542bbb78b96ace2cd64ee Author: Sowmini Varadhan Date: Mon Oct 26 12:46:37 2015 -0400 RDS-TCP: Recover correctly from pskb_pull()/pksb_trim() failure in rds_tcp_data_recv [ Upstream commit 8ce675ff39b9958d1c10f86cf58e357efaafc856 ] Either of pskb_pull() or pskb_trim() may fail under low memory conditions. If rds_tcp_data_recv() ignores such failures, the application will receive corrupted data because the skb has not been correctly carved to the RDS datagram size. Avoid this by handling pskb_pull/pskb_trim failure in the same manner as the skb_clone failure: bail out of rds_tcp_data_recv(), and retry via the deferred call to rds_send_worker() that gets set up on ENOMEM from rds_tcp_read_sock() Signed-off-by: Sowmini Varadhan Acked-by: Santosh Shilimkar Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 037eb89d8b8f6119adae62f87f77f32eb384231b Author: Guillaume Nault Date: Thu Oct 22 16:57:10 2015 +0200 ppp: fix pppoe_dev deletion condition in pppoe_release() [ Upstream commit 1acea4f6ce1b1c0941438aca75dd2e5c6b09db60 ] We can't rely on PPPOX_ZOMBIE to decide whether to clear po->pppoe_dev. PPPOX_ZOMBIE can be set by pppoe_disc_rcv() even when po->pppoe_dev is NULL. So we have no guarantee that (sk->sk_state & PPPOX_ZOMBIE) implies (po->pppoe_dev != NULL). Since we're releasing a PPPoE socket, we want to release the pppoe_dev if it exists and reset sk_state to PPPOX_DEAD, no matter the previous value of sk_state. So we can just check for po->pppoe_dev and avoid any assumption on sk->sk_state. Fixes: 2b018d57ff18 ("pppoe: drop PPPOX_ZOMBIEs in pppoe_release") Signed-off-by: Guillaume Nault Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 2d2d5e7745361bf7d106abd3e990579f4956ba11 Author: Jason Wang Date: Fri Oct 23 00:57:05 2015 -0400 macvtap: unbreak receiving of gro skb with frag list [ Upstream commit f23d538bc24a83c16127c2eb82c9cf1adc2b5149 ] We don't have fraglist support in TAP_FEATURES. This will lead software segmentation of gro skb with frag list. Fixes by having frag list support in TAP_FEATURES. With this patch single session of netperf receiving were restored from about 5Gb/s to about 12Gb/s on mlx4. Fixes a567dd6252 ("macvtap: simplify usage of tap_features") Cc: Vlad Yasevich Cc: Michael S. Tsirkin Signed-off-by: Jason Wang Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit c75f0a0bfdec01eac652ad6a9eaa14e7ea5d85cb Author: Dan Carpenter Date: Mon Oct 19 13:16:49 2015 +0300 irda: precedence bug in irlmp_seq_hb_idx() [ Upstream commit 50010c20597d14667eff0fdb628309986f195230 ] This is decrementing the pointer, instead of the value stored in the pointer. KASan detects it as an out of bounds reference. Reported-by: "Berry Cheng 程君(成淼)" Signed-off-by: Dan Carpenter Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit dc1546ee854c56780a29624d3bbf20a6fcd05574 Author: Tom Tucker Date: Tue Mar 25 15:14:57 2014 -0500 Fix regression in NFSRDMA server commit 7e4359e2611f95a97037e2b6905eab52f28afbeb upstream. The server regression was caused by the addition of rq_next_page (afc59400d6c65bad66d4ad0b2daf879cbff8e23e). There were a few places that were missed with the update of the rq_respages array. Signed-off-by: Tom Tucker Tested-by: Steve Wise Signed-off-by: J. Bruce Fields Signed-off-by: Jiri Slaby commit 557f3d9f4e9bc4777360b403004141bb7e047aa6 Author: Dan Williams Date: Fri May 8 15:23:55 2015 -0400 ahci: avoton port-disable reset-quirk commit dbfe8ef5599a5370abc441fcdbb382b656563eb4 upstream. Avoton AHCI occasionally sees drive probe timeouts at driver load time. When this happens SCR_STATUS indicates device detected, but no D2H FIS reception. Reset the internal link state machines by bouncing port-enable in the PCS register when this occurs. Cc: Signed-off-by: Dan Williams Signed-off-by: Tejun Heo Signed-off-by: Jiri Slaby commit 4f348a8d38f7bf2a4137acbeed2057485b6fd618 Author: Hans de Goede Date: Sat Feb 22 16:53:30 2014 +0100 libahci: Allow drivers to override start_engine commit 039ece38da45f5e6a94be3aa7611cf3634bc2461 upstream. Allwinner A10 and A20 ARM SoCs have an AHCI sata controller which needs a special register to be poked before starting the DMA engine. This register gets reset on an ahci_stop_engine call, so there is no other place then ahci_start_engine where this poking can be done. This commit allows drivers to override ahci_start_engine behavior for use by the Allwinner AHCI driver (and potentially other drivers in the future). Signed-off-by: Hans de Goede Signed-off-by: Tejun Heo Signed-off-by: Jiri Slaby commit f94234c73bc8a9cacafac2770e279534ef06825d Author: Paul Moore Date: Tue Dec 30 09:26:21 2014 -0500 audit: create private file name copies when auditing inodes commit fcf22d8267ad2601fe9b6c549d1be96401c23e0b upstream. Unfortunately, while commit 4a928436 ("audit: correctly record file names with different path name types") fixed a problem where we were not recording filenames, it created a new problem by attempting to use these file names after they had been freed. This patch resolves the issue by creating a copy of the filename which the audit subsystem frees after it is done with the string. At some point it would be nice to resolve this issue with refcounts, or something similar, instead of having to allocate/copy strings, but that is almost surely beyond the scope of a -rcX patch so we'll defer that for later. On the plus side, only audit users should be impacted by the string copying. Reported-by: Toralf Foerster Signed-off-by: Paul Moore Signed-off-by: Jiri Slaby commit 8b8c7dccfc747fe8027a84eec59b4f656fa12322 Author: Paul Moore Date: Mon Dec 22 12:27:39 2014 -0500 audit: correctly record file names with different path name types commit 4a92843601ad0f5067f441d2f0dca55bbe18c076 upstream. There is a problem with the audit system when multiple audit records are created for the same path, each with a different path name type. The root cause of the problem is in __audit_inode() when an exact match (both the path name and path name type) is not found for a path name record; the existing code creates a new path name record, but it never sets the path name in this record, leaving it NULL. This patch corrects this problem by assigning the path name to these newly created records. There are many ways to reproduce this problem, but one of the easiest is the following (assuming auditd is running): # mkdir /root/tmp/test # touch /root/tmp/test/567 # auditctl -a always,exit -F dir=/root/tmp/test # touch /root/tmp/test/567 Afterwards, or while the commands above are running, check the audit log and pay special attention to the PATH records. A faulty kernel will display something like the following for the file creation: type=SYSCALL msg=audit(1416957442.025:93): arch=c000003e syscall=2 success=yes exit=3 ... comm="touch" exe="/usr/bin/touch" type=CWD msg=audit(1416957442.025:93): cwd="/root/tmp" type=PATH msg=audit(1416957442.025:93): item=0 name="test/" inode=401409 ... nametype=PARENT type=PATH msg=audit(1416957442.025:93): item=1 name=(null) inode=393804 ... nametype=NORMAL type=PATH msg=audit(1416957442.025:93): item=2 name=(null) inode=393804 ... nametype=NORMAL While a patched kernel will show the following: type=SYSCALL msg=audit(1416955786.566:89): arch=c000003e syscall=2 success=yes exit=3 ... comm="touch" exe="/usr/bin/touch" type=CWD msg=audit(1416955786.566:89): cwd="/root/tmp" type=PATH msg=audit(1416955786.566:89): item=0 name="test/" inode=401409 ... nametype=PARENT type=PATH msg=audit(1416955786.566:89): item=1 name="test/567" inode=393804 ... nametype=NORMAL This issue was brought up by a number of people, but special credit should go to hujianyang@huawei.com for reporting the problem along with an explanation of the problem and a patch. While the original patch did have some problems (see the archive link below), it did demonstrate the problem and helped kickstart the fix presented here. * https://lkml.org/lkml/2014/9/5/66 Reported-by: hujianyang Signed-off-by: Paul Moore Acked-by: Richard Guy Briggs Signed-off-by: Jiri Slaby commit 1f71f19f190bbd80d00b175a039de8b6aa946ecd Author: Dan Carpenter Date: Fri Jul 3 11:53:03 2015 +0300 mptfusion: prevent some memory corruption commit e819cdb198319cccf4af4fc12ac4d796109d8c23 upstream. These are signed values the come from the user, we put a cap on the upper bounds but not on the lower bounds. We use "karg.dataSgeOffset" to calculate "sz". We verify "sz" and proceed as if that means that "karg.dataSgeOffset" is correct but this fails to consider that the "sz" calculations can have integer overflows. Signed-off-by: Dan Carpenter Reviewed-by: Johannes Thumshirn Signed-off-by: James Bottomley Cc: Oliver Neukum Signed-off-by: Jiri Slaby commit 8442d4876ef9d3df87d1bdb5113e6a6ee41c20d2 Author: Charles Keepax Date: Tue Jul 7 15:28:13 2015 +0100 mfd: wm5110: Add register patch for rev E and above commit 81207880cef207cd89db863f9aa1d65f22b4f2a2 upstream. Add a register patch for rev E and above that configures the location of some write sequences to assist with the headphone enables. Signed-off-by: Charles Keepax Acked-by: Lee Jones Signed-off-by: Mark Brown Cc: Oliver Neukum Signed-off-by: Jiri Slaby commit 3833b2c882b1060aff477ad911bcc7768d75d842 Author: Charles Keepax Date: Thu Jan 9 11:53:54 2014 +0000 mfd: wm5110: Add register patch for rev D chip commit 02915661dbb91b25b621ab3f387ab55311bded7f upstream. Evaluation of revision D of WM5110 suggests updates to the register patch for optimal performance. For the sake of clarity rev C of the chip does not require a register patch. Signed-off-by: Charles Keepax Signed-off-by: Lee Jones Cc: Oliver Neukum Signed-off-by: Jiri Slaby commit cfcdadb344e6bce7f3a80da83322b36d5795c22e Author: Soeren Grunewald Date: Thu Jun 11 09:25:04 2015 +0200 serial: 8250_pci: Add support for 12 port Exar boards commit be32c0cf0462c36f482b5ddcff1d8371be1e183c upstream. The Exar XR17V358 can also be combined with a XR17V354 chip to act as a single 12 port chip. This works the same way as the combining two XR17V358 chips. But the reported device id then is 0x4358. Signed-off-by: Soeren Grunewald Signed-off-by: Jiri Slaby commit 3e8c9dd24acc11db838781ca05305ed02484f2c3 Author: Soeren Grunewald Date: Tue Apr 28 16:29:49 2015 +0200 serial: 8250_pci: Add support for 16 port Exar boards commit 96a5d18bc1338786fecac73599f1681f59a59a8e upstream. The Exar XR17V358 chip usually provides only 8 ports. But two chips can be combined to act as a single 16 port chip. Therefor one chip is configured as master the second as slave by connecting the mode pin to VCC (master) or GND (slave). Then the master chip is reporting a different device-id depending on whether a slave is detected or not. The UARTs 8-15 are addressed from 0x2000-0x3fff. So the offset of 0x400 from UART to UART can be used to address all 16 ports as before. See: https://www.exar.com/common/content/document.ashx?id=1587 page 11 Signed-off-by: Soeren Grunewald Signed-off-by: Jiri Slaby commit 31eb9884abf96a1631be20ad2a317452b3818558 Author: Doron Tsur Date: Sun Oct 11 15:58:17 2015 +0300 IB/cm: Fix rb-tree duplicate free and use-after-free commit 0ca81a2840f77855bbad1b9f172c545c4dc9e6a4 upstream. ib_send_cm_sidr_rep could sometimes erase the node from the sidr (depending on errors in the process). Since ib_send_cm_sidr_rep is called both from cm_sidr_req_handler and cm_destroy_id, cm_id_priv could be either erased from the rb_tree twice or not erased at all. Fixing that by making sure it's erased only once before freeing cm_id_priv. Fixes: a977049dacde ('[PATCH] IB: Add the kernel CM implementation') Signed-off-by: Doron Tsur Signed-off-by: Matan Barak Signed-off-by: Doug Ledford Signed-off-by: Jiri Slaby commit c5891c0838328d666faff93daf46731bf85b9cc2 Author: Dāvis Mosāns Date: Fri Aug 21 07:29:22 2015 +0300 mvsas: Fix NULL pointer dereference in mvs_slot_task_free commit 2280521719e81919283b82902ac24058f87dfc1b upstream. When pci_pool_alloc fails in mvs_task_prep then task->lldd_task stays NULL but it's later used in mvs_abort_task as slot which is passed to mvs_slot_task_free causing NULL pointer dereference. Just return from mvs_slot_task_free when passed with NULL slot. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=101891 Signed-off-by: Dāvis Mosāns Reviewed-by: Tomas Henzl Reviewed-by: Johannes Thumshirn Signed-off-by: James Bottomley Signed-off-by: Jiri Slaby commit bcaee63e9cbee6443f8e87ae64ea0ea982dd0279 Author: Jes Sorensen Date: Tue Oct 20 12:09:13 2015 -0400 md/raid10: submit_bio_wait() returns 0 on success commit 681ab4696062f5aa939c9e04d058732306a97176 upstream. This was introduced with 9e882242c6193ae6f416f2d8d8db0d9126bd996b which changed the return value of submit_bio_wait() to return != 0 on error, but didn't update the caller accordingly. Fixes: 9e882242c6 ("block: Add submit_bio_wait(), remove from md") Reported-by: Bill Kuzeja Signed-off-by: Jes Sorensen Signed-off-by: NeilBrown Signed-off-by: Jiri Slaby commit 4ab46026e088c6e7801e278101d66a60ce6b72b8 Author: Jes Sorensen Date: Tue Oct 20 12:09:12 2015 -0400 md/raid1: submit_bio_wait() returns 0 on success commit 203d27b0226a05202438ddb39ef0ef1acb14a759 upstream. This was introduced with 9e882242c6193ae6f416f2d8d8db0d9126bd996b which changed the return value of submit_bio_wait() to return != 0 on error, but didn't update the caller accordingly. Fixes: 9e882242c6 ("block: Add submit_bio_wait(), remove from md") Reported-by: Bill Kuzeja Signed-off-by: Jes Sorensen Signed-off-by: NeilBrown Signed-off-by: Jiri Slaby commit b7775d1cd0a78e447ced2dbb41a0e1586b1cb58e Author: Herbert Xu Date: Mon Oct 19 18:23:57 2015 +0800 crypto: api - Only abort operations on fatal signal commit 3fc89adb9fa4beff31374a4bf50b3d099d88ae83 upstream. Currently a number of Crypto API operations may fail when a signal occurs. This causes nasty problems as the caller of those operations are often not in a good position to restart the operation. In fact there is currently no need for those operations to be interrupted by user signals at all. All we need is for them to be killable. This patch replaces the relevant calls of signal_pending with fatal_signal_pending, and wait_for_completion_interruptible with wait_for_completion_killable, respectively. Signed-off-by: Herbert Xu Signed-off-by: Jiri Slaby commit c6bf30eb4c6789da93e36e68554b51dd99c2de69 Author: Peter Zijlstra Date: Thu Aug 20 10:34:59 2015 +0930 module: Fix locking in symbol_put_addr() commit 275d7d44d802ef271a42dc87ac091a495ba72fc5 upstream. Poma (on the way to another bug) reported an assertion triggering: [] module_assert_mutex_or_preempt+0x49/0x90 [] __module_address+0x32/0x150 [] __module_text_address+0x16/0x70 [] symbol_put_addr+0x29/0x40 [] dvb_frontend_detach+0x7d/0x90 [dvb_core] Laura Abbott produced a patch which lead us to inspect symbol_put_addr(). This function has a comment claiming it doesn't need to disable preemption around the module lookup because it holds a reference to the module it wants to find, which therefore cannot go away. This is wrong (and a false optimization too, preempt_disable() is really rather cheap, and I doubt any of this is on uber critical paths, otherwise it would've retained a pointer to the actual module anyway and avoided the second lookup). While its true that the module cannot go away while we hold a reference on it, the data structure we do the lookup in very much _CAN_ change while we do the lookup. Therefore fix the comment and add the required preempt_disable(). Reported-by: poma Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Rusty Russell Fixes: a6e6abd575fc ("module: remove module_text_address()") Signed-off-by: Jiri Slaby commit 54001184d4c2f4660a783437d318d3868239690a Author: Cathy Avery Date: Fri Oct 2 09:35:01 2015 -0400 xen-blkfront: check for null drvdata in blkback_changed (XenbusStateClosing) commit a54c8f0f2d7df525ff997e2afe71866a1a013064 upstream. xen-blkfront will crash if the check to talk_to_blkback() in blkback_changed()(XenbusStateInitWait) returns an error. The driver data is freed and info is set to NULL. Later during the close process via talk_to_blkback's call to xenbus_dev_fatal() the null pointer is passed to and dereference in blkfront_closing. Signed-off-by: Cathy Avery Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Jiri Slaby commit 96c5ef590f6d974bb3cd03421b7824499c9e34e3 Author: Laura Abbott Date: Mon Oct 12 11:30:13 2015 +0300 xhci: Add spurious wakeup quirk for LynxPoint-LP controllers commit fd7cd061adcf5f7503515ba52b6a724642a839c8 upstream. We received several reports of systems rebooting and powering on after an attempted shutdown. Testing showed that setting XHCI_SPURIOUS_WAKEUP quirk in addition to the XHCI_SPURIOUS_REBOOT quirk allowed the system to shutdown as expected for LynxPoint-LP xHCI controllers. Set the quirk back. Note that the quirk was originally introduced for LynxPoint and LynxPoint-LP just for this same reason. See: commit 638298dc66ea ("xhci: Fix spurious wakeups after S5 on Haswell") It was later limited to only concern HP machines as it caused regression on some machines, see both bug and commit: Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=66171 commit 6962d914f317 ("xhci: Limit the spurious wakeup fix only to HP machines") Later it was discovered that the powering on after shutdown was limited to LynxPoint-LP (Haswell-ULT) and that some non-LP HP machine suffered from spontaneous resume from S3 (which should not be related to the SPURIOUS_WAKEUP quirk at all). An attempt to fix this then removed the SPURIOUS_WAKEUP flag usage completely. commit b45abacde3d5 ("xhci: no switching back on non-ULT Haswell") Current understanding is that LynxPoint-LP (Haswell ULT) machines need the SPURIOUS_WAKEUP quirk, otherwise they will restart, and plain Lynxpoint (Haswell) machines may _not_ have the quirk set otherwise they again will restart. Signed-off-by: Laura Abbott Cc: Takashi Iwai Cc: Oliver Neukum [Added more history to commit message -Mathias] Signed-off-by: Mathias Nyman Signed-off-by: Jiri Slaby commit 5bdb174eff58a6f6ba8c7382ff60c569c1a33d7e Author: Mathias Nyman Date: Mon Oct 12 11:30:12 2015 +0300 xhci: handle no ping response error properly commit 3b4739b8951d650becbcd855d7d6f18ac98a9a85 upstream. If a host fails to wake up a isochronous SuperSpeed device from U1/U2 in time for a isoch transfer it will generate a "No ping response error" Host will then move to the next transfer descriptor. Handle this case in the same way as missed service errors, tag the current TD as skipped and handle it on the next transfer event. Signed-off-by: Mathias Nyman Signed-off-by: Jiri Slaby commit 76dff47884e6806e2dd71f7b9a12a4f99a344e0a Author: Mike Snitzer Date: Thu Oct 22 10:56:40 2015 -0400 dm btree: fix leak of bufio-backed block in btree_split_beneath error path commit 4dcb8b57df3593dcb20481d9d6cf79d1dc1534be upstream. btree_split_beneath()'s error path had an outstanding FIXME that speaks directly to the potential for _not_ cleaning up a previously allocated bufio-backed block. Fix this by releasing the previously allocated bufio block using unlock_block(). Reported-by: Mikulas Patocka Signed-off-by: Mike Snitzer Acked-by: Joe Thornber Signed-off-by: Jiri Slaby commit b865892e2e90302fa2e4613c181772c8659ea34e Author: Will Deacon Date: Wed Oct 28 16:56:13 2015 +0000 Revert "ARM64: unwind: Fix PC calculation" commit 9702970c7bd3e2d6fecb642a190269131d4ac16c upstream. This reverts commit e306dfd06fcb44d21c80acb8e5a88d55f3d1cf63. With this patch applied, we were the only architecture making this sort of adjustment to the PC calculation in the unwinder. This causes problems for ftrace, where the PC values are matched against the contents of the stack frames in the callchain and fail to match any records after the address adjustment. Whilst there has been some effort to change ftrace to workaround this, those patches are not yet ready for mainline and, since we're the odd architecture in this regard, let's just step in line with other architectures (like arch/arm/) for now. Signed-off-by: Will Deacon Signed-off-by: Jiri Slaby commit 787d82837c06fe7d5b8b38d5b22f5d1cdd809f5d Author: Ronny Hegewald Date: Thu Oct 15 18:50:46 2015 +0000 rbd: require stable pages if message data CRCs are enabled commit bae818ee1577c27356093901a0ea48f672eda514 upstream. rbd requires stable pages, as it performs a crc of the page data before they are send to the OSDs. But since kernel 3.9 (patch 1d1d1a767206fbe5d4c69493b7e6d2a8d08cc0a0 "mm: only enforce stable page writes if the backing device requires it") it is not assumed anymore that block devices require stable pages. This patch sets the necessary flag to get stable pages back for rbd. In a ceph installation that provides multiple ext4 formatted rbd devices "bad crc" messages appeared regularly (ca 1 message every 1-2 minutes on every OSD that provided the data for the rbd) in the OSD-logs before this patch. After this patch this messages are pretty much gone (only ca 1-2 / month / OSD). Signed-off-by: Ronny Hegewald [idryomov@gmail.com: require stable pages only in crc case, changelog] [idryomov@gmail.com: backport to 3.9-3.17: context] Signed-off-by: Ilya Dryomov Signed-off-by: Jiri Slaby commit 237956f696672c2a34aecbfda45f87e08b1950b2 Author: Ilia Mirkin Date: Tue Oct 20 01:15:39 2015 -0400 drm/nouveau/gem: return only valid domain when there's only one commit 2a6c521bb41ce862e43db46f52e7681d33e8d771 upstream. On nv50+, we restrict the valid domains to just the one where the buffer was originally created. However after the buffer is evicted to system memory, we might move it back to a different domain that was not originally valid. When sharing the buffer and retrieving its GEM_INFO data, we still want the domain that will be valid for this buffer in a pushbuf, not the one where it currently happens to be. This resolves fdo#92504 and several others. These are due to suspend evicting all buffers, making it more likely that they temporarily end up in the wrong place. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92504 Signed-off-by: Ilia Mirkin Signed-off-by: Ben Skeggs Signed-off-by: Jiri Slaby commit a0f5187efd10968161741ddbad76ff69afeb3522 Author: SeongJae Park Date: Tue Feb 4 15:58:09 2014 +0900 spi: fix pointer-integer size mismatch warning commit e1bde3b11fedace5042f0232339da90bc85666af upstream. Fix the pointer-integer size mismatch warning below: drivers/spi/spi-gpio.c: In function ‘spi_gpio_setup’: drivers/spi/spi-gpio.c:252:8: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] cs = (unsigned int) spi->controller_data; ^ Signed-off-by: SeongJae Park Signed-off-by: Mark Brown Signed-off-by: Jiri Slaby commit dc0627873295877dafe8fc2dc27ef2507b5d7024 Author: Lad, Prabhakar Date: Thu Dec 4 14:56:04 2014 +0000 power: bq24190_charger: suppress build warning commit 31f50e48e3e4ea9d503285a389d6a1b5349d66c0 upstream. This patch fixes following build warning: In file included from include/linux/printk.h:261:0, from include/linux/kernel.h:13, from include/linux/list.h:8, from include/linux/module.h:9, from drivers/power/bq24190_charger.c:11: drivers/power/bq24190_charger.c: In function ‘bq24190_irq_handler_thread’: include/linux/dynamic_debug.h:86:20: warning: ‘ss_reg’ may be used uninitialized in this function [-Wmaybe-uninitialized] __dynamic_dev_dbg(&descriptor, dev, fmt, \ ^ drivers/power/bq24190_charger.c:1211:5: note: ‘ss_reg’ was declared here u8 ss_reg, f_reg; ^ In file included from include/linux/printk.h:261:0, from include/linux/kernel.h:13, from include/linux/list.h:8, from include/linux/module.h:9, from drivers/power/bq24190_charger.c:11: include/linux/dynamic_debug.h:86:20: warning: ‘f_reg’ may be used uninitialized in this function [-Wmaybe-uninitialized] __dynamic_dev_dbg(&descriptor, dev, fmt, \ ^ drivers/power/bq24190_charger.c:1211:13: note: ‘f_reg’ was declared here u8 ss_reg, f_reg; Signed-off-by: Lad, Prabhakar Signed-off-by: Sebastian Reichel Signed-off-by: Jiri Slaby commit 86d16222fd8ee0c1f7d9ff74ced8eb03b1915509 Author: David S. Miller Date: Fri Apr 17 15:15:40 2015 -0400 sfc: Fix memcpy() with const destination compiler warning. commit 1d20a16062e771b6e26b843c0cde3b17c1146e00 upstream. drivers/net/ethernet/sfc/selftest.c: In function ‘efx_iterate_state’: drivers/net/ethernet/sfc/selftest.c:388:9: warning: passing argument 1 of ‘memcpy’ discards ‘const’ qualifier from pointer target type [-Wdiscarded-array-qualifiers] This is because the msg[] member of struct efx_loopback_payload is marked as 'const'. Remove that. Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit ef1a1f76f66aeadbf151b60d35f6e63109dd98f2 Author: Jan Kara Date: Thu Oct 22 13:32:21 2015 -0700 mm: make sendfile(2) killable commit 296291cdd1629c308114504b850dc343eabc2782 upstream. Currently a simple program below issues a sendfile(2) system call which takes about 62 days to complete in my test KVM instance. int fd; off_t off = 0; fd = open("file", O_RDWR | O_TRUNC | O_SYNC | O_CREAT, 0644); ftruncate(fd, 2); lseek(fd, 0, SEEK_END); sendfile(fd, fd, &off, 0xfffffff); Now you should not ask kernel to do a stupid stuff like copying 256MB in 2-byte chunks and call fsync(2) after each chunk but if you do, sysadmin should have a way to stop you. We actually do have a check for fatal_signal_pending() in generic_perform_write() which triggers in this path however because we always succeed in writing something before the check is done, we return value > 0 from generic_perform_write() and thus the information about signal gets lost. Fix the problem by doing the signal check before writing anything. That way generic_perform_write() returns -EINTR, the error gets propagated up and the sendfile loop terminates early. Signed-off-by: Jan Kara Reported-by: Dmitry Vyukov Cc: Al Viro