]> git.ipfire.org Git - thirdparty/kernel/stable-queue.git/commitdiff
3.13-stable patches
authorGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Thu, 20 Mar 2014 18:38:48 +0000 (11:38 -0700)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Thu, 20 Mar 2014 18:38:48 +0000 (11:38 -0700)
added patches:
i2c-remove-usage-of-orphaned-symbol-of_i2c.patch
ibmveth-fix-endian-issues-with-mac-addresses.patch
ipc-fix-2-bugs-in-msgrcv-msg_copy-implementation.patch
kvm-svm-fix-cr8-intercept-window.patch
pci-enable-intx-in-pci_reenable_device-only-when-msi-msi-x-not-enabled.patch
vmxnet3-fix-building-without-config_pci_msi.patch
vmxnet3-fix-netpoll-race-condition.patch

queue-3.13/i2c-remove-usage-of-orphaned-symbol-of_i2c.patch [new file with mode: 0644]
queue-3.13/ibmveth-fix-endian-issues-with-mac-addresses.patch [new file with mode: 0644]
queue-3.13/ipc-fix-2-bugs-in-msgrcv-msg_copy-implementation.patch [new file with mode: 0644]
queue-3.13/kvm-svm-fix-cr8-intercept-window.patch [new file with mode: 0644]
queue-3.13/pci-enable-intx-in-pci_reenable_device-only-when-msi-msi-x-not-enabled.patch [new file with mode: 0644]
queue-3.13/series
queue-3.13/vmxnet3-fix-building-without-config_pci_msi.patch [new file with mode: 0644]
queue-3.13/vmxnet3-fix-netpoll-race-condition.patch [new file with mode: 0644]

