- 16 Dec, 2014 28 commits
-
-
Kan Liang authored
commit 338b522c upstream. With -cpu host, KVM reports LBR and extra_regs support, if the host has support. When the guest perf driver tries to access LBR or extra_regs MSR, it #GPs all MSR accesses,since KVM doesn't handle LBR and extra_regs support. So check the related MSRs access right once at initialization time to avoid the error access at runtime. For reproducing the issue, please build the kernel with CONFIG_KVM_INTEL = y (for host kernel). And CONFIG_PARAVIRT = n and CONFIG_KVM_GUEST = n (for guest kernel). Start the guest with -cpu host. Run perf record with --branch-any or --branch-filter in guest to trigger LBR Run perf stat offcore events (E.g. LLC-loads/LLC-load-misses ...) in guest to trigger offcore_rsp #GP Signed-off-by:
Kan Liang <kan.liang@intel.com> Signed-off-by:
Peter Zijlstra <peterz@infradead.org> Cc: Andi Kleen <ak@linux.intel.com> Cc: Arnaldo Carvalho de Melo <acme@kernel.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Maria Dimakopoulou <maria.n.dimakopoulou@gmail.com> Cc: Mark Davies <junk@eslaf.co.uk> Cc: Paul Mackerras <paulus@samba.org> Cc: Stephane Eranian <eranian@google.com> Cc: Yan, Zheng <zheng.z.yan@intel.com> Link: http://lkml.kernel.org/r/1405365957-20202-1-git-send-email-kan.liang@intel.comSigned-off-by:
Ingo Molnar <mingo@kernel.org> Cc: Dongsu Park <dongsu.park@profitbricks.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Daniel Borkmann authored
[ Upstream commit 9772b54c ] 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 <robert@swiecki.net> Reference: https://lkml.org/lkml/2014/12/1/507 Fixes: 594ccc14 ("[SCTP] Replace incorrect use of dev_alloc_skb with alloc_skb in sctp_packet_transmit().") Signed-off-by:
Daniel Borkmann <dborkman@redhat.com> Acked-by:
Vlad Yasevich <vyasevich@gmail.com> Acked-by:
Neil Horman <nhorman@tuxdriver.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Eric Dumazet authored
[ Upstream commit 5f478b41 ] 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: 71f6d1b3 ("net: mvneta: replace Tx timer with a real interrupt") Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
-
willy tarreau authored
[ Upstream commit aebea2ba ] 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 <maggie.mae.roxas@gmail.com> Signed-off-by:
Willy Tarreau <w@1wt.eu> Signed-off-by:
-
Tom Herbert authored
[ Upstream commit 6fb2a756 ] 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: 14051f04 ("gre: Use inner mac length when computing tunnel length") Reported-by:
Wolfgang Walter <linux@stwm.de> Signed-off-by:
Tom Herbert <therbert@google.com> Signed-off-by:
-
Nicolas Dichtel authored
[ Upstream commit e0ebde0e ] rtnl_link_get_net() holds a reference on the 'struct net', we need to release it in case of error. CC: Eric W. Biederman <ebiederm@xmission.com> Fixes: b51642f6 ("net: Enable a userns root rtnl calls that are safe for unprivilged users") Signed-off-by:
Nicolas Dichtel <nicolas.dichtel@6wind.com> Reviewed-by:
"Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by:
-
Jack Morgenstein authored
[ Upstream commit 2d5c57d7 ] 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: c82e9aa0 "mlx4_core: resource tracking for HCA resources used by guests" Signed-off-by:
Jack Morgenstein <jackm@dev.mellanox.co.il> Signed-off-by:
Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by:
-
Thadeu Lima de Souza Cascardo authored
[ Upstream commit a620a6bc ] 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 <cascardo@linux.vnet.ibm.com> Signed-off-by:
-
Marcelo Leitner authored
[ Upstream commit 00c83b01 ] 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 <mleitner@redhat.com> Fixes: 7c47cedf ("vxlan: move IGMP join/leave to work queue") Signed-off-by:
-
Yuri Chislov authored
[ Upstream commit be6572fd ] 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: c12b395a ("gre: Support GRE over IPv6") Cc: Dmitry Kozlov <xeb@mail.ru> Signed-off-by:
Yuri Chislov <yuri.chislov@gmail.com> Tested-by:
-
lucien authored
[ Upstream commit 20ea60ca ] 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: [<ffffffffa04103fd>] 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] [<ffffffffa0411924>] ip_tunnel_newlink+0x64/0x160 [ip_tunnel] [ 3835.073008] [<ffffffffa040b2e3>] vti_newlink+0x43/0x70 [ip_vti] [ 3835.073008] [<ffffffff8150d4da>] rtnl_newlink+0x4fa/0x5f0 [ 3835.073008] [<ffffffff812f68bb>] ? nla_strlcpy+0x5b/0x70 [ 3835.073008] [<ffffffff81508fb0>] ? rtnl_link_ops_get+0x40/0x60 [ 3835.073008] [<ffffffff8150d11f>] ? rtnl_newlink+0x13f/0x5f0 [ 3835.073008] [<ffffffff81509cf4>] rtnetlink_rcv_msg+0xa4/0x270 [ 3835.073008] [<ffffffff8126adf5>] ? sock_has_perm+0x75/0x90 [ 3835.073008] [<ffffffff81509c50>] ? rtnetlink_rcv+0x30/0x30 [ 3835.073008] [<ffffffff81529e39>] netlink_rcv_skb+0xa9/0xc0 [ 3835.073008] [<ffffffff81509c48>] 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 <lucien.xin@gmail.com> Signed-off-by:
Cong Wang <cwang@twopensource.com> Signed-off-by:
-
Dmitry Torokhov authored
commit aad0b624 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 <dtor@chromium.org> Signed-off-by:
Tejun Heo <tj@kernel.org> Signed-off-by:
-
Tejun Heo authored
commit 2b21ef0a upstream. Just like 0x1600 which got blacklisted by 66a7cbc3 ("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:
Dominik Mierzejewski <dominik@greysector.net> Link: https://bugzilla.kernel.org/show_bug.cgi?id=89171Signed-off-by:
-
Devin Ryles authored
commit 249cd0a1 upstream. This patch adds DeviceIDs for Sunrise Point-LP. Signed-off-by:
Devin Ryles <devin.ryles@intel.com> Signed-off-by:
-
Mathias Nyman authored
commit 8e71a322 upstream. If a device is halted and reuturns a STALL, then the halted endpoint needs to be cleared both on the host and device side. The host side halt is cleared by issueing a xhci reset endpoint command. The device side is cleared with a ClearFeature(ENDPOINT_HALT) request, which should be issued by the device driver if a URB reruen -EPIPE. Previously we cleared the host side halt after the device side was cleared. To make sure the host side halt is cleared in time we want to issue the reset endpoint command immedialtely when a STALL status is encountered. Otherwise we end up not following the specs and not returning -EPIPE several times in a row when trying to transfer data to a halted endpoint. Fixes: bcef3fd5 (USB: xhci: Handle errors that cause endpoint halts.) Tested-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by:
-
Sakari Ailus authored
commit b31eb901 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 <sakari.ailus@iki.fi> Signed-off-by:
Mauro Carvalho Chehab <mchehab@osg.samsung.com> Signed-off-by:
-
Chris Clayton authored
commit e2e68ae6 upstream. commit e6023367 '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: e6023367 'x86, kaslr: Prevent .bss from overlaping initrd' Signed-off-by:
Chris Clayton <chris2553@googlemail.com> Acked-by:
Kees Cook <keescook@chromium.org> Acked-by:
Borislav Petkov <bp@suse.de> Cc: Junjie Mao <eternal.n08@gmail.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: H. Peter Anvin <hpa@linux.intel.com> Link: http://lkml.kernel.org/r/54705C8E.1080400@googlemail.comSigned-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Daniel Vetter authored
commit b0616c53 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 c31407a3 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Thu Oct 18 21:07:01 2012 +0100 drm/i915: Add no-lvds quirk for Supermicro X7SPA-H Reported-by:
Alexey Orishko <alexey.orishko@gmail.com> Cc: Alexey Orishko <alexey.orishko@gmail.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Francois Tigeot <ftigeot@wolfpond.org> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Tested-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Daniel Vetter authored
commit b6836227 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=86478Signed-off-by:
lu hua <huax.lu@intel.com> Reviewed-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
-
Petr Mladek authored
commit f5475cc4 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: [<ffffffff8150423b>] 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:[<ffffffff8150423b>] [<ffffffff8150423b>] 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: [<ffffffff8151b51d>] ? drm_vma_offset_remove+0x1d/0x110 [<ffffffff8152dc98>] radeon_get_vblank_timestamp_kms+0x38/0x60 [<ffffffff8152076a>] ? ttm_bo_release_list+0xba/0x180 [<ffffffff81503751>] drm_get_last_vbltimestamp+0x41/0x70 [<ffffffff81503933>] vblank_disable_and_save+0x73/0x1d0 [<ffffffff81106b2f>] ? try_to_del_timer_sync+0x4f/0x70 [<ffffffff81505245>] drm_vblank_cleanup+0x65/0xa0 [<ffffffff815604fa>] radeon_irq_kms_fini+0x1a/0x70 [<ffffffff8156c07e>] r100_init+0x26e/0x410 [<ffffffff8152ae3e>] radeon_device_init+0x7ae/0xb50 [<ffffffff8152d57f>] radeon_driver_load_kms+0x8f/0x210 [<ffffffff81506965>] drm_dev_register+0xb5/0x110 [<ffffffff8150998f>] drm_get_pci_dev+0x8f/0x200 [<ffffffff815291cd>] radeon_pci_probe+0xad/0xe0 [<ffffffff8141a365>] local_pci_probe+0x45/0xa0 [<ffffffff8141b741>] pci_device_probe+0xd1/0x130 [<ffffffff81633dad>] driver_probe_device+0x12d/0x3e0 [<ffffffff8163413b>] __driver_attach+0x9b/0xa0 [<ffffffff816340a0>] ? __device_attach+0x40/0x40 [<ffffffff81631cd3>] bus_for_each_dev+0x63/0xa0 [<ffffffff8163378e>] driver_attach+0x1e/0x20 [<ffffffff81633390>] bus_add_driver+0x180/0x240 [<ffffffff81634914>] driver_register+0x64/0xf0 [<ffffffff81419cac>] __pci_register_driver+0x4c/0x50 [<ffffffff81509bf5>] drm_pci_init+0xf5/0x120 [<ffffffff821dc871>] ? ttm_init+0x6a/0x6a [<ffffffff821dc908>] radeon_init+0x97/0xb5 [<ffffffff810002fc>] do_one_initcall+0xbc/0x1f0 [<ffffffff810e3278>] ? __wake_up+0x48/0x60 [<ffffffff8218e256>] kernel_init_freeable+0x18a/0x215 [<ffffffff8218d983>] ? initcall_blacklist+0xc0/0xc0 [<ffffffff818a78f0>] ? rest_init+0x80/0x80 [<ffffffff818a78fe>] kernel_init+0xe/0xf0 [<ffffffff818c0c3c>] ret_from_fork+0x7c/0xb0 [<ffffffff818a78f0>] ? 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 [<ffffffff8150423b>] drm_calc_vbltimestamp_from_scanoutpos+0x4b/0x320 RSP <ffff880234da7918> 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 <deller@gmx.de> Signed-off-by:
Petr Mladek <pmladek@suse.cz> Tested-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Grygorii Strashko authored
commit 9ea359f7 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 cda2109a ("i2c: omap: query STP always when NACK is received"). Reviewed-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reported-by:
Hein Tibosch <hein_tibosch@yahoo.es> Signed-off-by:
Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Signed-off-by:
-
Alexander Kochetkov authored
commit ccfc8663 upstream. commit 6d9939f6 (i2c: omap: split out [XR]DR and [XR]RDY) changed the way how errata i207 (I2C: RDR Flag May Be Incorrectly Set) get handled. 6d9939f6 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 6d9939f6 way of handling errata. Found by code review. Real impact haven't seen. Tested on Beagleboard XM C. Signed-off-by:
Alexander Kochetkov <al.kochet@gmail.com> Fixes: 6d9939f6 i2c: omap: split out [XR]DR and [XR]RDY Tested-by:
-
Alexander Kochetkov authored
commit 27caca9d upstream. commit 1d7afc95 (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 1d7afc95, but it is really bad idea to have ISR running on user data after transfer was complete. It looks, what 1d7afc95 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 1d7afc95 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:
Aaro Koskinen <aaro.koskinen@iki.fi> Signed-off-by:
-
Seth Forshee authored
commit 8d609725 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: f36c3747 ("xen/netfront: handle compound page fragments on transmit") Signed-off-by:
Seth Forshee <seth.forshee@canonical.com> Reviewed-by:
David Vrabel <david.vrabel@citrix.com> Signed-off-by:
-
Daniel Forrest authored
commit c4ea95d7 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: ef0855d3 ("mm: mempolicy: turn vma_set_policy() into vma_dup_policy()") Signed-off-by:
Daniel Forrest <dan.forrest@ssec.wisc.edu> Reviewed-by:
Michal Hocko <mhocko@suse.cz> Cc: Konstantin Khlebnikov <koct9i@gmail.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: Rik van Riel <riel@redhat.com> Cc: Tim Hartrick <tim@edgecast.com> Cc: Hugh Dickins <hughd@google.com> Cc: Michel Lespinasse <walken@google.com> Cc: Vlastimil Babka <vbabka@suse.cz> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Hugh Dickins authored
commit 2022b4d1 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 <hughd@google.com> Cc: Kelley Nielsen <kelleynnn@gmail.com> Signed-off-by:
-
Andrew Morton authored
commit 91b57191 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 <ji_ang@163.com> Cc: Anton Vorontsov <anton.vorontsov@linaro.org> Signed-off-by:
-
Weijie Yang authored
commit fb993fa1 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 <weijie.yang@samsung.com> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: Seth Jennings <sjennings@variantweb.net> Cc: Dan Streetman <ddstreet@ieee.org> Cc: Minchan Kim <minchan@kernel.org> Cc: Bob Liu <bob.liu@oracle.com> Signed-off-by:
-
- 06 Dec, 2014 12 commits
-
-
Greg Kroah-Hartman authored
-
David Jeffery authored
commit 92a56555 upstream. If a SIGKILL is sent to a task waiting in __nfs_iocounter_wait, it will busy-wait or soft lockup in its while loop. nfs_wait_bit_killable won't sleep, and the loop won't exit on the error return. Stop the busy-wait by breaking out of the loop when nfs_wait_bit_killable returns an error. Signed-off-by:
David Jeffery <djeffery@redhat.com> Signed-off-by:
Trond Myklebust <trond.myklebust@primarydata.com> [ kamal: backport to 3.13-stable: context ] Cc: Moritz Mühlenhoff <muehlenhoff@univention.de> Signed-off-by:
Kamal Mostafa <kamal@canonical.com> Signed-off-by:
-
Paolo Bonzini authored
commit c1118b36 upstream. On x86_64, kernel text mappings are mapped read-only with CONFIG_DEBUG_RODATA. In that case, KVM will fail to patch VMCALL instructions to VMMCALL as required on AMD processors. The failure mode is currently a divide-by-zero exception, which obviously is a KVM bug that has to be fixed. However, picking the right instruction between VMCALL and VMMCALL will be faster and will help if you cannot upgrade the hypervisor. Reported-by:
Chris Webb <chris@arachsys.com> Tested-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
Chris J Arges <chris.j.arges@canonical.com> Signed-off-by:
-
Cong Wang authored
commit b6ed5498 upstream. batman tries to search dev->iflink to check if it's a batman interface, but ->iflink could be 0, which is not a valid ifindex. It should just avoid iflink == 0 case. Reported-by:
Jet Chen <jet.chen@intel.com> Tested-by:
Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by:
-
Benjamin Herrenschmidt authored
commit 36074381 upstream. Instead of the arch specific quirk which we are deprecating and that drivers don't understand. Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Jeff Layton authored
commit 8c3cac5e upstream. A leftover lock on the list is surely a sign of a problem of some sort, but it's not necessarily a reason to panic the box. Instead, just log a warning with some info about the lock, and then delete it like we would any other lock. In the event that the filesystem declares a ->lock f_op, we may end up leaking something, but that's generally preferable to an immediate panic. Acked-by:
J. Bruce Fields <bfields@fieldses.org> Signed-off-by:
Jeff Layton <jlayton@redhat.com> Cc: Markus Blank-Burian <burian@muenster.de> Signed-off-by:
-
Maxime COQUELIN authored
commit 00b4d9a1 upstream. On some 32 bits architectures, including x86, GENMASK(31, 0) returns 0 instead of the expected ~0UL. This is the same on some 64 bits architectures with GENMASK_ULL(63, 0). This is due to an overflow in the shift operand, 1 << 32 for GENMASK, 1 << 64 for GENMASK_ULL. Reported-by:
Eric Paire <eric.paire@st.com> Suggested-by:
Rasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by:
Maxime Coquelin <maxime.coquelin@st.com> Signed-off-by:
-
Benjamin Herrenschmidt authored
commit 91ed6fd2 upstream. Some radeon ASICs don't support all 64 address bits of MSIs despite advertising support for 64-bit MSIs in their configuration space. This breaks on systems such as IBM POWER7/8, where 64-bit MSIs can be assigned with some of the high address bits set. This makes use of the newly introduced "no_64bit_msi" flag in structure pci_dev to allow the MSI allocation code to fallback to 32-bit MSIs on those adapters. Adding Alex's review tag. Patch to the driver is identical to the reviewed one, I dropped the arch/powerpc hunk rewrote the subject and cset comment. Signed-off-by:
-
Alex Deucher authored
commit 28731d58 upstream. Value needs to be swapped on BE. Signed-off-by:
-
Maurizio Lombardi authored
commit 01a4cc4d upstream. In some cases, the fcoe_rx_list may contains multiple instances of the same skb (the so called "shared skbs"). the bnx2fc_l2_rcv thread is a loop that extracts a skb from the list, modifies (and destroys) its content and then proceed to the next one. The problem is that if the skb is shared, the remaining instances will be corrupted. The solution is to use skb_share_check() before adding the skb to the fcoe_rx_list. [ 6286.808725] ------------[ cut here ]------------ [ 6286.808729] WARNING: at include/scsi/fc_frame.h:173 bnx2fc_l2_rcv_thread+0x425/0x450 [bnx2fc]() [ 6286.808748] Modules linked in: bnx2x(-) mdio dm_service_time bnx2fc cnic uio fcoe libfcoe 8021q garp stp mrp libfc llc scsi_transport_fc scsi_tgt sg iTCO_wdt iTCO_vendor_support coretemp kvm_intel kvm crct10dif_pclmul crc32_pclmul crc32c_intel e1000e ghash_clmulni_intel aesni_intel lrw gf128mul glue_helper ablk_helper ptp cryptd hpilo serio_raw hpwdt lpc_ich pps_core ipmi_si pcspkr mfd_core ipmi_msghandler shpchp pcc_cpufreq mperf nfsd auth_rpcgss nfs_acl lockd sunrpc dm_multipath xfs libcrc32c ata_generic pata_acpi sd_mod crc_t10dif crct10dif_common mgag200 syscopyarea sysfillrect sysimgblt i2c_algo_bit ata_piix drm_kms_helper ttm drm libata i2c_core hpsa dm_mirror dm_region_hash dm_log dm_mod [last unloaded: mdio] [ 6286.808750] CPU: 3 PID: 1304 Comm: bnx2fc_l2_threa Not tainted 3.10.0-121.el7.x86_64 #1 [ 6286.808750] Hardware name: HP ProLiant DL120 G7, BIOS J01 07/01/2013 [ 6286.808752] 0000000000000000 000000000b36e715 ffff8800deba1e00 ffffffff815ec0ba [ 6286.808753] ffff8800deba1e38 ffffffff8105dee1 ffffffffa05618c0 ffff8801e4c81888 [ 6286.808754] ffffe8ffff663868 ffff8801f402b180 ffff8801f56bc000 ffff8800deba1e48 [ 6286.808754] Call Trace: [ 6286.808759] [<ffffffff815ec0ba>] dump_stack+0x19/0x1b [ 6286.808762] [<ffffffff8105dee1>] warn_slowpath_common+0x61/0x80 [ 6286.808763] [<ffffffff8105e00a>] warn_slowpath_null+0x1a/0x20 [ 6286.808765] [<ffffffffa054f415>] bnx2fc_l2_rcv_thread+0x425/0x450 [bnx2fc] [ 6286.808767] [<ffffffffa054eff0>] ? bnx2fc_disable+0x90/0x90 [bnx2fc] [ 6286.808769] [<ffffffff81085aef>] kthread+0xcf/0xe0 [ 6286.808770] [<ffffffff81085a20>] ? kthread_create_on_node+0x140/0x140 [ 6286.808772] [<ffffffff815fc76c>] ret_from_fork+0x7c/0xb0 [ 6286.808773] [<ffffffff81085a20>] ? kthread_create_on_node+0x140/0x140 [ 6286.808774] ---[ end trace c6cdb939184ccb4e ]--- Signed-off-by:
Maurizio Lombardi <mlombard@redhat.com> Acked-by:
Chad Dupuis <chad.dupuis@qlogic.com> Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Jane Zhou authored
commit 91a0b603 upstream. ping_lookup() may return a wrong sock if sk_buff's and sock's protocols dont' match. For example, sk_buff's protocol is ETH_P_IPV6, but sock's sk_family is AF_INET, in that case, if sk->sk_bound_dev_if is zero, a wrong sock will be returned. the fix is to "continue" the searching, if no matching, return NULL. Cc: "David S. Miller" <davem@davemloft.net> Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru> Cc: James Morris <jmorris@namei.org> Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org> Cc: Patrick McHardy <kaber@trash.net> Cc: netdev@vger.kernel.org Signed-off-by:
Jane Zhou <a17711@motorola.com> Signed-off-by:
Yiwei Zhao <gbjc64@motorola.com> Signed-off-by:
-
Jeff Layton authored
commit 1b19453d upstream. Currently, the DRC cache pruner will stop scanning the list when it hits an entry that is RC_INPROG. It's possible however for a call to take a *very* long time. In that case, we don't want it to block other entries from being pruned if they are expired or we need to trim the cache to get back under the limit. Fix the DRC cache pruner to just ignore RC_INPROG entries. Signed-off-by:
Jeff Layton <jlayton@primarydata.com> Signed-off-by:
J. Bruce Fields <bfields@redhat.com> Cc: Joseph Salisbury <joseph.salisbury@canonical.com> Signed-off-by:
-
