- 13 Jul, 2016 40 commits
-
-
Hannes Frederic Sowa authored
BugLink: http://bugs.launchpad.net/bugs/1596575 [ Upstream commit e5aed006 ] In case we find a socket with encapsulation enabled we should call the encap_recv function even if just a udp header without payload is available. The callbacks are responsible for correctly verifying and dropping the packets. Also, in case the header validation fails for geneve and vxlan we shouldn't put the skb back into the socket queue, no one will pick them up there. Instead we can simply discard them in the respective encap_recv functions. Signed-off-by:
Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Tim Gardner <tim.gardner@canonical.com> Signed-off-by:
Kamal Mostafa <kamal@canonical.com>
-
Jason Wang authored
BugLink: http://bugs.launchpad.net/bugs/1596575 [ Upstream commit addf8fc4 ] We used to check dev->reg_state against NETREG_REGISTERED after each time we are woke up. But after commit 9e641bdc ("net-tun: restructure tun_do_read for better sleep/wakeup efficiency"), it uses skb_recv_datagram() which does not check dev->reg_state. This will result if we delete a tun/tap device after a process is blocked in the reading. The device will wait for the reference count which was held by that process for ever. Fixes this by using RCV_SHUTDOWN which will be checked during sk_recv_datagram() before trying to wake up the process during uninit. Fixes: 9e641bdc ("net-tun: restructure tun_do_read for better sleep/wakeup efficiency") Cc: Eric Dumazet <edumazet@google.com> Cc: Xi Wang <xii@google.com> Cc: Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
Jason Wang <jasowang@redhat.com> Acked-by:
Eric Dumazet <edumazet@google.com> Acked-by:
Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
-
Jiri Pirko authored
BugLink: http://bugs.launchpad.net/bugs/1596575 [ Upstream commit da4ed551 ] The problem is that fib_info->nh is [0] so the struct fib_info allocation size depends on number of nexthops. If we just copy fib_info, we do not copy the nexthops info and driver accesses memory which is not ours. Given the fact that fib4 does not defer operations and therefore it does not need copy, just pass the pointer down to drivers as it was done before. Fixes: 850d0cbc ("switchdev: remove pointers from switchdev objects") Signed-off-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
-
Richard Alpe authored
BugLink: http://bugs.launchpad.net/bugs/1596575 [ Upstream commit 03aaaa9b ] The publication field of the old netlink API should contain the publication key and not the publication reference. Fixes: 44a8ae94 (tipc: convert legacy nl name table dump to nl compat) Signed-off-by:
Richard Alpe <richard.alpe@ericsson.com> Acked-by:
Jon Maloy <jon.maloy@ericsson.com> Signed-off-by:
-
Herbert Xu authored
BugLink: http://bugs.launchpad.net/bugs/1596575 [ Upstream commit 92964c79 ] When we free cb->skb after a dump, we do it after releasing the lock. This means that a new dump could have started in the time being and we'll end up freeing their skb instead of ours. This patch saves the skb and module before we unlock so we free the right memory. Fixes: 16b304f3 ("netlink: Eliminate kmalloc in netlink dump operation.") Reported-by:
Baozeng Ding <sploving1@gmail.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Acked-by:
Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by:
-
Ewan D. Milne authored
BugLink: http://bugs.launchpad.net/bugs/1596575 commit fbd83006 upstream. Linux fails to boot as a guest with a QEMU CD-ROM: [ 4.439488] ata2.00: ATAPI: QEMU CD-ROM, 0.8.2, max UDMA/100 [ 4.443649] ata2.00: configured for MWDMA2 [ 4.450267] scsi 1:0:0:0: CD-ROM QEMU QEMU CD-ROM 0.8. PQ: 0 ANSI: 5 [ 4.464317] ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen [ 4.464319] ata2.00: BMDMA stat 0x5 [ 4.464339] ata2.00: cmd a0/01:00:00:00:01/00:00:00:00:00/a0 tag 0 dma 16640 in [ 4.464339] Inquiry 12 01 00 00 ff 00res 48/20:02:00:24:00/00:00:00:00:00/a0 Emask 0x2 (HSM violation) [ 4.464341] ata2.00: status: { DRDY DRQ } [ 4.465864] ata2: soft resetting link [ 4.625971] ata2.00: configured for MWDMA2 [ 4.628290] ata2: EH complete [ 4.646670] ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen [ 4.646671] ata2.00: BMDMA stat 0x5 [ 4.646683] ata2.00: cmd a0/01:00:00:00:01/00:00:00:00:00/a0 tag 0 dma 16640 in [ 4.646683] Inquiry 12 01 00 00 ff 00res 48/20:02:00:24:00/00:00:00:00:00/a0 Emask 0x2 (HSM violation) [ 4.646685] ata2.00: status: { DRDY DRQ } [ 4.648193] ata2: soft resetting link ... Fix this by suppressing VPD inquiry for this device. Signed-off-by:
Ewan D. Milne <emilne@redhat.com> Reported-by:
Jan Stancek <jstancek@redhat.com> Tested-by:
Johannes Thumshirn <jthumshirn@suse.de> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
James Bottomley authored
BugLink: http://bugs.launchpad.net/bugs/1596575 commit a621bac3 upstream. When SCSI was written, all commands coming from the filesystem (REQ_TYPE_FS commands) had data. This meant that our signal for needing to complete the command was the number of bytes completed being equal to the number of bytes in the request. Unfortunately, with the advent of flush barriers, we can now get zero length REQ_TYPE_FS commands, which confuse this logic because they satisfy the condition every time. This means they never get retried even for retryable conditions, like UNIT ATTENTION because we complete them early assuming they're done. Fix this by special casing the early completion condition to recognise zero length commands with errors and let them drop through to the retry code. Reported-by:
Sebastian Parschauer <s.parschauer@gmx.de> Signed-off-by:
James E.J. Bottomley <jejb@linux.vnet.ibm.com> Tested-by:
Jack Wang <jinpu.wang@profitbricks.com> Signed-off-by:
-
Vitaly Kuznetsov authored
BugLink: http://bugs.launchpad.net/bugs/1583357 Hyper-V VMs can be replicated to another hosts and there is a feature to set different IP for replicas, it is called 'Failover TCP/IP'. When such guest starts Hyper-V host sends it KVP_OP_SET_IP_INFO message as soon as we finish negotiation procedure. The problem is that it can happen (and it actually happens) before userspace daemon connects and we reply with HV_E_FAIL to the message. As there are no repetitions we fail to set the requested IP. Solve the issue by postponing our reply to the negotiation message till userspace daemon is connected. We can't wait too long as there is a host-side timeout (cca. 75 seconds) and if we fail to reply in this time frame the whole KVP service will become inactive. The solution is not ideal - if it takes userspace daemon more than 60 seconds to connect IP Failover will still fail but I don't see a solution with our current separation between kernel and userspace parts. Other two modules (VSS and FCOPY) don't require such delay, leave them untouched. Signed-off-by:
Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by:
K. Y. Srinivasan <kys@microsoft.com> Signed-off-by:
Brad Figg <brad.figg@canonical.com> Signed-off-by:
-
K. Y. Srinivasan authored
BugLink: http://bugs.launchpad.net/bugs/1583357 On the consumer side, we have interrupt driven flow management of the producer. It is sufficient to base the signaling decision on the amount of space that is available to write after the read is complete. The current code samples the previous available space and uses this in making the signaling decision. This state can be stale and is unnecessary. Since the state can be stale, we end up not signaling the host (when we should) and this can result in a hang. Fix this problem by removing the unnecessary check. I would like to thank Arseney Romanenko <arseneyr@microsoft.com> for pointing out this issue. Also, issue a full memory barrier before making the signaling descision to correctly deal with potential reordering of the write (read index) followed by the read of pending_sz. Signed-off-by:
Dexuan Cui <decui@microsoft.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Vitaly Kuznetsov authored
BugLink: http://bugs.launchpad.net/bugs/1583357 Generation2 instances don't support reporting the NMI status on port 0x61, read from there returns 'ff' and we end up reporting nonsensical PCI error (as there is no PCI bus in these instances) on all NMIs: NMI: PCI system error (SERR) for reason ff on CPU 0. Dazed and confused, but trying to continue Fix the issue by overriding x86_platform.get_nmi_reason. Use 'booted on EFI' flag to detect Gen2 instances. Signed-off-by:
Ingo Molnar <mingo@kernel.org> (cherry picked from commit 1e2ae9ec) Signed-off-by:
-
Haiyang Zhang authored
BugLink: http://bugs.launchpad.net/bugs/1583357 Reorder the code in netvsc_sc_open(), so num_sc_offered is only decremented after vmbus_open() is called. This avoid pontential race of removing device before all channels are setup. Signed-off-by:
Haiyang Zhang <haiyangz@microsoft.com> Reviewed-by:
-
Haiyang Zhang authored
BugLink: http://bugs.launchpad.net/bugs/1583357 The VRSS_CHANNEL_MAX is the max number of channels supported by Hyper-V hosts. We use it for the related array sizes instead of using NR_CPUS, which may be set to several thousands. This patch reduces possible memory allocation failures. Signed-off-by:
-
Haiyang Zhang authored
BugLink: http://bugs.launchpad.net/bugs/1583357 struct netvsc_device is freed in rndis_filter_device_remove(). So we save the nvdev->num_chn into a temp variable for later usage. (Please also include this patch into stable branch.) Signed-off-by:
-
sixiao@microsoft.com authored
BugLink: http://bugs.launchpad.net/bugs/1583357 This patch allows the user to set and retrieve speed and duplex of the hv_netvsc device via ethtool. Example: $ ethtool eth0 Settings for eth0: ... Speed: Unknown! Duplex: Unknown! (255) ... $ ethtool -s eth0 speed 1000 duplex full $ ethtool eth0 Settings for eth0: ... Speed: 1000Mb/s Duplex: Full ... This is based on patches by Roopa Prabhu and Nikolay Aleksandrov. Signed-off-by:
Simon Xiao <sixiao@microsoft.com> Signed-off-by:
-
sixiao@microsoft.com authored
BugLink: http://bugs.launchpad.net/bugs/1583357 Enable skb_tx_timestamp in hyperv netvsc. Signed-off-by:
-
Andrey Smetanin authored
BugLink: http://bugs.launchpad.net/bugs/1583357 Rename HV_X64_HV_NOTIFY_LONG_SPIN_WAIT by HVCALL_NOTIFY_LONG_SPIN_WAIT, so the name is more consistent with the other hypercalls. Signed-off-by:
Andrey Smetanin <asmetanin@virtuozzo.com> Reviewed-by:
Roman Kagan <rkagan@virtuozzo.com> CC: Gleb Natapov <gleb@kernel.org> CC: Paolo Bonzini <pbonzini@redhat.com> CC: Joerg Roedel <joro@8bytes.org> CC: "K. Y. Srinivasan" <kys@microsoft.com> CC: Haiyang Zhang <haiyangz@microsoft.com> CC: Roman Kagan <rkagan@virtuozzo.com> CC: Denis V. Lunev <den@openvz.org> CC: qemu-devel@nongnu.org [Change name, Andrey used HV_X64_HCALL_NOTIFY_LONG_SPIN_WAIT. - Paolo] Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> (back ported from commit 8ed6d767) Signed-off-by:
-
Vitaly Kuznetsov authored
BugLink: http://bugs.launchpad.net/bugs/1583357 Commit c0eb4540 ("hv_netvsc: Don't ask for additional head room in the skb") got rid of needed_headroom setting for the driver. With the change I hit the following issue trying to use ptkgen module: [ 57.522021] kernel BUG at net/core/skbuff.c:1128! [ 57.522021] invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC ... [ 58.721068] Call Trace: [ 58.721068] [<ffffffffa0144e86>] netvsc_start_xmit+0x4c6/0x8e0 [hv_netvsc] ... [ 58.721068] [<ffffffffa02f87fc>] ? pktgen_finalize_skb+0x25c/0x2a0 [pktgen] [ 58.721068] [<ffffffff814f5760>] ? __netdev_alloc_skb+0xc0/0x100 [ 58.721068] [<ffffffffa02f9907>] pktgen_thread_worker+0x257/0x1920 [pktgen] Basically, we're calling skb_cow_head(skb, RNDIS_AND_PPI_SIZE) and crash on if (skb_shared(skb)) BUG(); We probably need to restore needed_headroom setting (but shrunk to RNDIS_AND_PPI_SIZE as we don't need more) to request the required headroom space. In theory, it should not give us performance penalty. Signed-off-by:
-
sixiao@microsoft.com authored
BugLink: http://bugs.launchpad.net/bugs/1583357 1. Adding NETIF_F_TSO6 feature flag; 2. Adding NETIF_F_HW_CSUM. NETIF_F_IPV6_CSUM and NETIF_F_IP_CSUM are being deprecated; 3. Cleanup the coding style of flag assignment by using macro. Signed-off-by:
-
sixiao@microsoft.com authored
BugLink: http://bugs.launchpad.net/bugs/1583357 This reverts commit 3814a737. Favor upstream Signed-off-by:
-
K. Y. Srinivasan authored
BugLink: http://bugs.launchpad.net/bugs/1583357 The function hv_ringbuffer_read() is called always on a pre-assigned CPU. Each chnnel is bound to a specific CPU and this function is always called on the CPU the channel is bound. There is no need to acquire the spin lock; get rid of this overhead. Signed-off-by:
-
K. Y. Srinivasan authored
BugLink: http://bugs.launchpad.net/bugs/1583357 This reverts commit ebade2fc. Favor upstream Signed-off-by:
-
K. Y. Srinivasan authored
BugLink: http://bugs.launchpad.net/bugs/1583357 Cleanup vmbus_set_event() by inlining the hypercall to post the event and since the return value of vmbus_set_event() is not checked, make it void. As part of this cleanup, get rid of the function hv_signal_event() as it is only callled from vmbus_set_event(). Signed-off-by:
-
K. Y. Srinivasan authored
BugLink: http://bugs.launchpad.net/bugs/1583357 This reverts commit 1454f3a3. Favor upstream Signed-off-by:
-
K. Y. Srinivasan authored
BugLink: http://bugs.launchpad.net/bugs/1583357 The current code assumes that there is only one target in device lookup. Fix this bug. This will alow us to correctly handle hot reomoval of LUNs. Signed-off-by:
Alex Ng <alexng@microsoft.com> Tested-by:
Vivek Yadav <vyadav@microsoft.com> Reviewed-by:
-
K. Y. Srinivasan authored
BugLink: http://bugs.launchpad.net/bugs/1583357 The default timeout routine used for FC transport is not suitable for FC devices managed by storvsc since FC devices managed by storvsc driver do not have an rport associated with them. Use the time out handler used for SCSI devices for FC devices as well. Signed-off-by:
-
Haiyang Zhang authored
BugLink: http://bugs.launchpad.net/bugs/1583357 Since eliminating send_completion_tid from struct hv_netvsc_packet, we haven't add proper book keeping for the skb of the batched packet. This patch fixes this issue and allows the previous skb is properly freed. Otherwise, a panic may happen. Thanks to Simon Xiao <sixiao@microsoft.com> for bisecting and analysis. Signed-off-by:
-
Vitaly Kuznetsov authored
BugLink: http://bugs.launchpad.net/bugs/1583357 Recent changes to 'struct flow_keys' (e.g commit d34af823 ("net: Add VLAN ID to flow_keys")) introduced a performance regression in netvsc driver. Is problem is, however, not the above mentioned commit but the fact that netvsc_set_hash() function did some assumptions on the struct flow_keys data layout and this is wrong. Get rid of netvsc_set_hash() by switching to skb_get_hash(). This change will also imply switching to Jenkins hash from the currently used Toeplitz but it seems there is no good excuse for Toeplitz to stay. Signed-off-by:
-
Tim Gardner authored
BugLink: http://bugs.launchpad.net/bugs/1583357 This reverts commit 9e3d2790. Favor upstream Signed-off-by:
-
Dan Carpenter authored
BugLink: http://bugs.launchpad.net/bugs/1583357 The module_param is "storvsc_vcpus_per_sub_channel" so we need to use that for MODULE_PARM_DESC() as well. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
Matthew R. Ochs <mrochs@linux.vnet.ibm.com> Signed-off-by:
-
K. Y. Srinivasan authored
BugLink: http://bugs.launchpad.net/bugs/1583357 On the interrupt path, we repeatedly establish the pointer to the storvsc_device. While the compiler does inline get_in_stor_device() (and other static functions) in the call chain in the interrupt path, the compiler is repeatedly inlining the call to get_in_stor_device() each time it is invoked. The return value of get_in_stor_device() can be cached in the interrupt path since there is higher level serialization in place to ensure correct handling when the module unload races with the processing of an incoming message from the host. Optimize this code path by caching the pointer to storvsc_device and passing it as an argument. Signed-off-by:
Long Li <longli@microsoft.com> Reviewed-by:
Hannes Reinecke <hare@suse.com> Tested-by:
-
K. Y. Srinivasan authored
BugLink: http://bugs.launchpad.net/bugs/1583357 The function storvsc_channel_init() repeatedly interacts with the host to extract various channel properties. Refactor this code to eliminate code repetition. Signed-off-by:
-
K. Y. Srinivasan authored
BugLink: http://bugs.launchpad.net/bugs/1583357 For FC devices managed by this driver, atttach the appropriate transport template. This will allow us to create the appropriate sysfs files for these devices. With this we can publish the wwn for both the port and the node. Signed-off-by:
-
K. Y. Srinivasan authored
BugLink: http://bugs.launchpad.net/bugs/1583357 The hv_fc_wwn_packet is exchanged over vmbus. Make the definition in Linux match the Windows definition. Signed-off-by:
-
Andrey Smetanin authored
BugLink: http://bugs.launchpad.net/bugs/1583357 Per Hyper-V specification (and as required by Hyper-V-aware guests), SynIC provides 4 per-vCPU timers. Each timer is programmed via a pair of MSRs, and signals expiration by delivering a special format message to the configured SynIC message slot and triggering the corresponding synthetic interrupt. Note: as implemented by this patch, all periodic timers are "lazy" (i.e. if the vCPU wasn't scheduled for more than the timer period the timer events are lost), regardless of the corresponding configuration MSR. If deemed necessary, the "catch up" mode (the timer period is shortened until the timer catches up) will be implemented later. Changes v2: * Use remainder to calculate periodic timer expiration time Signed-off-by:
-
Andrey Smetanin authored
BugLink: http://bugs.launchpad.net/bugs/1583357 The SynIC message protocol mandates that the message slot is claimed by atomically setting message type to something other than HVMSG_NONE. If another message is to be delivered while the slot is still busy, message pending flag is asserted to indicate to the guest that the hypervisor wants to be notified when the slot is released. To make sure the protocol works regardless of where the message sources are (kernel or userspace), clear the pending flag on SINT ACK notification, and let the message sources compete for the slot again. Signed-off-by:
-
Andrey Smetanin authored
BugLink: http://bugs.launchpad.net/bugs/1583357 This helper will be used also in Hyper-V SynIC timers implementation. Signed-off-by:
-
Andrey Smetanin authored
BugLink: http://bugs.launchpad.net/bugs/1583357Signed-off-by:
-
Andrey Smetanin authored
BugLink: http://bugs.launchpad.net/bugs/1583357 This rearrangement places functions declarations together according to their functionality, so future additions will be simplier. Signed-off-by:
-
Andrey Smetanin authored
BugLink: http://bugs.launchpad.net/bugs/1583357 A new vcpu exit is introduced to notify the userspace of the changes in Hyper-V SynIC configuration triggered by guest writing to the corresponding MSRs. Changes v4: * exit into userspace only if guest writes into SynIC MSR's Changes v3: * added KVM_EXIT_HYPERV types and structs notes into docs Signed-off-by:
Denis V. Lunev <den@openvz.org> CC: Gleb Natapov <gleb@kernel.org> CC: Paolo Bonzini <pbonzini@redhat.com> CC: Roman Kagan <rkagan@virtuozzo.com> CC: Denis V. Lunev <den@openvz.org> CC: qemu-devel@nongnu.org Signed-off-by:
-
Andrey Smetanin authored
BugLink: http://bugs.launchpad.net/bugs/1583357 SynIC (synthetic interrupt controller) is a lapic extension, which is controlled via MSRs and maintains for each vCPU - 16 synthetic interrupt "lines" (SINT's); each can be configured to trigger a specific interrupt vector optionally with auto-EOI semantics - a message page in the guest memory with 16 256-byte per-SINT message slots - an event flag page in the guest memory with 16 2048-bit per-SINT event flag areas The host triggers a SINT whenever it delivers a new message to the corresponding slot or flips an event flag bit in the corresponding area. The guest informs the host that it can try delivering a message by explicitly asserting EOI in lapic or writing to End-Of-Message (EOM) MSR. The userspace (qemu) triggers interrupts and receives EOM notifications via irqfd with resampler; for that, a GSI is allocated for each configured SINT, and irq_routing api is extended to support GSI-SINT mapping. Changes v4: * added activation of SynIC by vcpu KVM_ENABLE_CAP * added per SynIC active flag * added deactivation of APICv upon SynIC activation Changes v3: * added KVM_CAP_HYPERV_SYNIC and KVM_IRQ_ROUTING_HV_SINT notes into docs Changes v2: * do not use posted interrupts for Hyper-V SynIC AutoEOI vectors * add Hyper-V SynIC vectors into EOI exit bitmap * Hyper-V SyniIC SINT msr write logic simplified Signed-off-by:
-