diff --git a/queue-3.13/i2c-remove-usage-of-orphaned-symbol-of_i2c.patch b/queue-3.13/i2c-remove-usage-of-orphaned-symbol-of_i2c.patch
new file mode 100644 (file)
index 0000000..37f6c64
--- /dev/null
@@ -0,0 +1,32 @@
+From 62c19c9d29e65086e5ae76df371ed2e6b23f00cd Mon Sep 17 00:00:00 2001
+From: Richard Weinberger <richard@nod.at>
+Date: Sun, 9 Feb 2014 19:47:40 +0100
+Subject: i2c: Remove usage of orphaned symbol OF_I2C
+
+From: Richard Weinberger <richard@nod.at>
+
+commit 62c19c9d29e65086e5ae76df371ed2e6b23f00cd upstream.
+
+The symbol is an orphan, don't depend on it anymore.
+
+Signed-off-by: Richard Weinberger <richard@nod.at>
+[wsa: enhanced commit message]
+Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
+Fixes: 687b81d083c0 (i2c: move OF helpers into the core)
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/i2c/busses/Kconfig |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/i2c/busses/Kconfig
++++ b/drivers/i2c/busses/Kconfig
+@@ -387,7 +387,7 @@ config I2C_CBUS_GPIO
+ config I2C_CPM
+       tristate "Freescale CPM1 or CPM2 (MPC8xx/826x)"
+-      depends on (CPM1 || CPM2) && OF_I2C
++      depends on CPM1 || CPM2
+       help
+         This supports the use of the I2C interface on Freescale
+         processors with CPM1 or CPM2.
diff --git a/queue-3.13/ibmveth-fix-endian-issues-with-mac-addresses.patch b/queue-3.13/ibmveth-fix-endian-issues-with-mac-addresses.patch
new file mode 100644 (file)
index 0000000..e2c7570
--- /dev/null
@@ -0,0 +1,103 @@
+From d746ca9561440685edb62614d1bcbbc27ff50e66 Mon Sep 17 00:00:00 2001
+From: Anton Blanchard <anton@samba.org>
+Date: Wed, 5 Mar 2014 14:51:37 +1100
+Subject: ibmveth: Fix endian issues with MAC addresses
+
+From: Anton Blanchard <anton@samba.org>
+
+commit d746ca9561440685edb62614d1bcbbc27ff50e66 upstream.
+
+The code to load a MAC address into a u64 for passing to the
+hypervisor via a register is broken on little endian.
+
+Create a helper function called ibmveth_encode_mac_addr
+which does the right thing in both big and little endian.
+
+We were storing the MAC address in a long in struct ibmveth_adapter.
+It's never used so remove it - we don't need another place in the
+driver where we create endian issues with MAC addresses.
+
+Signed-off-by: Anton Blanchard <anton@samba.org>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/ethernet/ibm/ibmveth.c |   25 ++++++++++++++++---------
+ drivers/net/ethernet/ibm/ibmveth.h |    1 -
+ 2 files changed, 16 insertions(+), 10 deletions(-)
+
+--- a/drivers/net/ethernet/ibm/ibmveth.c
++++ b/drivers/net/ethernet/ibm/ibmveth.c
+@@ -523,10 +523,21 @@ retry:
+       return rc;
+ }
++static u64 ibmveth_encode_mac_addr(u8 *mac)
++{
++      int i;
++      u64 encoded = 0;
++
++      for (i = 0; i < ETH_ALEN; i++)
++              encoded = (encoded << 8) | mac[i];
++
++      return encoded;
++}
++
+ static int ibmveth_open(struct net_device *netdev)
+ {
+       struct ibmveth_adapter *adapter = netdev_priv(netdev);
+-      u64 mac_address = 0;
++      u64 mac_address;
+       int rxq_entries = 1;
+       unsigned long lpar_rc;
+       int rc;
+@@ -580,8 +591,7 @@ static int ibmveth_open(struct net_devic
+       adapter->rx_queue.num_slots = rxq_entries;
+       adapter->rx_queue.toggle = 1;
+-      memcpy(&mac_address, netdev->dev_addr, netdev->addr_len);
+-      mac_address = mac_address >> 16;
++      mac_address = ibmveth_encode_mac_addr(netdev->dev_addr);
+       rxq_desc.fields.flags_len = IBMVETH_BUF_VALID |
+                                       adapter->rx_queue.queue_len;
+@@ -1184,8 +1194,8 @@ static void ibmveth_set_multicast_list(s
+               /* add the addresses to the filter table */
+               netdev_for_each_mc_addr(ha, netdev) {
+                       /* add the multicast address to the filter table */
+-                      unsigned long mcast_addr = 0;
+-                      memcpy(((char *)&mcast_addr)+2, ha->addr, ETH_ALEN);
++                      u64 mcast_addr;
++                      mcast_addr = ibmveth_encode_mac_addr(ha->addr);
+                       lpar_rc = h_multicast_ctrl(adapter->vdev->unit_address,
+                                                  IbmVethMcastAddFilter,
+                                                  mcast_addr);
+@@ -1369,9 +1379,6 @@ static int ibmveth_probe(struct vio_dev
+       netif_napi_add(netdev, &adapter->napi, ibmveth_poll, 16);
+-      adapter->mac_addr = 0;
+-      memcpy(&adapter->mac_addr, mac_addr_p, ETH_ALEN);
+-
+       netdev->irq = dev->irq;
+       netdev->netdev_ops = &ibmveth_netdev_ops;
+       netdev->ethtool_ops = &netdev_ethtool_ops;
+@@ -1380,7 +1387,7 @@ static int ibmveth_probe(struct vio_dev
+               NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM;
+       netdev->features |= netdev->hw_features;
+-      memcpy(netdev->dev_addr, &adapter->mac_addr, netdev->addr_len);
++      memcpy(netdev->dev_addr, mac_addr_p, ETH_ALEN);
+       for (i = 0; i < IBMVETH_NUM_BUFF_POOLS; i++) {
+               struct kobject *kobj = &adapter->rx_buff_pool[i].kobj;
+--- a/drivers/net/ethernet/ibm/ibmveth.h
++++ b/drivers/net/ethernet/ibm/ibmveth.h
+@@ -139,7 +139,6 @@ struct ibmveth_adapter {
+     struct napi_struct napi;
+     struct net_device_stats stats;
+     unsigned int mcastFilterSize;
+-    unsigned long mac_addr;
+     void * buffer_list_addr;
+     void * filter_list_addr;
+     dma_addr_t buffer_list_dma;
diff --git a/queue-3.13/ipc-fix-2-bugs-in-msgrcv-msg_copy-implementation.patch b/queue-3.13/ipc-fix-2-bugs-in-msgrcv-msg_copy-implementation.patch
new file mode 100644 (file)
index 0000000..162f43b
--- /dev/null
@@ -0,0 +1,120 @@
+From 4f87dac386cc43d5525da7a939d4b4e7edbea22c Mon Sep 17 00:00:00 2001
+From: Michael Kerrisk <mtk.manpages@gmail.com>
+Date: Mon, 10 Mar 2014 14:46:07 +0100
+Subject: ipc: Fix 2 bugs in msgrcv() MSG_COPY implementation
+
+From: Michael Kerrisk <mtk.manpages@gmail.com>
+
+commit 4f87dac386cc43d5525da7a939d4b4e7edbea22c upstream.
+
+While testing and documenting the msgrcv() MSG_COPY flag that Stanislav
+Kinsbursky added in commit 4a674f34ba04 ("ipc: introduce message queue
+copy feature" => kernel 3.8), I discovered a couple of bugs in the
+implementation.  The two bugs concern MSG_COPY interactions with other
+msgrcv() flags, namely:
+
+ (A) MSG_COPY + MSG_EXCEPT
+ (B) MSG_COPY + !IPC_NOWAIT
+
+The bugs are distinct (and the fix for the first one is obvious),
+however my fix for both is a single-line patch, which is why I'm
+combining them in a single mail, rather than writing two mails+patches.
+
+ ===== (A) MSG_COPY + MSG_EXCEPT =====
+
+With the addition of the MSG_COPY flag, there are now two msgrcv()
+flags--MSG_COPY and MSG_EXCEPT--that modify the meaning of the 'msgtyp'
+argument in unrelated ways.  Specifying both in the same call is a
+logical error that is currently permitted, with the effect that MSG_COPY
+has priority and MSG_EXCEPT is ignored.  The call should give an error
+if both flags are specified.  The patch below implements that behavior.
+
+ ===== (B) (B) MSG_COPY + !IPC_NOWAIT =====
+
+The test code that was submitted in commit 3a665531a3b7 ("selftests: IPC
+message queue copy feature test") shows MSG_COPY being used in
+conjunction with IPC_NOWAIT.  In other words, if there is no message at
+the position 'msgtyp'.  return immediately with the error in ENOMSG.
+
+What was not (fully) tested is the behavior if MSG_COPY is specified
+*without* IPC_NOWAIT, and there is an odd behavior.  If the queue
+contains less than 'msgtyp' messages, then the call blocks until the
+next message is written to the queue.  At that point, the msgrcv() call
+returns a copy of the newly added message, regardless of whether that
+message is at the ordinal position 'msgtyp'.  This is clearly bogus, and
+problematic for applications that might want to make use of the MSG_COPY
+flag.
+
+I considered the following possible solutions to this problem:
+
+ (1) Force the call to block until a message *does* appear at the
+     position 'msgtyp'.
+
+ (2) If the MSG_COPY flag is specified, the kernel should implicitly add
+     IPC_NOWAIT, so that the call fails with ENOMSG for this case.
+
+ (3) If the MSG_COPY flag is specified, but IPC_NOWAIT is not, generate
+     an error (probably, EINVAL is the right one).
+
+I do not know if any application would really want to have the
+functionality of solution (1), especially since an application can
+determine in advance the number of messages in the queue using msgctl()
+IPC_STAT.  Obviously, this solution would be the most work to implement.
+
+Solution (2) would have the effect of silently fixing any applications
+that tried to employ broken behavior.  However, it would mean that if we
+later decided to implement solution (1), then user-space could not
+easily detect what the kernel supports (but, since I'm somewhat doubtful
+that solution (1) is needed, I'm not sure that this is much of a
+problem).
+
+Solution (3) would have the effect of informing broken applications that
+they are doing something broken.  The downside is that this would cause
+a ABI breakage for any applications that are currently employing the
+broken behavior.  However:
+
+a) Those applications are almost certainly not getting the results they
+   expect.
+b) Possibly, those applications don't even exist, because MSG_COPY is
+   currently hidden behind CONFIG_CHECKPOINT_RESTORE.
+
+The upside of solution (3) is that if we later decided to implement
+solution (1), user-space could determine what the kernel supports, via
+the error return.
+
+In my view, solution (3) is mildly preferable to solution (2), and
+solution (1) could still be done later if anyone really cares.  The
+patch below implements solution (3).
+
+PS.  For anyone out there still listening, it's the usual story:
+documenting an API (and the thinking about, and the testing of the API,
+that documentation entails) is the one of the single best ways of
+finding bugs in the API, as I've learned from a lot of experience.  Best
+to do that documentation before releasing the API.
+
+Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
+Acked-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
+Cc: Stanislav Kinsbursky <skinsbursky@parallels.com>
+Cc: Serge Hallyn <serge.hallyn@canonical.com>
+Cc: "Eric W. Biederman" <ebiederm@xmission.com>
+Cc: Pavel Emelyanov <xemul@parallels.com>
+Cc: Al Viro <viro@zeniv.linux.org.uk>
+Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ ipc/msg.c |    2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/ipc/msg.c
++++ b/ipc/msg.c
+@@ -885,6 +885,8 @@ long do_msgrcv(int msqid, void __user *b
+               return -EINVAL;
+       if (msgflg & MSG_COPY) {
++              if ((msgflg & MSG_EXCEPT) || !(msgflg & IPC_NOWAIT))
++                      return -EINVAL;
+               copy = prepare_copy(buf, min_t(size_t, bufsz, ns->msg_ctlmax));
+               if (IS_ERR(copy))
+                       return PTR_ERR(copy);
diff --git a/queue-3.13/kvm-svm-fix-cr8-intercept-window.patch b/queue-3.13/kvm-svm-fix-cr8-intercept-window.patch
new file mode 100644 (file)
index 0000000..ebbbf16
--- /dev/null
@@ -0,0 +1,52 @@
+From 596f3142d2b7be307a1652d59e7b93adab918437 Mon Sep 17 00:00:00 2001
+From: Radim Krčmář <rkrcmar@redhat.com>
+Date: Tue, 11 Mar 2014 19:11:18 +0100
+Subject: KVM: SVM: fix cr8 intercept window
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Radim Krčmář <rkrcmar@redhat.com>
+
+commit 596f3142d2b7be307a1652d59e7b93adab918437 upstream.
+
+We always disable cr8 intercept in its handler, but only re-enable it
+if handling KVM_REQ_EVENT, so there can be a window where we do not
+intercept cr8 writes, which allows an interrupt to disrupt a higher
+priority task.
+
+Fix this by disabling intercepts in the same function that re-enables
+them when needed. This fixes BSOD in Windows 2008.
+
+Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
+Reviewed-by: Marcelo Tosatti <mtosatti@redhat.com>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kvm/svm.c |    6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/arch/x86/kvm/svm.c
++++ b/arch/x86/kvm/svm.c
+@@ -2989,10 +2989,8 @@ static int cr8_write_interception(struct
+       u8 cr8_prev = kvm_get_cr8(&svm->vcpu);
+       /* instruction emulation calls kvm_set_cr8() */
+       r = cr_interception(svm);
+-      if (irqchip_in_kernel(svm->vcpu.kvm)) {
+-              clr_cr_intercept(svm, INTERCEPT_CR8_WRITE);
++      if (irqchip_in_kernel(svm->vcpu.kvm))
+               return r;
+-      }
+       if (cr8_prev <= kvm_get_cr8(&svm->vcpu))
+               return r;
+       kvm_run->exit_reason = KVM_EXIT_SET_TPR;
+@@ -3554,6 +3552,8 @@ static void update_cr8_intercept(struct
+       if (is_guest_mode(vcpu) && (vcpu->arch.hflags & HF_VINTR_MASK))
+               return;
++      clr_cr_intercept(svm, INTERCEPT_CR8_WRITE);
++
+       if (irr == -1)
+               return;
diff --git a/queue-3.13/pci-enable-intx-in-pci_reenable_device-only-when-msi-msi-x-not-enabled.patch b/queue-3.13/pci-enable-intx-in-pci_reenable_device-only-when-msi-msi-x-not-enabled.patch
new file mode 100644 (file)
index 0000000..546bb79
--- /dev/null
@@ -0,0 +1,47 @@
+From 3cdeb713dc66057b50682048c151eae07b186c42 Mon Sep 17 00:00:00 2001
+From: Bjorn Helgaas <bhelgaas@google.com>
+Date: Tue, 11 Mar 2014 14:22:19 -0600
+Subject: PCI: Enable INTx in pci_reenable_device() only when MSI/MSI-X not enabled
+
+From: Bjorn Helgaas <bhelgaas@google.com>
+
+commit 3cdeb713dc66057b50682048c151eae07b186c42 upstream.
+
+Andreas reported that after 1f42db786b14 ("PCI: Enable INTx if BIOS left
+them disabled"), pciehp surprise removal stopped working.
+
+This happens because pci_reenable_device() on the hotplug bridge (used in
+the pciehp_configure_device() path) clears the Interrupt Disable bit, which
+apparently breaks the bridge's MSI hotplug event reporting.
+
+Previously we cleared the Interrupt Disable bit in do_pci_enable_device(),
+which is used by both pci_enable_device() and pci_reenable_device().  But
+we use pci_reenable_device() after the driver may have enabled MSI or
+MSI-X, and we *set* Interrupt Disable as part of enabling MSI/MSI-X.
+
+This patch clears Interrupt Disable only when MSI/MSI-X has not been
+enabled.
+
+Fixes: 1f42db786b14 PCI: Enable INTx if BIOS left them disabled
+Link: https://bugzilla.kernel.org/show_bug.cgi?id=71691
+Reported-and-tested-by: Andreas Noever <andreas.noever@gmail.com>
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+CC: Sarah Sharp <sarah.a.sharp@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/pci/pci.c |    3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/pci/pci.c
++++ b/drivers/pci/pci.c
+@@ -1131,6 +1131,9 @@ static int do_pci_enable_device(struct p
+               return err;
+       pci_fixup_device(pci_fixup_enable, dev);
++      if (dev->msi_enabled || dev->msix_enabled)
++              return 0;
++
+       pci_read_config_byte(dev, PCI_INTERRUPT_PIN, &pin);
+       if (pin) {
+               pci_read_config_word(dev, PCI_COMMAND, &cmd);
index 8af63fa67768a84169fdf6800d67f2d2c97c40ef..1e636d42f017b8138eb2201fe7e7aded343c4a76 100644 (file)
@@ -110,3 +110,10 @@ drm-radeon-si-fix-typo-in-dpm-sq-ramping-setup.patch
 asoc-pcm-free-path-list-before-exiting-from-error-conditions.patch
 asoc-88pm860-fix-io-setup.patch
 asoc-si476x-fix-io-setup.patch
+i2c-remove-usage-of-orphaned-symbol-of_i2c.patch
+ipc-fix-2-bugs-in-msgrcv-msg_copy-implementation.patch
+kvm-svm-fix-cr8-intercept-window.patch
+ibmveth-fix-endian-issues-with-mac-addresses.patch
+pci-enable-intx-in-pci_reenable_device-only-when-msi-msi-x-not-enabled.patch
+vmxnet3-fix-netpoll-race-condition.patch
+vmxnet3-fix-building-without-config_pci_msi.patch
diff --git a/queue-3.13/vmxnet3-fix-building-without-config_pci_msi.patch b/queue-3.13/vmxnet3-fix-building-without-config_pci_msi.patch
new file mode 100644 (file)
index 0000000..3dc8f3c
--- /dev/null
@@ -0,0 +1,51 @@
+From 0a8d8c446b5429d15ff2d48f46e00d8a08552303 Mon Sep 17 00:00:00 2001
+From: Arnd Bergmann <arnd@arndb.de>
+Date: Thu, 13 Mar 2014 10:44:34 +0100
+Subject: vmxnet3: fix building without CONFIG_PCI_MSI
+
+From: Arnd Bergmann <arnd@arndb.de>
+
+commit 0a8d8c446b5429d15ff2d48f46e00d8a08552303 upstream.
+
+Since commit d25f06ea466e "vmxnet3: fix netpoll race condition",
+the vmxnet3 driver fails to build when CONFIG_PCI_MSI is disabled,
+because it unconditionally references the vmxnet3_msix_rx()
+function.
+
+To fix this, use the same #ifdef in the caller that exists around
+the function definition.
+
+Signed-off-by: Arnd Bergmann <arnd@arndb.de>
+Cc: Neil Horman <nhorman@tuxdriver.com>
+Cc: Shreyas Bhatewara <sbhatewara@vmware.com>
+Cc: "VMware, Inc." <pv-drivers@vmware.com>
+Cc: "David S. Miller" <davem@davemloft.net>
+Acked-by: Neil Horman <nhorman@tuxdriver.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/vmxnet3/vmxnet3_drv.c |    7 +++++--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+--- a/drivers/net/vmxnet3/vmxnet3_drv.c
++++ b/drivers/net/vmxnet3/vmxnet3_drv.c
+@@ -1759,13 +1759,16 @@ static void
+ vmxnet3_netpoll(struct net_device *netdev)
+ {
+       struct vmxnet3_adapter *adapter = netdev_priv(netdev);
+-      int i;
+       switch (adapter->intr.type) {
+-      case VMXNET3_IT_MSIX:
++#ifdef CONFIG_PCI_MSI
++      case VMXNET3_IT_MSIX: {
++              int i;
+               for (i = 0; i < adapter->num_rx_queues; i++)
+                       vmxnet3_msix_rx(0, &adapter->rx_queue[i]);
+               break;
++      }
++#endif
+       case VMXNET3_IT_MSI:
+       default:
+               vmxnet3_intr(0, adapter->netdev);
diff --git a/queue-3.13/vmxnet3-fix-netpoll-race-condition.patch b/queue-3.13/vmxnet3-fix-netpoll-race-condition.patch
new file mode 100644 (file)
index 0000000..53381d1
--- /dev/null
@@ -0,0 +1,78 @@
+From d25f06ea466ea521b563b76661180b4e44714ae6 Mon Sep 17 00:00:00 2001
+From: Neil Horman <nhorman@tuxdriver.com>
+Date: Mon, 10 Mar 2014 06:55:55 -0400
+Subject: vmxnet3: fix netpoll race condition
+
+From: Neil Horman <nhorman@tuxdriver.com>
+
+commit d25f06ea466ea521b563b76661180b4e44714ae6 upstream.
+
+vmxnet3's netpoll driver is incorrectly coded.  It directly calls
+vmxnet3_do_poll, which is the driver internal napi poll routine.  As the netpoll
+controller method doesn't block real napi polls in any way, there is a potential
+for race conditions in which the netpoll controller method and the napi poll
+method run concurrently.  The result is data corruption causing panics such as this
+one recently observed:
+PID: 1371   TASK: ffff88023762caa0  CPU: 1   COMMAND: "rs:main Q:Reg"
+ #0 [ffff88023abd5780] machine_kexec at ffffffff81038f3b
+ #1 [ffff88023abd57e0] crash_kexec at ffffffff810c5d92
+ #2 [ffff88023abd58b0] oops_end at ffffffff8152b570
+ #3 [ffff88023abd58e0] die at ffffffff81010e0b
+ #4 [ffff88023abd5910] do_trap at ffffffff8152add4
+ #5 [ffff88023abd5970] do_invalid_op at ffffffff8100cf95
+ #6 [ffff88023abd5a10] invalid_op at ffffffff8100bf9b
+    [exception RIP: vmxnet3_rq_rx_complete+1968]
+    RIP: ffffffffa00f1e80  RSP: ffff88023abd5ac8  RFLAGS: 00010086
+    RAX: 0000000000000000  RBX: ffff88023b5dcee0  RCX: 00000000000000c0
+    RDX: 0000000000000000  RSI: 00000000000005f2  RDI: ffff88023b5dcee0
+    RBP: ffff88023abd5b48   R8: 0000000000000000   R9: ffff88023a3b6048
+    R10: 0000000000000000  R11: 0000000000000002  R12: ffff8802398d4cd8
+    R13: ffff88023af35140  R14: ffff88023b60c890  R15: 0000000000000000
+    ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
+ #7 [ffff88023abd5b50] vmxnet3_do_poll at ffffffffa00f204a [vmxnet3]
+ #8 [ffff88023abd5b80] vmxnet3_netpoll at ffffffffa00f209c [vmxnet3]
+ #9 [ffff88023abd5ba0] netpoll_poll_dev at ffffffff81472bb7
+
+The fix is to do as other drivers do, and have the poll controller call the top
+half interrupt handler, which schedules a napi poll properly to recieve frames
+
+Tested by myself, successfully.
+
+Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
+CC: Shreyas Bhatewara <sbhatewara@vmware.com>
+CC: "VMware, Inc." <pv-drivers@vmware.com>
+CC: "David S. Miller" <davem@davemloft.net>
+Reviewed-by: Shreyas N Bhatewara <sbhatewara@vmware.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/vmxnet3/vmxnet3_drv.c |   16 +++++++++++-----
+ 1 file changed, 11 insertions(+), 5 deletions(-)
+
+--- a/drivers/net/vmxnet3/vmxnet3_drv.c
++++ b/drivers/net/vmxnet3/vmxnet3_drv.c
+@@ -1759,12 +1759,18 @@ static void
+ vmxnet3_netpoll(struct net_device *netdev)
+ {
+       struct vmxnet3_adapter *adapter = netdev_priv(netdev);
++      int i;
+-      if (adapter->intr.mask_mode == VMXNET3_IMM_ACTIVE)
+-              vmxnet3_disable_all_intrs(adapter);
+-
+-      vmxnet3_do_poll(adapter, adapter->rx_queue[0].rx_ring[0].size);
+-      vmxnet3_enable_all_intrs(adapter);
++      switch (adapter->intr.type) {
++      case VMXNET3_IT_MSIX:
++              for (i = 0; i < adapter->num_rx_queues; i++)
++                      vmxnet3_msix_rx(0, &adapter->rx_queue[i]);
++              break;
++      case VMXNET3_IT_MSI:
++      default:
++              vmxnet3_intr(0, adapter->netdev);
++              break;
++      }
+ }
+ #endif        /* CONFIG_NET_POLL_CONTROLLER */