From: Greg Kroah-Hartman Date: Thu, 3 Jun 2010 23:47:25 +0000 (-0700) Subject: .32 patches X-Git-Tag: v2.6.31.14~40 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=240fb9737a7ebb5ed7c5039e564b46ce881a6a7e;p=thirdparty%2Fkernel%2Fstable-queue.git .32 patches --- diff --git a/queue-2.6.32/can-fix-sja1000-command-register-writes-on-smp-systems.patch b/queue-2.6.32/can-fix-sja1000-command-register-writes-on-smp-systems.patch new file mode 100644 index 00000000000..6070634bc7b --- /dev/null +++ b/queue-2.6.32/can-fix-sja1000-command-register-writes-on-smp-systems.patch @@ -0,0 +1,96 @@ +From 57c8a456640fa3ca777652f11f2db4179a3e66b6 Mon Sep 17 00:00:00 2001 +From: Oliver Hartkopp +Date: Tue, 18 May 2010 14:03:10 -0700 +Subject: can: Fix SJA1000 command register writes on SMP systems + +From: Oliver Hartkopp + +commit 57c8a456640fa3ca777652f11f2db4179a3e66b6 upstream. + +The SJA1000 command register is concurrently written in the rx-path to free +the receive buffer _and_ in the tx-path to start the transmission. + +The SJA1000 data sheet, 6.4.4 COMMAND REGISTER (CMR) states: +"Between two commands at least one internal clock cycle is needed in +order to proceed. The internal clock is half of the external oscillator +frequency." + +On SMP systems the current implementation leads to a write stall in the +tx-path, which can be solved by adding some general locking and some time +to settle the write_reg() operation for the command register. + +Thanks to Klaus Hitschler for the original fix and detailed problem +description. + +This patch applies on net-2.6 and (with some offsets) on net-next-2.6 . + +Signed-off-by: Oliver Hartkopp +Acked-by: Wolfgang Grandegger +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/net/can/sja1000/sja1000.c | 20 +++++++++++++++++--- + drivers/net/can/sja1000/sja1000.h | 1 + + 2 files changed, 18 insertions(+), 3 deletions(-) + +--- a/drivers/net/can/sja1000/sja1000.c ++++ b/drivers/net/can/sja1000/sja1000.c +@@ -84,6 +84,20 @@ static struct can_bittiming_const sja100 + .brp_inc = 1, + }; + ++static void sja1000_write_cmdreg(struct sja1000_priv *priv, u8 val) ++{ ++ unsigned long flags; ++ ++ /* ++ * The command register needs some locking and time to settle ++ * the write_reg() operation - especially on SMP systems. ++ */ ++ spin_lock_irqsave(&priv->cmdreg_lock, flags); ++ priv->write_reg(priv, REG_CMR, val); ++ priv->read_reg(priv, REG_SR); ++ spin_unlock_irqrestore(&priv->cmdreg_lock, flags); ++} ++ + static int sja1000_probe_chip(struct net_device *dev) + { + struct sja1000_priv *priv = netdev_priv(dev); +@@ -279,7 +293,7 @@ static netdev_tx_t sja1000_start_xmit(st + + can_put_echo_skb(skb, dev, 0); + +- priv->write_reg(priv, REG_CMR, CMD_TR); ++ sja1000_write_cmdreg(priv, CMD_TR); + + return NETDEV_TX_OK; + } +@@ -334,7 +348,7 @@ static void sja1000_rx(struct net_device + cf->data[i++] = 0; + + /* release receive buffer */ +- priv->write_reg(priv, REG_CMR, CMD_RRB); ++ sja1000_write_cmdreg(priv, CMD_RRB); + + netif_rx(skb); + +@@ -368,7 +382,7 @@ static int sja1000_err(struct net_device + cf->data[1] = CAN_ERR_CRTL_RX_OVERFLOW; + stats->rx_over_errors++; + stats->rx_errors++; +- priv->write_reg(priv, REG_CMR, CMD_CDO); /* clear bit */ ++ sja1000_write_cmdreg(priv, CMD_CDO); /* clear bit */ + } + + if (isrc & IRQ_EI) { +--- a/drivers/net/can/sja1000/sja1000.h ++++ b/drivers/net/can/sja1000/sja1000.h +@@ -165,6 +165,7 @@ struct sja1000_priv { + + void __iomem *reg_base; /* ioremap'ed address to registers */ + unsigned long irq_flags; /* for request_irq() */ ++ spinlock_t cmdreg_lock; /* lock for concurrent cmd register writes */ + + u16 flags; /* custom mode flags */ + u8 ocr; /* output control register */ diff --git a/queue-2.6.32/drivers-base-cpu.c-fix-the-output-from-sys-devices-system-cpu-offline.patch b/queue-2.6.32/drivers-base-cpu.c-fix-the-output-from-sys-devices-system-cpu-offline.patch new file mode 100644 index 00000000000..88b0880119f --- /dev/null +++ b/queue-2.6.32/drivers-base-cpu.c-fix-the-output-from-sys-devices-system-cpu-offline.patch @@ -0,0 +1,34 @@ +From cdc6e3d3968052cebb2f2ddcd742bff29fbd1a90 Mon Sep 17 00:00:00 2001 +From: Jan Beulich +Date: Tue, 27 Apr 2010 14:01:20 -0700 +Subject: drivers/base/cpu.c: fix the output from /sys/devices/system/cpu/offline + +From: Jan Beulich + +commit cdc6e3d3968052cebb2f2ddcd742bff29fbd1a90 upstream. + +Without CONFIG_CPUMASK_OFFSTACK, simply inverting cpu_online_mask leads +to CPUs beyond nr_cpu_ids to be displayed twice and CPUs not even +possible to be displayed as offline. + +Signed-off-by: Jan Beulich +Cc: Andi Kleen +Cc: Stephen Rothwell +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/base/cpu.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/base/cpu.c ++++ b/drivers/base/cpu.c +@@ -149,7 +149,7 @@ static ssize_t print_cpus_offline(struct + /* display offline cpus < nr_cpu_ids */ + if (!alloc_cpumask_var(&offline, GFP_KERNEL)) + return -ENOMEM; +- cpumask_complement(offline, cpu_online_mask); ++ cpumask_andnot(offline, cpu_possible_mask, cpu_online_mask); + n = cpulist_scnprintf(buf, len, offline); + free_cpumask_var(offline); + diff --git a/queue-2.6.32/drm-i915-reject-bind_to_gtt-early-if-object-aperture.patch b/queue-2.6.32/drm-i915-reject-bind_to_gtt-early-if-object-aperture.patch new file mode 100644 index 00000000000..5b73de50fdb --- /dev/null +++ b/queue-2.6.32/drm-i915-reject-bind_to_gtt-early-if-object-aperture.patch @@ -0,0 +1,39 @@ +From 654fc6073f68efa3b6c466825749e73e7fbb92cd Mon Sep 17 00:00:00 2001 +From: Chris Wilson +Date: Thu, 27 May 2010 13:18:21 +0100 +Subject: drm/i915: Reject bind_to_gtt() early if object > aperture + +From: Chris Wilson + +commit 654fc6073f68efa3b6c466825749e73e7fbb92cd upstream. + +If the object is bigger than the entire aperture, reject it early +before evicting everything in a vain attempt to find space. + +v2: Use E2BIG as suggested by Owain G. Ainsworth. + +Signed-off-by: Chris Wilson +Signed-off-by: Eric Anholt +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/i915/i915_gem.c | 8 ++++++++ + 1 file changed, 8 insertions(+) + +--- a/drivers/gpu/drm/i915/i915_gem.c ++++ b/drivers/gpu/drm/i915/i915_gem.c +@@ -2615,6 +2615,14 @@ i915_gem_object_bind_to_gtt(struct drm_g + return -EINVAL; + } + ++ /* If the object is bigger than the entire aperture, reject it early ++ * before evicting everything in a vain attempt to find space. ++ */ ++ if (obj->size > dev->gtt_total) { ++ DRM_ERROR("Attempting to bind an object larger than the aperture\n"); ++ return -E2BIG; ++ } ++ + search_free: + free_space = drm_mm_search_free(&dev_priv->mm.gtt_space, + obj->size, alignment, 0); diff --git a/queue-2.6.32/mac80211-fix-robust-management-frame-handling-mfp.patch b/queue-2.6.32/mac80211-fix-robust-management-frame-handling-mfp.patch new file mode 100644 index 00000000000..7ed12cc3d86 --- /dev/null +++ b/queue-2.6.32/mac80211-fix-robust-management-frame-handling-mfp.patch @@ -0,0 +1,35 @@ +From d211e90e28a074447584729018a39910d691d1a8 Mon Sep 17 00:00:00 2001 +From: Jouni Malinen +Date: Sun, 28 Mar 2010 22:29:52 -0700 +Subject: mac80211: Fix robust management frame handling (MFP) + +From: Jouni Malinen + +commit d211e90e28a074447584729018a39910d691d1a8 upstream. + +Commit e34e09401ee9888dd662b2fca5d607794a56daf2 incorrectly removed +use of ieee80211_has_protected() from the management frame case and in +practice, made this validation drop all Action frames when MFP is +enabled. This should have only been done for frames with Protected +field set to zero. + +Signed-off-by: Jouni Malinen +Signed-off-by: John W. Linville +Signed-off-by: Greg Kroah-Hartman + +--- + net/mac80211/rx.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/net/mac80211/rx.c ++++ b/net/mac80211/rx.c +@@ -1220,7 +1220,8 @@ ieee80211_drop_unencrypted(struct ieee80 + (rx->key || rx->sdata->drop_unencrypted))) + return -EACCES; + if (rx->sta && test_sta_flags(rx->sta, WLAN_STA_MFP)) { +- if (unlikely(ieee80211_is_unicast_robust_mgmt_frame(rx->skb) && ++ if (unlikely(!ieee80211_has_protected(fc) && ++ ieee80211_is_unicast_robust_mgmt_frame(rx->skb) && + rx->key)) + return -EACCES; + /* BIP does not use Protected field, so need to check MMIE */ diff --git a/queue-2.6.32/mac80211-fix-rts-threshold-check.patch b/queue-2.6.32/mac80211-fix-rts-threshold-check.patch new file mode 100644 index 00000000000..a175283e1f9 --- /dev/null +++ b/queue-2.6.32/mac80211-fix-rts-threshold-check.patch @@ -0,0 +1,52 @@ +From a2c40249a36d0b4d76d1caf6bf806e4ae5b06e8a Mon Sep 17 00:00:00 2001 +From: Shanyu Zhao +Date: Tue, 27 Apr 2010 11:15:12 -0700 +Subject: mac80211: fix rts threshold check + +From: Shanyu Zhao + +commit a2c40249a36d0b4d76d1caf6bf806e4ae5b06e8a upstream. + +Currently whenever rts thresold is set, every packet will use RTS +protection no matter its size exceeds the threshold or not. This is +due to a bug in the rts threshold check. + if (len > tx->local->hw.wiphy->rts_threshold) { + txrc.rts = rts = true; + } +Basically it is comparing an int (len) and a u32 (rts_threshold), +and the variable len is assigned as: + len = min_t(int, tx->skb->len + FCS_LEN, + tx->local->hw.wiphy->frag_threshold); +However, when frag_threshold is "-1", len is always "-1", which is +0xffffffff therefore rts is always set to true. + +Signed-off-by: Shanyu Zhao +Reviewed-by: Johannes Berg +Signed-off-by: John W. Linville +Signed-off-by: Greg Kroah-Hartman + +--- + net/mac80211/tx.c | 5 +++-- + 1 file changed, 3 insertions(+), 2 deletions(-) + +--- a/net/mac80211/tx.c ++++ b/net/mac80211/tx.c +@@ -496,7 +496,8 @@ ieee80211_tx_h_rate_ctrl(struct ieee8021 + struct ieee80211_hdr *hdr = (void *)tx->skb->data; + struct ieee80211_supported_band *sband; + struct ieee80211_rate *rate; +- int i, len; ++ int i; ++ u32 len; + bool inval = false, rts = false, short_preamble = false; + struct ieee80211_tx_rate_control txrc; + u32 sta_flags; +@@ -505,7 +506,7 @@ ieee80211_tx_h_rate_ctrl(struct ieee8021 + + sband = tx->local->hw.wiphy->bands[tx->channel->band]; + +- len = min_t(int, tx->skb->len + FCS_LEN, ++ len = min_t(u32, tx->skb->len + FCS_LEN, + tx->local->hw.wiphy->frag_threshold); + + /* set up the tx rate control struct we give the RC algo */ diff --git a/queue-2.6.32/mac80211-give-warning-if-building-w-out-rate-ctrl-algorithm.patch b/queue-2.6.32/mac80211-give-warning-if-building-w-out-rate-ctrl-algorithm.patch new file mode 100644 index 00000000000..1c3ffc16f27 --- /dev/null +++ b/queue-2.6.32/mac80211-give-warning-if-building-w-out-rate-ctrl-algorithm.patch @@ -0,0 +1,68 @@ +From c2ef355bf3ef0b8006b96128726684fba47ac928 Mon Sep 17 00:00:00 2001 +From: Andres Salomon +Date: Thu, 25 Feb 2010 19:18:47 -0500 +Subject: mac80211: give warning if building w/out rate ctrl algorithm + +From: Andres Salomon + +commit c2ef355bf3ef0b8006b96128726684fba47ac928 upstream. + +I discovered that if EMBEDDED=y, one can accidentally build a mac80211 stack +and drivers w/ no rate control algorithm. For drivers like RTL8187 that don't +supply their own RC algorithms, this will cause ieee80211_register_hw to +fail (making the driver unusable). + +This will tell kconfig to provide a warning if no rate control algorithms +have been selected. That'll at least warn the user; users that know that +their drivers supply a rate control algorithm can safely ignore the +warning, and those who don't know (or who expect to be using multiple +drivers) can select a default RC algorithm. + +Signed-off-by: Andres Salomon +Signed-off-by: John W. Linville +Signed-off-by: Greg Kroah-Hartman + +--- + net/mac80211/Kconfig | 9 +++++++++ + 1 file changed, 9 insertions(+) + +--- a/net/mac80211/Kconfig ++++ b/net/mac80211/Kconfig +@@ -15,8 +15,12 @@ comment "CFG80211 needs to be enabled fo + + if MAC80211 != n + ++config MAC80211_HAS_RC ++ def_bool n ++ + config MAC80211_RC_PID + bool "PID controller based rate control algorithm" if EMBEDDED ++ select MAC80211_HAS_RC + ---help--- + This option enables a TX rate control algorithm for + mac80211 that uses a PID controller to select the TX +@@ -24,12 +28,14 @@ config MAC80211_RC_PID + + config MAC80211_RC_MINSTREL + bool "Minstrel" if EMBEDDED ++ select MAC80211_HAS_RC + default y + ---help--- + This option enables the 'minstrel' TX rate control algorithm + + choice + prompt "Default rate control algorithm" ++ depends on MAC80211_HAS_RC + default MAC80211_RC_DEFAULT_MINSTREL + ---help--- + This option selects the default rate control algorithm +@@ -62,6 +68,9 @@ config MAC80211_RC_DEFAULT + + endif + ++comment "Some wireless drivers require a rate control algorithm" ++ depends on MAC80211_HAS_RC=n ++ + config MAC80211_MESH + bool "Enable mac80211 mesh networking (pre-802.11s) support" + depends on MAC80211 && EXPERIMENTAL diff --git a/queue-2.6.32/pci-disable-msi-for-mcp55-on-p5n32-e-sli.patch b/queue-2.6.32/pci-disable-msi-for-mcp55-on-p5n32-e-sli.patch new file mode 100644 index 00000000000..c84a2a44551 --- /dev/null +++ b/queue-2.6.32/pci-disable-msi-for-mcp55-on-p5n32-e-sli.patch @@ -0,0 +1,44 @@ +From e4146bb9088c01c8b6e82be11f0c371f8aff023c Mon Sep 17 00:00:00 2001 +From: Ben Hutchings +Date: Sun, 16 May 2010 02:28:49 +0100 +Subject: PCI: Disable MSI for MCP55 on P5N32-E SLI + +From: Ben Hutchings + +commit e4146bb9088c01c8b6e82be11f0c371f8aff023c upstream. + +As reported in , MSI appears to be +broken for this on-board device. We already have a quirk for the +P5N32-SLI Premium; extend it to cover both variants of the board. + +Reported-by: Romain DEGEZ +Signed-off-by: Ben Hutchings +Signed-off-by: Jesse Barnes +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/pci/quirks.c | 7 ++++--- + 1 file changed, 4 insertions(+), 3 deletions(-) + +--- a/drivers/pci/quirks.c ++++ b/drivers/pci/quirks.c +@@ -2185,15 +2185,16 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_S + DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_8132_BRIDGE, + ht_enable_msi_mapping); + +-/* The P5N32-SLI Premium motherboard from Asus has a problem with msi ++/* The P5N32-SLI motherboards from Asus have a problem with msi + * for the MCP55 NIC. It is not yet determined whether the msi problem + * also affects other devices. As for now, turn off msi for this device. + */ + static void __devinit nvenet_msi_disable(struct pci_dev *dev) + { +- if (dmi_name_in_vendors("P5N32-SLI PREMIUM")) { ++ if (dmi_name_in_vendors("P5N32-SLI PREMIUM") || ++ dmi_name_in_vendors("P5N32-E SLI")) { + dev_info(&dev->dev, +- "Disabling msi for MCP55 NIC on P5N32-SLI Premium\n"); ++ "Disabling msi for MCP55 NIC on P5N32-SLI\n"); + dev->no_msi = 1; + } + } diff --git a/queue-2.6.32/pci-quirk-disable-msi-on-via-k8t890-systems.patch b/queue-2.6.32/pci-quirk-disable-msi-on-via-k8t890-systems.patch new file mode 100644 index 00000000000..75ae779443c --- /dev/null +++ b/queue-2.6.32/pci-quirk-disable-msi-on-via-k8t890-systems.patch @@ -0,0 +1,33 @@ +From 134b345081534235dbf228b1005c14590e0570ba Mon Sep 17 00:00:00 2001 +From: Matthew Wilcox +Date: Wed, 24 Mar 2010 07:11:01 -0600 +Subject: PCI quirk: Disable MSI on VIA K8T890 systems + +From: Matthew Wilcox + +commit 134b345081534235dbf228b1005c14590e0570ba upstream. + +Bugzilla 15287 indicates that there's a problem with Message Signalled +Interrupts on VIA K8T890 systems. Add a quirk to disable MSI on these +systems. + +Signed-off-by: Matthew Wilcox +Tested-by: Jan Kreuzer +Tested-by: lh +Signed-off-by: Jesse Barnes +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/pci/quirks.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/pci/quirks.c ++++ b/drivers/pci/quirks.c +@@ -2092,6 +2092,7 @@ static void __devinit quirk_disable_msi( + } + } + DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_8131_BRIDGE, quirk_disable_msi); ++DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_VIA, 0xa238, quirk_disable_msi); + + /* Go through the list of Hypertransport capabilities and + * return 1 if a HT MSI capability is found and enabled */ diff --git a/queue-2.6.32/pci-quirks-disable-msi-on-amd-rs4xx-internal-gfx-bridges.patch b/queue-2.6.32/pci-quirks-disable-msi-on-amd-rs4xx-internal-gfx-bridges.patch new file mode 100644 index 00000000000..01be1d1ceaf --- /dev/null +++ b/queue-2.6.32/pci-quirks-disable-msi-on-amd-rs4xx-internal-gfx-bridges.patch @@ -0,0 +1,30 @@ +From 9313ff450400e6a2ab10fe6b9bdb12a828329410 Mon Sep 17 00:00:00 2001 +From: Alex Deucher +Date: Tue, 18 May 2010 10:42:53 -0400 +Subject: PCI quirks: disable msi on AMD rs4xx internal gfx bridges + +From: Alex Deucher + +commit 9313ff450400e6a2ab10fe6b9bdb12a828329410 upstream. + +Doesn't work reliably for internal gfx. Fixes kernel bug +https://bugzilla.kernel.org/show_bug.cgi?id=15626. + +Signed-off-by: Alex Deucher +Signed-off-by: Jesse Barnes +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/pci/quirks.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/pci/quirks.c ++++ b/drivers/pci/quirks.c +@@ -2093,6 +2093,7 @@ static void __devinit quirk_disable_msi( + } + DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_8131_BRIDGE, quirk_disable_msi); + DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_VIA, 0xa238, quirk_disable_msi); ++DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x5a3f, quirk_disable_msi); + + /* Go through the list of Hypertransport capabilities and + * return 1 if a HT MSI capability is found and enabled */ diff --git a/queue-2.6.32/series b/queue-2.6.32/series index ac9971976bf..d9e7b445422 100644 --- a/queue-2.6.32/series +++ b/queue-2.6.32/series @@ -37,3 +37,13 @@ usb-ehci-clear-phcd-before-resuming.patch usb-xhci-fix-issue-with-set-interface-after-stall.patch usb-xhci-fix-check-for-room-on-the-ring.patch usb-xhci-fix-wrong-usage-of-macro-trb_type.patch +mac80211-give-warning-if-building-w-out-rate-ctrl-algorithm.patch +mac80211-fix-robust-management-frame-handling-mfp.patch +mac80211-fix-rts-threshold-check.patch +drm-i915-reject-bind_to_gtt-early-if-object-aperture.patch +drivers-base-cpu.c-fix-the-output-from-sys-devices-system-cpu-offline.patch +can-fix-sja1000-command-register-writes-on-smp-systems.patch +pci-quirk-disable-msi-on-via-k8t890-systems.patch +pci-quirks-disable-msi-on-amd-rs4xx-internal-gfx-bridges.patch +pci-disable-msi-for-mcp55-on-p5n32-e-sli.patch +virtio_net-make-delayed-refill-more-reliable.patch diff --git a/queue-2.6.32/virtio_net-make-delayed-refill-more-reliable.patch b/queue-2.6.32/virtio_net-make-delayed-refill-more-reliable.patch new file mode 100644 index 00000000000..d772b182b38 --- /dev/null +++ b/queue-2.6.32/virtio_net-make-delayed-refill-more-reliable.patch @@ -0,0 +1,52 @@ +From 39d321577405e8e269fd238b278aaf2425fa788a Mon Sep 17 00:00:00 2001 +From: Herbert Xu +Date: Mon, 25 Jan 2010 15:51:01 -0800 +Subject: virtio_net: Make delayed refill more reliable + +From: Herbert Xu + +commit 39d321577405e8e269fd238b278aaf2425fa788a upstream. + +I have seen RX stalls on a machine that experienced a suspected +OOM. After the stall, the RX buffer is empty on the guest side +and there are exactly 16 entries available on the host side. As +the number of entries is less than that required by a maximal +skb, the host cannot proceed. + +The guest did not have a refill job scheduled. + +My diagnosis is that an OOM had occured, with the delayed refill +job scheduled. The job was able to allocate at least one skb, but +not enough to overcome the minimum required by the host to proceed. + +As the refill job would only reschedule itself if it failed completely +to allocate any skbs, this would lead to an RX stall. + +The following patch removes this stall possibility by always +rescheduling the refill job until the ring is totally refilled. + +Testing has shown that the RX stall no longer occurs whereas +previously it would occur within a day. + +Signed-off-by: Herbert Xu +Acked-by: Rusty Russell +Signed-off-by: David S. Miller +Cc: Bruce Rogers +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/net/virtio_net.c | 3 +-- + 1 file changed, 1 insertion(+), 2 deletions(-) + +--- a/drivers/net/virtio_net.c ++++ b/drivers/net/virtio_net.c +@@ -398,8 +398,7 @@ static void refill_work(struct work_stru + + vi = container_of(work, struct virtnet_info, refill.work); + napi_disable(&vi->napi); +- try_fill_recv(vi, GFP_KERNEL); +- still_empty = (vi->num == 0); ++ still_empty = !try_fill_recv(vi, GFP_KERNEL); + napi_enable(&vi->napi); + + /* In theory, this can happen: if we don't get any buffers in