commit 9fbe8b46fa4bb64f8f4f1abcb03d03e92de2aafb Author: Greg Kroah-Hartman Date: Tue Dec 16 09:37:26 2014 -0800 Linux 3.17.7 commit 37ae58a932ac9c767e677ff1dbde8cfb4939aef8 Author: Takashi Iwai Date: Sat Dec 6 18:02:55 2014 +0100 ALSA: usb-audio: Don't resubmit pending URBs at MIDI error recovery commit 66139a48cee1530c91f37c145384b4ee7043f0b7 upstream. In snd_usbmidi_error_timer(), the driver tries to resubmit MIDI input URBs to reactivate the MIDI stream, but this causes the error when some of URBs are still pending like: WARNING: CPU: 0 PID: 0 at ../drivers/usb/core/urb.c:339 usb_submit_urb+0x5f/0x70() URB ef705c40 submitted while active CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.16.6-2-desktop #1 Hardware name: FOXCONN TPS01/TPS01, BIOS 080015 03/23/2010 c0984bfa f4009ed4 c078deaf f4009ee4 c024c884 c09a135c f4009f00 00000000 c0984bfa 00000153 c061ac4f c061ac4f 00000009 00000001 ef705c40 e854d1c0 f4009eec c024c8d3 00000009 f4009ee4 c09a135c f4009f00 f4009f04 c061ac4f Call Trace: [] try_stack_unwind+0x156/0x170 [] dump_trace+0x5a/0x1b0 [] show_trace_log_lvl+0x46/0x50 [] show_stack_log_lvl+0x51/0xe0 [] show_stack+0x27/0x50 [] dump_stack+0x45/0x65 [] warn_slowpath_common+0x84/0xa0 [] warn_slowpath_fmt+0x33/0x40 [] usb_submit_urb+0x5f/0x70 [] snd_usbmidi_submit_urb+0x14/0x60 [snd_usbmidi_lib] [] snd_usbmidi_error_timer+0x6a/0xa0 [snd_usbmidi_lib] [] call_timer_fn+0x30/0x130 [] run_timer_softirq+0x1c2/0x260 [] __do_softirq+0xc3/0x270 [] do_softirq_own_stack+0x22/0x30 [] irq_exit+0x8d/0xa0 [] smp_apic_timer_interrupt+0x38/0x50 [] apic_timer_interrupt+0x34/0x3c [] cpuidle_enter_state+0x3e/0xd0 [] cpu_idle_loop+0x29d/0x3e0 [] cpu_startup_entry+0x53/0x60 [] start_kernel+0x415/0x41a For avoiding these errors, check the pending URBs and skip resubmitting such ones. Reported-and-tested-by: Stefan Seyfried Acked-by: Clemens Ladisch Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit dba8c7756c8978e9242baed43697a998fe7af83a Author: Takashi Iwai Date: Thu Nov 13 07:11:38 2014 +0100 ALSA: hda - Fix built-in mic at resume on Lenovo Ideapad S210 commit fedb2245cbb8d823e449ebdd48ba9bb35c071ce0 upstream. The built-in mic boost volume gets almost muted after suspend/resume on Lenovo Ideapad S210. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=88121 Reported-and-tested-by: Roman Kagan Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit bf56a7af898c8649419957e3e0f3c49810bcff2d Author: Takashi Iwai Date: Tue Dec 9 19:58:53 2014 +0100 ALSA: hda - Add EAPD fixup for ASUS Z99He laptop commit f62f5eff3d40a56ad1cf0d81a6cac8dd8743e8a1 upstream. The same fixup to enable EAPD is needed for ASUS Z99He with AD1986A codec like another ASUS machine. Reported-and-tested-by: Dmitry V. Zimin Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit a3e97a494e017670a29973f2c610ff68897beca4 Author: Christian König Date: Thu Nov 27 13:12:58 2014 +0100 drm/radeon: sync all BOs involved in a CS v2 commit 86b276385c6a986872e4cd144f5940b156053c3f upstream. Not just the userspace relocs, otherwise we won't wait for a swapped out page tables to be swapped in again. v2: rebased on Alex current drm-fixes-3.18 Signed-off-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 1c9e23ba8ed175ebe9a48366a276bc3ac493506c Author: Greg Kroah-Hartman Date: Sun Dec 14 12:04:52 2014 -0800 Revert: ACPI / EC: Add support to disallow QR_EC to be issued before completing previous QR_EC This reverts commit 2dbfff81a40b5b2be553042ad5c767e34fdd214c, which really is commit 558e4736f2e1b0e6323adf7a5e4df77ed6cfc1a4 upstream. Sorry for the confusion, this got applied twice, and reverted once, this is the second revert and I hope to never touch it again... Reported-by: Lv Zheng Cc: Alexander Mezin Cc: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit ed6e7e6db07dd54ff420c5de6552c5123ac78902 Author: Daniel Borkmann Date: Wed Dec 10 16:33:10 2014 +0100 netlink: use jhash as hashfn for rhashtable [ Upstream commit 7f19fc5e0b617593dcda0d9956adc78b559ef1f5 ] For netlink, we shouldn't be using arch_fast_hash() as a hashing discipline, but rather jhash() instead. Since netlink sockets can be opened by any user, a local attacker would be able to easily create collisions with the DPDK-derived arch_fast_hash(), which trades off performance for security by using crc32 CPU instructions on x86_64. While it might have a legimite use case in other places, it should be avoided in netlink context, though. As rhashtable's API is very flexible, we could later on still decide on other hashing disciplines, if legitimate. Reference: http://thread.gmane.org/gmane.linux.kernel/1844123 Fixes: e341694e3eb5 ("netlink: Convert netlink_lookup() to use RCU protected hash table") Cc: Herbert Xu Signed-off-by: Daniel Borkmann Acked-by: Thomas Graf Acked-by: Hannes Frederic Sowa Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit f37f698e00694a1b30d2cee574003a2ce803c5de Author: David Vrabel Date: Tue Dec 9 18:43:28 2014 +0000 xen-netfront: use correct linear area after linearizing an skb [ Upstream commit 11d3d2a16cc1f05c6ece69a4392e99efb85666a6 ] Commit 97a6d1bb2b658ac85ed88205ccd1ab809899884d (xen-netfront: Fix handling packets on compound pages with skb_linearize) attempted to fix a problem where an skb that would have required too many slots would be dropped causing TCP connections to stall. However, it filled in the first slot using the original buffer and not the new one and would use the wrong offset and grant access to the wrong page. Netback would notice the malformed request and stop all traffic on the VIF, reporting: vif vif-3-0 vif3.0: txreq.offset: 85e, size: 4002, end: 6144 vif vif-3-0 vif3.0: fatal error; disabling device Reported-by: Anthony Wright Tested-by: Anthony Wright Signed-off-by: David Vrabel Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 4c60f294000b7c7e617c7f08ad04fd104cc6fbaf Author: Daniel Borkmann Date: Wed Dec 3 12:13:58 2014 +0100 net: sctp: use MAX_HEADER for headroom reserve in output path [ Upstream commit 9772b54c55266ce80c639a80aa68eeb908f8ecf5 ] To accomodate for enough headroom for tunnels, use MAX_HEADER instead of LL_MAX_HEADER. Robert reported that he has hit after roughly 40hrs of trinity an skb_under_panic() via SCTP output path (see reference). I couldn't reproduce it from here, but not using MAX_HEADER as elsewhere in other protocols might be one possible cause for this. In any case, it looks like accounting on chunks themself seems to look good as the skb already passed the SCTP output path and did not hit any skb_over_panic(). Given tunneling was enabled in his .config, the headroom would have been expanded by MAX_HEADER in this case. Reported-by: Robert Święcki Reference: https://lkml.org/lkml/2014/12/1/507 Fixes: 594ccc14dfe4d ("[SCTP] Replace incorrect use of dev_alloc_skb with alloc_skb in sctp_packet_transmit().") Signed-off-by: Daniel Borkmann Acked-by: Vlad Yasevich Acked-by: Neil Horman Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 14de991db18a160a5a67a3cbd14cc71a53a40784 Author: Eric Dumazet Date: Tue Dec 2 04:30:59 2014 -0800 net: mvneta: fix race condition in mvneta_tx() [ Upstream commit 5f478b41033606d325e420df693162e2524c2b94 ] mvneta_tx() dereferences skb to get skb->len too late, as hardware might have completed the transmit and TX completion could have freed the skb from another cpu. Fixes: 71f6d1b31fb1 ("net: mvneta: replace Tx timer with a real interrupt") Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit f7bf1abd2eae146f72a7e66ccb0e82e358ba552a Author: willy tarreau Date: Tue Dec 2 08:13:04 2014 +0100 net: mvneta: fix Tx interrupt delay [ Upstream commit aebea2ba0f7495e1a1c9ea5e753d146cb2f6b845 ] The mvneta driver sets the amount of Tx coalesce packets to 16 by default. Normally that does not cause any trouble since the driver uses a much larger Tx ring size (532 packets). But some sockets might run with very small buffers, much smaller than the equivalent of 16 packets. This is what ping is doing for example, by setting SNDBUF to 324 bytes rounded up to 2kB by the kernel. The problem is that there is no documented method to force a specific packet to emit an interrupt (eg: the last of the ring) nor is it possible to make the NIC emit an interrupt after a given delay. In this case, it causes trouble, because when ping sends packets over its raw socket, the few first packets leave the system, and the first 15 packets will be emitted without an IRQ being generated, so without the skbs being freed. And since the socket's buffer is small, there's no way to reach that amount of packets, and the ping ends up with "send: no buffer available" after sending 6 packets. Running with 3 instances of ping in parallel is enough to hide the problem, because with 6 packets per instance, that's 18 packets total, which is enough to grant a Tx interrupt before all are sent. The original driver in the LSP kernel worked around this design flaw by using a software timer to clean up the Tx descriptors. This timer was slow and caused terrible network performance on some Tx-bound workloads (such as routing) but was enough to make tools like ping work correctly. Instead here, we simply set the packet counts before interrupt to 1. This ensures that each packet sent will produce an interrupt. NAPI takes care of coalescing interrupts since the interrupt is disabled once generated. No measurable performance impact nor CPU usage were observed on small nor large packets, including when saturating the link on Tx, and this fixes tools like ping which rely on too small a send buffer. If one wants to increase this value for certain workloads where it is safe to do so, "ethtool -C $dev tx-frames" will override this default setting. This fix needs to be applied to stable kernels starting with 3.10. Tested-By: Maggie Mae Roxas Signed-off-by: Willy Tarreau Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 65f158039c9b916f677d26c76bbd64beffd0b1ee Author: Denis Kirjanov Date: Mon Dec 1 12:57:02 2014 +0300 mips: bpf: Fix broken BPF_MOD [ Upstream commit 2e46477a12f6fd273e31a220b155d66e8352198c ] Remove optimize_div() from BPF_MOD | BPF_K case since we don't know the dividend and fix the emit_mod() by reading the mod operation result from HI register Signed-off-by: Denis Kirjanov Reviewed-by: Markos Chandras Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 5f4cfd32b21e509325111e72b27aff2e273f11f8 Author: Tom Herbert Date: Sat Nov 29 09:59:45 2014 -0800 gre: Set inner mac header in gro complete [ Upstream commit 6fb2a756739aa507c1fd5b8126f0bfc2f070dc46 ] Set the inner mac header to point to the GRE payload when doing GRO. This is needed if we proceed to send the packet through GRE GSO which now uses the inner mac header instead of inner network header to determine the length of encapsulation headers. Fixes: 14051f0452a2 ("gre: Use inner mac length when computing tunnel length") Reported-by: Wolfgang Walter Signed-off-by: Tom Herbert Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 3e66aad18b516bd6c2b317cd8f01537ae59aa957 Author: Nicolas Dichtel Date: Thu Nov 27 10:16:15 2014 +0100 rtnetlink: release net refcnt on error in do_setlink() [ Upstream commit e0ebde0e131b529fd721b24f62872def5ec3718c ] rtnl_link_get_net() holds a reference on the 'struct net', we need to release it in case of error. CC: Eric W. Biederman Fixes: b51642f6d77b ("net: Enable a userns root rtnl calls that are safe for unprivilged users") Signed-off-by: Nicolas Dichtel Reviewed-by: "Eric W. Biederman" Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 54e673fc73b6008bc3569d63e92903ef11675e24 Author: Thomas Graf Date: Thu Nov 27 00:22:33 2014 +0100 bond: Check length of IFLA_BOND_ARP_IP_TARGET attributes [ Upstream commit f6c6fda4c9e17940b0a2ba206b0408babfdc930c ] Fixes: 7f28fa10 ("bonding: add arp_ip_target netlink support") Reported-by: John Fastabend Cc: Scott Feldman Signed-off-by: Thomas Graf Acked-by: John Fastabend Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 433337f9c00cac447d020922f59237273f5d92be Author: Willem de Bruijn Date: Wed Nov 26 14:53:02 2014 -0500 net-timestamp: make tcp_recvmsg call ipv6_recv_error for AF_INET6 socks [ Upstream commit f4713a3dfad045d46afcb9c2a7d0bba288920ed4 ] TCP timestamping introduced MSG_ERRQUEUE handling for TCP sockets. If the socket is of family AF_INET6, call ipv6_recv_error instead of ip_recv_error. This change is more complex than a single branch due to the loadable ipv6 module. It reuses a pre-existing indirect function call from ping. The ping code is safe to call, because it is part of the core ipv6 module and always present when AF_INET6 sockets are active. Fixes: 4ed2d765 (net-timestamp: TCP timestamping) Signed-off-by: Willem de Bruijn ---- It may also be worthwhile to add WARN_ON_ONCE(sk->family == AF_INET6) to ip_recv_error. Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 79fa8e2338280f1f7954d25ce5b5791b3472bcfa Author: Jack Morgenstein Date: Tue Nov 25 11:54:31 2014 +0200 net/mlx4_core: Limit count field to 24 bits in qp_alloc_res [ Upstream commit 2d5c57d7fbfaa642fb7f0673df24f32b83d9066c ] Some VF drivers use the upper byte of "param1" (the qp count field) in mlx4_qp_reserve_range() to pass flags which are used to optimize the range allocation. Under the current code, if any of these flags are set, the 32-bit count field yields a count greater than 2^24, which is out of range, and this VF fails. As these flags represent a "best-effort" allocation hint anyway, they may safely be ignored. Therefore, the PF driver may simply mask out the bits. Fixes: c82e9aa0a8 "mlx4_core: resource tracking for HCA resources used by guests" Signed-off-by: Jack Morgenstein Signed-off-by: Or Gerlitz Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 600ce1de64e617a14055d1848afcfc9719d070ed Author: Thadeu Lima de Souza Cascardo Date: Tue Nov 25 14:21:11 2014 -0200 tg3: fix ring init when there are more TX than RX channels [ Upstream commit a620a6bc1c94c22d6c312892be1e0ae171523125 ] If TX channels are set to 4 and RX channels are set to less than 4, using ethtool -L, the driver will try to initialize more RX channels than it has allocated, causing an oops. This fix only initializes the RX ring if it has been allocated. Signed-off-by: Thadeu Lima de Souza Cascardo Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 077465adaffd3558a42717c178332be9ecbf9510 Author: Marcelo Leitner Date: Thu Dec 11 10:02:22 2014 -0200 Fix race condition between vxlan_sock_add and vxlan_sock_release [ Upstream commit 00c83b01d58068dfeb2e1351cca6fccf2a83fa8f ] Currently, when trying to reuse a socket, vxlan_sock_add will grab vn->sock_lock, locate a reusable socket, inc refcount and release vn->sock_lock. But vxlan_sock_release() will first decrement refcount, and then grab that lock. refcnt operations are atomic but as currently we have deferred works which hold vs->refcnt each, this might happen, leading to a use after free (specially after vxlan_igmp_leave): CPU 1 CPU 2 deferred work vxlan_sock_add ... ... spin_lock(&vn->sock_lock) vs = vxlan_find_sock(); vxlan_sock_release dec vs->refcnt, reaches 0 spin_lock(&vn->sock_lock) vxlan_sock_hold(vs), refcnt=1 spin_unlock(&vn->sock_lock) hlist_del_rcu(&vs->hlist); vxlan_notify_del_rx_port(vs) spin_unlock(&vn->sock_lock) So when we look for a reusable socket, we check if it wasn't freed already before reusing it. Signed-off-by: Marcelo Ricardo Leitner Fixes: 7c47cedf43a8b3 ("vxlan: move IGMP join/leave to work queue") Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 53aa04efe5f299cecbcf307937a3b2069fcfb0a3 Author: Alexander Duyck Date: Mon Nov 24 20:08:38 2014 -0800 vxlan: Fix boolean flip in VXLAN_F_UDP_ZERO_CSUM6_[TX|RX] [ Upstream commit 3dc2b6a8d38cf6c7604ec25f3d50d6ec8da04435 ] In "vxlan: Call udp_sock_create" there was a logic error that resulted in the default for IPv6 VXLAN tunnels going from using checksums to not using checksums. Since there is currently no support in iproute2 for setting these values it means that a kernel after the change cannot talk over a IPv6 VXLAN tunnel to a kernel prior the change. Fixes: 3ee64f3 ("vxlan: Call udp_sock_create") Cc: Tom Herbert Signed-off-by: Alexander Duyck Acked-by: Tom Herbert Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 360450bac21a9b9052fb4bef2f348b7c07ea91ac Author: Yuri Chislov Date: Mon Nov 24 11:25:15 2014 +0100 ipv6: gre: fix wrong skb->protocol in WCCP [ Upstream commit be6572fdb1bfbe23b2624d477de50af50b02f5d6 ] When using GRE redirection in WCCP, it sets the wrong skb->protocol, that is, ETH_P_IP instead of ETH_P_IPV6 for the encapuslated traffic. Fixes: c12b395a4664 ("gre: Support GRE over IPv6") Cc: Dmitry Kozlov Signed-off-by: Yuri Chislov Tested-by: Yuri Chislov Signed-off-by: Daniel Borkmann Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 63eddb92d0f61d404a2681e4ea39887315eb02d8 Author: lucien Date: Sun Nov 23 15:04:11 2014 +0800 ip_tunnel: the lack of vti_link_ops' dellink() cause kernel panic [ Upstream commit 20ea60ca9952bd19d4b0d74719daba305aef5178 ] Now the vti_link_ops do not point the .dellink, for fb tunnel device (ip_vti0), the net_device will be removed as the default .dellink is unregister_netdevice_queue,but the tunnel still in the tunnel list, then if we add a new vti tunnel, in ip_tunnel_find(): hlist_for_each_entry_rcu(t, head, hash_node) { if (local == t->parms.iph.saddr && remote == t->parms.iph.daddr && link == t->parms.link && ==> type == t->dev->type && ip_tunnel_key_match(&t->parms, flags, key)) break; } the panic will happen, cause dev of ip_tunnel *t is null: [ 3835.072977] IP: [] ip_tunnel_find+0x9d/0xc0 [ip_tunnel] [ 3835.073008] PGD b2c21067 PUD b7277067 PMD 0 [ 3835.073008] Oops: 0000 [#1] SMP ..... [ 3835.073008] Stack: [ 3835.073008] ffff8800b72d77f0 ffffffffa0411924 ffff8800bb956000 ffff8800b72d78e0 [ 3835.073008] ffff8800b72d78a0 0000000000000000 ffffffffa040d100 ffff8800b72d7858 [ 3835.073008] ffffffffa040b2e3 0000000000000000 0000000000000000 0000000000000000 [ 3835.073008] Call Trace: [ 3835.073008] [] ip_tunnel_newlink+0x64/0x160 [ip_tunnel] [ 3835.073008] [] vti_newlink+0x43/0x70 [ip_vti] [ 3835.073008] [] rtnl_newlink+0x4fa/0x5f0 [ 3835.073008] [] ? nla_strlcpy+0x5b/0x70 [ 3835.073008] [] ? rtnl_link_ops_get+0x40/0x60 [ 3835.073008] [] ? rtnl_newlink+0x13f/0x5f0 [ 3835.073008] [] rtnetlink_rcv_msg+0xa4/0x270 [ 3835.073008] [] ? sock_has_perm+0x75/0x90 [ 3835.073008] [] ? rtnetlink_rcv+0x30/0x30 [ 3835.073008] [] netlink_rcv_skb+0xa9/0xc0 [ 3835.073008] [] rtnetlink_rcv+0x28/0x30 .... modprobe ip_vti ip link del ip_vti0 type vti ip link add ip_vti0 type vti rmmod ip_vti do that one or more times, kernel will panic. fix it by assigning ip_tunnel_dellink to vti_link_ops' dellink, in which we skip the unregister of fb tunnel device. do the same on ip6_vti. Signed-off-by: Xin Long Signed-off-by: Cong Wang Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 7a47f5fcb211100744fbd168b5b0c613c66b3cef Author: Dmitry Torokhov Date: Fri Nov 14 13:39:05 2014 -0800 sata_fsl: fix error handling of irq_of_parse_and_map commit aad0b624129709c94c2e19e583b6053520353fa8 upstream. irq_of_parse_and_map() returns 0 on error (the result is unsigned int), so testing for negative result never works. Signed-off-by: Dmitry Torokhov Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit 1b3146151e7ab12043975c3f620a3ad3b45b4fad Author: Tejun Heo Date: Thu Dec 4 13:13:28 2014 -0500 ahci: disable MSI on SAMSUNG 0xa800 SSD commit 2b21ef0aae65f22f5ba86b13c4588f6f0c2dbefb upstream. Just like 0x1600 which got blacklisted by 66a7cbc303f4 ("ahci: disable MSI instead of NCQ on Samsung pci-e SSDs on macbooks"), 0xa800 chokes on NCQ commands if MSI is enabled. Disable MSI. Signed-off-by: Tejun Heo Reported-by: Dominik Mierzejewski Link: https://bugzilla.kernel.org/show_bug.cgi?id=89171 Signed-off-by: Greg Kroah-Hartman commit d15b99217b63e8d2eda3f10d3df7339b282efc71 Author: Devin Ryles Date: Fri Nov 7 17:59:05 2014 -0500 AHCI: Add DeviceIDs for Sunrise Point-LP SATA controller commit 249cd0a187ed4ef1d0af7f74362cc2791ec5581b upstream. This patch adds DeviceIDs for Sunrise Point-LP. Signed-off-by: Devin Ryles Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit 6d6a8c0b7e25f934d19da71d14084aa851e76ec6 Author: Sakari Ailus Date: Thu Nov 6 17:49:45 2014 -0300 media: smiapp: Only some selection targets are settable commit b31eb901c4e5eeef4c83c43dfbc7fe0d4348cb21 upstream. Setting a non-settable selection target caused BUG() to be called. The check for valid selections only takes the selection target into account, but does not tell whether it may be set, or only get. Fix the issue by simply returning an error to the user. Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit ce7c82e8f8616f03120f8bed8e4f344b69fa6a47 Author: sensoray-dev Date: Mon Nov 17 19:50:36 2014 -0300 media: s2255drv: fix payload size for JPG, MJPEG commit 1f391217ad8d7cd7b1e48e6e2abf49970cd91d18 upstream. length is the size of the buffer, not the payload. That's set using vb2_set_plane_payload(). Signed-off-by: Dean Anderson Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 26366e61455f21778408b57901e7778dc45cddde Author: David Härdeman Date: Thu Nov 20 18:09:54 2014 -0300 media: rc-core: fix toggle handling in the rc6 decoder commit d2a74581390d8e5ed09b12c9d4736847d918dfa6 upstream. The toggle bit shouldn't be cleared before the toggle value is calculated. This should probably go into 3.17.x as well. Fixes: 120703f9eb32 ([media] rc-core: document the protocol type) Tested-by: Stephan Raue Signed-off-by: David Härdeman Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit adac476a1983459b0351903430c2f45e8d542570 Author: Chris Clayton Date: Sat Nov 22 09:51:10 2014 +0000 x86: Use $(OBJDUMP) instead of plain objdump commit e2e68ae688b0a3766cd75aedf4ed4e39be402009 upstream. commit e6023367d779 'x86, kaslr: Prevent .bss from overlaping initrd' broke the cross compile of x86. It added a objdump invocation, which invokes the host native objdump and ignores an active cross tool chain. Use $(OBJDUMP) instead which takes the CROSS_COMPILE prefix into account. [ tglx: Massage changelog and use $(OBJDUMP) ] Fixes: e6023367d779 'x86, kaslr: Prevent .bss from overlaping initrd' Signed-off-by: Chris Clayton Acked-by: Kees Cook Acked-by: Borislav Petkov Cc: Junjie Mao Cc: Ingo Molnar Cc: H. Peter Anvin Link: http://lkml.kernel.org/r/54705C8E.1080400@googlemail.com Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit fb978c5b11b234a54076c3c465e7a407e9de5a52 Author: Daniel Vetter Date: Mon Dec 1 17:56:54 2014 +0100 drm/i915: Unlock panel even when LVDS is disabled commit b0616c5306b342ceca07044dbc4f917d95c4f825 upstream. Otherwise we'll have backtraces in assert_panel_unlocked because the BIOS locks the register. In the reporter's case this regression was introduced in commit c31407a3672aaebb4acddf90944a114fa5c8af7b Author: Chris Wilson Date: Thu Oct 18 21:07:01 2012 +0100 drm/i915: Add no-lvds quirk for Supermicro X7SPA-H Reported-by: Alexey Orishko Cc: Alexey Orishko Cc: Chris Wilson Cc: Francois Tigeot Signed-off-by: Daniel Vetter Tested-by: Alexey Orishko Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit f9fff2487c58743ebbefe5e4a455e7d839f863ea Author: Daniel Vetter Date: Mon Nov 24 17:02:45 2014 +0100 drm/i915: More cautious with pch fifo underruns commit b68362278af94e1171f5be9d4e44988601fb0439 upstream. Apparently PCH fifo underruns are tricky, we have plenty reports that we see the occasional underrun (especially at boot-up). So for a change let's see what happens when we don't re-enable pch fifo underrun reporting when the pipe is disabled. This means that the kernel can't catch pch fifo underruns when they happen (except when all pipes are on on the pch). But we'll still catch underruns when disabling the pipe again. So not a terrible reduction in test coverage. Since the DRM_ERROR is new and hence a regression plan B would be to revert it back to a debug output. Which would be a lot worse than this hack for underrun test coverage in the wild. See the referenced discussions for more. References: http://mid.gmane.org/CA+gsUGRfGe3t4NcjdeA=qXysrhLY3r4CEu7z4bjTwxi1uOfy+g@mail.gmail.com Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85898 References: https://bugs.freedesktop.org/show_bug.cgi?id=85898 References: https://bugs.freedesktop.org/show_bug.cgi?id=86233 References: https://bugs.freedesktop.org/show_bug.cgi?id=86478 Signed-off-by: Daniel Vetter Tested-by: lu hua Reviewed-by: Paulo Zanoni Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit bb4be8b28092bd32120c7ffc1f1a8295262cbb74 Author: Ian Campbell Date: Tue Nov 25 15:05:13 2014 +0000 of/fdt: memblock_reserve /memreserve/ regions in the case of partial overlap commit 094cb98179f19b75acf9ff471daabf3948ce98e6 upstream. memblock_is_region_reserved() returns true in the case of a partial overlap, meaning that the current code fails to reserve the non-overlapping portion. This call was introduced as part of d1552ce449eb "of/fdt: move memreserve and dtb memory reservations into core" which went into v3.16. I observed this causing a Midway system with a buggy fdt (the header declares itself to be larger than it really is) failing to boot because the over-inflated size of the fdt was causing it to seem to run into the swapper_pg_dir region, meaning the DT wasn't reserved. The symptoms were failing to find an disks or network and failing to boot. However given the ambiguity of whether things like the initrd are covered by /memreserve/ and similar I think it is best to also register the region rather than just ignoring it. Since memblock_reserve() handles overlaps just fine lets just warn and carry on. Signed-off-by: Ian Campbell Signed-off-by: Grant Likely Cc: Rob Herring Signed-off-by: Greg Kroah-Hartman commit 81bbfbf106ba1121bf2d06853b95719487693edd Author: Petr Mladek Date: Thu Nov 27 16:57:21 2014 +0100 drm/radeon: kernel panic in drm_calc_vbltimestamp_from_scanoutpos with 3.18.0-rc6 commit f5475cc43c899e33098d4db44b7c5e710f16589d upstream. I was unable too boot 3.18.0-rc6 because of the following kernel panic in drm_calc_vbltimestamp_from_scanoutpos(): [drm] Initialized drm 1.1.0 20060810 [drm] radeon kernel modesetting enabled. [drm] initializing kernel modesetting (RV100 0x1002:0x515E 0x15D9:0x8080). [drm] register mmio base: 0xC8400000 [drm] register mmio size: 65536 radeon 0000:0b:01.0: VRAM: 128M 0x00000000D0000000 - 0x00000000D7FFFFFF (16M used) radeon 0000:0b:01.0: GTT: 512M 0x00000000B0000000 - 0x00000000CFFFFFFF [drm] Detected VRAM RAM=128M, BAR=128M [drm] RAM width 16bits DDR [TTM] Zone kernel: Available graphics memory: 3829346 kiB [TTM] Zone dma32: Available graphics memory: 2097152 kiB [TTM] Initializing pool allocator [TTM] Initializing DMA pool allocator [drm] radeon: 16M of VRAM memory ready [drm] radeon: 512M of GTT memory ready. [drm] GART: num cpu pages 131072, num gpu pages 131072 [drm] PCI GART of 512M enabled (table at 0x0000000037880000). radeon 0000:0b:01.0: WB disabled radeon 0000:0b:01.0: fence driver on ring 0 use gpu addr 0x00000000b0000000 and cpu addr 0xffff8800bbbfa000 [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [drm] Driver supports precise vblank timestamp query. [drm] radeon: irq initialized. [drm] Loading R100 Microcode radeon 0000:0b:01.0: Direct firmware load for radeon/R100_cp.bin failed with error -2 radeon_cp: Failed to load firmware "radeon/R100_cp.bin" [drm:r100_cp_init] *ERROR* Failed to load firmware! radeon 0000:0b:01.0: failed initializing CP (-2). radeon 0000:0b:01.0: Disabling GPU acceleration [drm] radeon: cp finalized BUG: unable to handle kernel NULL pointer dereference at 000000000000025c IP: [] drm_calc_vbltimestamp_from_scanoutpos+0x4b/0x320 PGD 0 Oops: 0000 [#1] SMP Modules linked in: CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.18.0-rc6-4-default #2649 Hardware name: Supermicro X7DB8/X7DB8, BIOS 6.00 07/26/2006 task: ffff880234da2010 ti: ffff880234da4000 task.ti: ffff880234da4000 RIP: 0010:[] [] drm_calc_vbltimestamp_from_scanoutpos+0x4b/0x320 RSP: 0000:ffff880234da7918 EFLAGS: 00010086 RAX: ffffffff81557890 RBX: 0000000000000000 RCX: ffff880234da7a48 RDX: ffff880234da79f4 RSI: 0000000000000000 RDI: ffff880232e15000 RBP: ffff880234da79b8 R08: 0000000000000000 R09: 0000000000000000 R10: 000000000000000a R11: 0000000000000001 R12: ffff880232dda1c0 R13: ffff880232e1518c R14: 0000000000000292 R15: ffff880232e15000 FS: 0000000000000000(0000) GS:ffff88023fc40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 000000000000025c CR3: 0000000002014000 CR4: 00000000000007e0 Stack: ffff880234da79d8 0000000000000286 ffff880232dcbc00 0000000000002480 ffff880234da7958 0000000000000296 ffff880234da7998 ffffffff8151b51d ffff880234da7a48 0000000032dcbeb0 ffff880232dcbc00 ffff880232dcbc58 Call Trace: [] ? drm_vma_offset_remove+0x1d/0x110 [] radeon_get_vblank_timestamp_kms+0x38/0x60 [] ? ttm_bo_release_list+0xba/0x180 [] drm_get_last_vbltimestamp+0x41/0x70 [] vblank_disable_and_save+0x73/0x1d0 [] ? try_to_del_timer_sync+0x4f/0x70 [] drm_vblank_cleanup+0x65/0xa0 [] radeon_irq_kms_fini+0x1a/0x70 [] r100_init+0x26e/0x410 [] radeon_device_init+0x7ae/0xb50 [] radeon_driver_load_kms+0x8f/0x210 [] drm_dev_register+0xb5/0x110 [] drm_get_pci_dev+0x8f/0x200 [] radeon_pci_probe+0xad/0xe0 [] local_pci_probe+0x45/0xa0 [] pci_device_probe+0xd1/0x130 [] driver_probe_device+0x12d/0x3e0 [] __driver_attach+0x9b/0xa0 [] ? __device_attach+0x40/0x40 [] bus_for_each_dev+0x63/0xa0 [] driver_attach+0x1e/0x20 [] bus_add_driver+0x180/0x240 [] driver_register+0x64/0xf0 [] __pci_register_driver+0x4c/0x50 [] drm_pci_init+0xf5/0x120 [] ? ttm_init+0x6a/0x6a [] radeon_init+0x97/0xb5 [] do_one_initcall+0xbc/0x1f0 [] ? __wake_up+0x48/0x60 [] kernel_init_freeable+0x18a/0x215 [] ? initcall_blacklist+0xc0/0xc0 [] ? rest_init+0x80/0x80 [] kernel_init+0xe/0xf0 [] ret_from_fork+0x7c/0xb0 [] ? rest_init+0x80/0x80 Code: 45 ac 0f 88 a8 01 00 00 3b b7 d0 01 00 00 49 89 ff 0f 83 99 01 00 00 48 8b 47 20 48 8b 80 88 00 00 00 48 85 c0 0f 84 cd 01 00 00 <41> 8b b1 5c 02 00 00 41 8b 89 58 02 00 00 89 75 98 41 8b b1 60 RIP [] drm_calc_vbltimestamp_from_scanoutpos+0x4b/0x320 RSP CR2: 000000000000025c ---[ end trace ad2c0aadf48e2032 ]--- Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009 It has helped me to add a NULL pointer check that was suggested at http://lists.freedesktop.org/archives/dri-devel/2014-October/070663.html I am not familiar with the code. But the change looks sane and we need something fast at this stage of 3.18 development. Suggested-by: Helge Deller Signed-off-by: Petr Mladek Tested-by: Petr Mladek Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 3555e19377e6b9a4cb75863273ba92b9dfcf8331 Author: Michel Dänzer Date: Thu Nov 27 18:00:54 2014 +0900 drm/radeon: Ignore RADEON_GEM_GTT_WC on 32-bit x86 commit a08b588e4199e4200d26027ffcdf3ab2fa906412 upstream. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84627 Signed-off-by: Michel Dänzer Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 294db70c579c2880d0ceb7a3938b6853aaf62ccb Author: Vishnu Motghare Date: Wed Dec 3 18:05:25 2014 +0530 i2c: cadence: Set the hardware time-out register to maximum value commit 681d15a0f527af7ab3a783e1037de86fbcb136ac upstream. Cadence I2C controller has bug wherein it generates invalid read transactions after timeout in master receiver mode. This driver does not use the HW timeout and this interrupt is disabled but the feature itself cannot be disabled. Hence, this patch writes the maximum value (0xFF) to this register. This is one of the workarounds to this bug and it will not avoid the issue completely but reduces the chances of error. Signed-off-by: Vishnu Motghare Signed-off-by: Harini Katakam Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit 0425de567c34b001929bdcef58b40ed76db71bd5 Author: Grygorii Strashko Date: Mon Dec 1 17:34:04 2014 +0200 i2c: davinci: generate STP always when NACK is received commit 9ea359f7314132cbcb5a502d2d8ef095be1f45e4 upstream. According to I2C specification the NACK should be handled as follows: "When SDA remains HIGH during this ninth clock pulse, this is defined as the Not Acknowledge signal. The master can then generate either a STOP condition to abort the transfer, or a repeated START condition to start a new transfer." [I2C spec Rev. 6, 3.1.6: http://www.nxp.com/documents/user_manual/UM10204.pdf] Currently the Davinci i2c driver interrupts the transfer on receipt of a NACK but fails to send a STOP in some situations and so makes the bus stuck until next I2C IP reset (idle/enable). For example, the issue will happen during SMBus read transfer which consists from two i2c messages write command/address and read data: S Slave Address Wr A Command Code A Sr Slave Address Rd A D1..Dn A P <--- write -----------------------> <--- read ---------------------> The I2C client device will send NACK if it can't recognize "Command Code" and it's expected from I2C master to generate STP in this case. But now, Davinci i2C driver will just exit with -EREMOTEIO and STP will not be generated. Hence, fix it by generating Stop condition (STP) always when NACK is received. This patch fixes Davinci I2C in the same way it was done for OMAP I2C commit cda2109a26eb ("i2c: omap: query STP always when NACK is received"). Reviewed-by: Uwe Kleine-König Reported-by: Hein Tibosch Signed-off-by: Grygorii Strashko Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit 16afa3f551a397046f9d323cf2b69867e081fb1a Author: Alexander Kochetkov Date: Fri Nov 21 04:16:51 2014 +0400 i2c: omap: fix i207 errata handling commit ccfc866356674cb3a61829d239c685af6e85f197 upstream. commit 6d9939f651419a63e091105663821f9c7d3fec37 (i2c: omap: split out [XR]DR and [XR]RDY) changed the way how errata i207 (I2C: RDR Flag May Be Incorrectly Set) get handled. 6d9939f6514 code doesn't correspond to workaround provided by errata. According to errata ISR must filter out spurious RDR before data read not after. ISR must read RXSTAT to get number of bytes available to read. Because RDR could be set while there could no data in the receive FIFO. Restored pre 6d9939f6514 way of handling errata. Found by code review. Real impact haven't seen. Tested on Beagleboard XM C. Signed-off-by: Alexander Kochetkov Fixes: 6d9939f651419a63e09110 i2c: omap: split out [XR]DR and [XR]RDY Tested-by: Felipe Balbi Reviewed-by: Felipe Balbi Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit 16e6ef8005387cb03d8b743ca3e0a51f05082dce Author: Alexander Kochetkov Date: Tue Nov 18 21:00:58 2014 +0400 i2c: omap: fix NACK and Arbitration Lost irq handling commit 27caca9d2e01c92b26d0690f065aad093fea01c7 upstream. commit 1d7afc95946487945cc7f5019b41255b72224b70 (i2c: omap: ack IRQ in parts) changed the interrupt handler to complete transfers without clearing XRDY (AL case) and ARDY (NACK case) flags. XRDY or ARDY interrupts will be fired again. As a result, ISR keep processing transfer after it was already complete (from the driver code point of view). A didn't see real impacts of the 1d7afc9, but it is really bad idea to have ISR running on user data after transfer was complete. It looks, what 1d7afc9 violate TI specs in what how AL and NACK should be handled (see Note 1, sprugn4r, Figure 17-31 and Figure 17-32). According to specs (if I understood correctly), in case of NACK and AL driver must reset NACK, AL, ARDY, RDR, and RRDY (Master Receive Mode), and NACK, AL, ARDY, and XDR (Master Transmitter Mode). All that is done down the code under the if condition: if (stat & (OMAP_I2C_STAT_ARDY | OMAP_I2C_STAT_NACK | OMAP_I2C_STAT_AL)) ... The patch restore pre 1d7afc9 logic of handling NACK and AL interrupts, so no interrupts is fired after ISR informs the rest of driver what transfer complete. Note: instead of removing break under NACK case, we could just replace 'break' with 'continue' and allow NACK transfer to finish using ARDY event. I found that NACK and ARDY bits usually set together. That case confirm TI wiki: http://processors.wiki.ti.com/index.php/I2C_Tips#Detecting_and_handling_NACK In order if someone interested in the event traces for NACK and AL cases, I sent them to mailing list. Tested on Beagleboard XM C. Signed-off-by: Alexander Kochetkov Fixes: 1d7afc9 i2c: omap: ack IRQ in parts Acked-by: Felipe Balbi Tested-by: Aaro Koskinen Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit c080e59b32df97aa4291675cce720effa3d9576b Author: Dave Airlie Date: Tue Dec 2 16:27:25 2014 +1000 nouveau: move the hotplug ignore to correct place. commit 8b62c8c6df08ca567c78afa51aa7bbc554cede06 upstream. Introduced in b440bde74f, however it was added to the wrong function in nouveau. https://bugzilla.kernel.org/show_bug.cgi?id=86011 Cc: Bjorn Helgaas Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 66334e06875a0d0e219737140002fbb80be83810 Author: Ilia Mirkin Date: Sun Nov 30 12:56:18 2014 -0500 drm/nouveau/gf116: remove copy1 engine commit 226d63a1addea8cbe8fc671978e62dc84927b046 upstream. Indications are that no GF116's actually have a copy engine there, but actually have the decompression engine. This engine can be made to do copies, but that should be done separately. Unclear why this didn't turn up on all GF116's, but perhaps the non-mobile ones came with enough VRAM to not trigger ttm migrations in test scenarios. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=85465 Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=59168 Signed-off-by: Ilia Mirkin Signed-off-by: Ben Skeggs Signed-off-by: Greg Kroah-Hartman commit 3ed455481c0dc39d8535851f24cd4b19e47bbb29 Author: Seth Forshee Date: Tue Nov 25 20:28:24 2014 -0600 xen-netfront: Remove BUGs on paged skb data which crosses a page boundary commit 8d609725d4357f499e2103e46011308b32f53513 upstream. These BUGs can be erroneously triggered by frags which refer to tail pages within a compound page. The data in these pages may overrun the hardware page while still being contained within the compound page, but since compound_order() evaluates to 0 for tail pages the assertion fails. The code already iterates through subsequent pages correctly in this scenario, so the BUGs are unnecessary and can be removed. Fixes: f36c374782e4 ("xen/netfront: handle compound page fragments on transmit") Signed-off-by: Seth Forshee Reviewed-by: David Vrabel Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit ac96565df0d251b812b2fad03c73c30e4d8909be Author: Paul Mackerras Date: Tue Dec 2 15:59:48 2014 -0800 slab: fix nodeid bounds check for non-contiguous node IDs commit 7c3fbbdd04a681a1992ad6a3d7a36a63ff668753 upstream. The bounds check for nodeid in ____cache_alloc_node gives false positives on machines where the node IDs are not contiguous, leading to a panic at boot time. For example, on a POWER8 machine the node IDs are typically 0, 1, 16 and 17. This means that num_online_nodes() returns 4, so when ____cache_alloc_node is called with nodeid = 16 the VM_BUG_ON triggers, like this: kernel BUG at /home/paulus/kernel/kvm/mm/slab.c:3079! Call Trace: .____cache_alloc_node+0x5c/0x270 (unreliable) .kmem_cache_alloc_node_trace+0xdc/0x360 .init_list+0x3c/0x128 .kmem_cache_init+0x1dc/0x258 .start_kernel+0x2a0/0x568 start_here_common+0x20/0xa8 To fix this, we instead compare the nodeid with MAX_NUMNODES, and additionally make sure it isn't negative (since nodeid is an int). The check is there mainly to protect the array dereference in the get_node() call in the next line, and the array being dereferenced is of size MAX_NUMNODES. If the nodeid is in range but invalid (for example if the node is off-line), the BUG_ON in the next line will catch that. Fixes: 14e50c6a9bc2 ("mm: slab: Verify the nodeid passed to ____cache_alloc_node") Signed-off-by: Paul Mackerras Reviewed-by: Yasuaki Ishimatsu Reviewed-by: Pekka Enberg Acked-by: David Rientjes Cc: Christoph Lameter Cc: Joonsoo Kim Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 093013219b53c57721ba03377583d814338d1ec0 Author: Daniel Forrest Date: Tue Dec 2 15:59:42 2014 -0800 mm: fix anon_vma_clone() error treatment commit c4ea95d7cd08d9ffd7fa75e6c5e0332d596dd11e upstream. Andrew Morton noticed that the error return from anon_vma_clone() was being dropped and replaced with -ENOMEM (which is not itself a bug because the only error return value from anon_vma_clone() is -ENOMEM). I did an audit of callers of anon_vma_clone() and discovered an actual bug where the error return was being lost. In __split_vma(), between Linux 3.11 and 3.12 the code was changed so the err variable is used before the call to anon_vma_clone() and the default initial value of -ENOMEM is overwritten. So a failure of anon_vma_clone() will return success since err at this point is now zero. Below is a patch which fixes this bug and also propagates the error return value from anon_vma_clone() in all cases. Fixes: ef0855d334e1 ("mm: mempolicy: turn vma_set_policy() into vma_dup_policy()") Signed-off-by: Daniel Forrest Reviewed-by: Michal Hocko Cc: Konstantin Khlebnikov Cc: Andrea Arcangeli Cc: Rik van Riel Cc: Tim Hartrick Cc: Hugh Dickins Cc: Michel Lespinasse Cc: Vlastimil Babka Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 9ceac1c4e6b7a0c2efb125fed4ae3ce65b919ed8 Author: Hugh Dickins Date: Tue Dec 2 15:59:39 2014 -0800 mm: fix swapoff hang after page migration and fork commit 2022b4d18a491a578218ce7a4eca8666db895a73 upstream. I've been seeing swapoff hangs in recent testing: it's cycling around trying unsuccessfully to find an mm for some remaining pages of swap. I have been exercising swap and page migration more heavily recently, and now notice a long-standing error in copy_one_pte(): it's trying to add dst_mm to swapoff's mmlist when it finds a swap entry, but is doing so even when it's a migration entry or an hwpoison entry. Which wouldn't matter much, except it adds dst_mm next to src_mm, assuming src_mm is already on the mmlist: which may not be so. Then if pages are later swapped out from dst_mm, swapoff won't be able to find where to replace them. There's already a !non_swap_entry() test for stats: move that up before the swap_duplicate() and the addition to mmlist. Signed-off-by: Hugh Dickins Cc: Kelley Nielsen Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 827a4f2a784d1de5375978b4a54049dc19bea465 Author: Al Viro Date: Tue Dec 2 15:59:37 2014 -0800 fat: fix oops on corrupted vfat fs commit 1ead0e79bfedd4b563b8ea7c585ca3884b0c89a7 upstream. a) don't bother with ->d_time for positives - we only check it for negatives anyway. b) make sure to set it at unlink and rmdir time - at *that* point soon-to-be negative dentry matches then-current directory contents c) don't go into renaming of old alias in vfat_lookup() unless it has the same parent (which it will, unless we are seeing corrupted image) [hirofumi@mail.parknet.co.jp: make change minimum, don't call d_move() for dir] Signed-off-by: Al Viro Signed-off-by: OGAWA Hirofumi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 3abaac9510bbdf474567e19b6bb5c32e5260d2bd Author: Andrew Morton Date: Tue Dec 2 15:59:31 2014 -0800 drivers/input/evdev.c: don't kfree() a vmalloc address commit 92788ac1eb06e69a822de45e2a8a63fa45eb5be2 upstream. If kzalloc() failed and then evdev_open_device() fails, evdev_open() will pass a vmalloc'ed pointer to kfree. This might fix https://bugzilla.kernel.org/show_bug.cgi?id=88401, where there was a crash in kfree(). Reported-by: Christian Casteyde Belatedly-Acked-by: Dmitry Torokhov Cc: Henrik Rydberg Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 1b543987277fe14880526e88cc77fa72e1c3db38 Author: Andrew Morton Date: Tue Dec 2 15:59:28 2014 -0800 mm/vmpressure.c: fix race in vmpressure_work_fn() commit 91b57191cfd152c02ded0745250167d0263084f8 upstream. In some android devices, there will be a "divide by zero" exception. vmpr->scanned could be zero before spin_lock(&vmpr->sr_lock). Addresses https://bugzilla.kernel.org/show_bug.cgi?id=88051 [akpm@linux-foundation.org: neaten] Reported-by: ji_ang Cc: Anton Vorontsov Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit f9a9b82b1063abb90b5f3c5d97ee859179a6218d Author: Weijie Yang Date: Tue Dec 2 15:59:25 2014 -0800 mm: frontswap: invalidate expired data on a dup-store failure commit fb993fa1a2f669215fa03a09eed7848f2663e336 upstream. If a frontswap dup-store failed, it should invalidate the expired page in the backend, or it could trigger some data corruption issue. Such as: 1. use zswap as the frontswap backend with writeback feature 2. store a swap page(version_1) to entry A, success 3. dup-store a newer page(version_2) to the same entry A, fail 4. use __swap_writepage() write version_2 page to swapfile, success 5. zswap do shrink, writeback version_1 page to swapfile 6. version_2 page is overwrited by version_1, data corrupt. This patch fixes this issue by invalidating expired data immediately when meet a dup-store failure. Signed-off-by: Weijie Yang Cc: Konrad Rzeszutek Wilk Cc: Seth Jennings Cc: Dan Streetman Cc: Minchan Kim Cc: Bob Liu Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman