This is a note to let you know that I've just added the patch titled
e1000e: Separate signaling for link check/link up
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
e1000e-separate-signaling-for-link-check-link-up.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 19110cfbb34d4af0cdfe14cd243f3b09dc95b013 Mon Sep 17 00:00:00 2001
From: Benjamin Poirier <bpoirier(a)suse.com>
Date: Fri, 21 Jul 2017 11:36:26 -0700
Subject: e1000e: Separate signaling for link check/link up
From: Benjamin Poirier <bpoirier(a)suse.com>
commit 19110cfbb34d4af0cdfe14cd243f3b09dc95b013 upstream.
Lennart reported the following race condition:
\ e1000_watchdog_task
\ e1000e_has_link
\ hw->mac.ops.check_for_link() === e1000e_check_for_copper_link
/* link is up */
mac->get_link_status = false;
/* interrupt */
\ e1000_msix_other
hw->mac.get_link_status = true;
link_active = !hw->mac.get_link_status
/* link_active is false, wrongly */
This problem arises because the single flag get_link_status is used to
signal two different states: link status needs checking and link status is
down.
Avoid the problem by using the return value of .check_for_link to signal
the link status to e1000e_has_link().
Reported-by: Lennart Sorensen <lsorense(a)csclub.uwaterloo.ca>
Signed-off-by: Benjamin Poirier <bpoirier(a)suse.com>
Tested-by: Aaron Brown <aaron.f.brown(a)intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com>
Signed-off-by: Amit Pundir <amit.pundir(a)linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/intel/e1000e/mac.c | 11 ++++++++---
drivers/net/ethernet/intel/e1000e/netdev.c | 2 +-
2 files changed, 9 insertions(+), 4 deletions(-)
--- a/drivers/net/ethernet/intel/e1000e/mac.c
+++ b/drivers/net/ethernet/intel/e1000e/mac.c
@@ -410,6 +410,9 @@ void e1000e_clear_hw_cntrs_base(struct e
* Checks to see of the link status of the hardware has changed. If a
* change in link status has been detected, then we read the PHY registers
* to get the current speed/duplex if link exists.
+ *
+ * Returns a negative error code (-E1000_ERR_*) or 0 (link down) or 1 (link
+ * up).
**/
s32 e1000e_check_for_copper_link(struct e1000_hw *hw)
{
@@ -423,7 +426,7 @@ s32 e1000e_check_for_copper_link(struct
* Change or Rx Sequence Error interrupt.
*/
if (!mac->get_link_status)
- return 0;
+ return 1;
/* First we want to see if the MII Status Register reports
* link. If so, then we want to get the current speed/duplex
@@ -461,10 +464,12 @@ s32 e1000e_check_for_copper_link(struct
* different link partner.
*/
ret_val = e1000e_config_fc_after_link_up(hw);
- if (ret_val)
+ if (ret_val) {
e_dbg("Error configuring flow control\n");
+ return ret_val;
+ }
- return ret_val;
+ return 1;
}
/**
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -5017,7 +5017,7 @@ static bool e1000e_has_link(struct e1000
case e1000_media_type_copper:
if (hw->mac.get_link_status) {
ret_val = hw->mac.ops.check_for_link(hw);
- link_active = !hw->mac.get_link_status;
+ link_active = ret_val > 0;
} else {
link_active = true;
}
Patches currently in stable-queue which might be from bpoirier(a)suse.com are
queue-4.4/e1000e-fix-error-path-in-link-detection.patch
queue-4.4/e1000e-separate-signaling-for-link-check-link-up.patch
queue-4.4/e1000e-fix-return-value-test.patch
This is a note to let you know that I've just added the patch titled
e1000e: Fix return value test
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
e1000e-fix-return-value-test.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From d3509f8bc7b0560044c15f0e3ecfde1d9af757a6 Mon Sep 17 00:00:00 2001
From: Benjamin Poirier <bpoirier(a)suse.com>
Date: Fri, 21 Jul 2017 11:36:25 -0700
Subject: e1000e: Fix return value test
From: Benjamin Poirier <bpoirier(a)suse.com>
commit d3509f8bc7b0560044c15f0e3ecfde1d9af757a6 upstream.
All the helpers return -E1000_ERR_PHY.
Signed-off-by: Benjamin Poirier <bpoirier(a)suse.com>
Tested-by: Aaron Brown <aaron.f.brown(a)intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com>
Signed-off-by: Amit Pundir <amit.pundir(a)linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/intel/e1000e/netdev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -5035,7 +5035,7 @@ static bool e1000e_has_link(struct e1000
break;
}
- if ((ret_val == E1000_ERR_PHY) && (hw->phy.type == e1000_phy_igp_3) &&
+ if ((ret_val == -E1000_ERR_PHY) && (hw->phy.type == e1000_phy_igp_3) &&
(er32(CTRL) & E1000_PHY_CTRL_GBE_DISABLE)) {
/* See e1000_kmrn_lock_loss_workaround_ich8lan() */
e_info("Gigabit has been disabled, downgrading speed\n");
Patches currently in stable-queue which might be from bpoirier(a)suse.com are
queue-4.4/e1000e-fix-error-path-in-link-detection.patch
queue-4.4/e1000e-separate-signaling-for-link-check-link-up.patch
queue-4.4/e1000e-fix-return-value-test.patch
This is a note to let you know that I've just added the patch titled
e1000e: Fix error path in link detection
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
e1000e-fix-error-path-in-link-detection.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From c4c40e51f9c32c6dd8adf606624c930a1c4d9bbb Mon Sep 17 00:00:00 2001
From: Benjamin Poirier <bpoirier(a)suse.com>
Date: Fri, 21 Jul 2017 11:36:23 -0700
Subject: e1000e: Fix error path in link detection
From: Benjamin Poirier <bpoirier(a)suse.com>
commit c4c40e51f9c32c6dd8adf606624c930a1c4d9bbb upstream.
In case of error from e1e_rphy(), the loop will exit early and "success"
will be set to true erroneously.
Signed-off-by: Benjamin Poirier <bpoirier(a)suse.com>
Tested-by: Aaron Brown <aaron.f.brown(a)intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com>
Signed-off-by: Amit Pundir <amit.pundir(a)linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/intel/e1000e/phy.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
--- a/drivers/net/ethernet/intel/e1000e/phy.c
+++ b/drivers/net/ethernet/intel/e1000e/phy.c
@@ -1744,6 +1744,7 @@ s32 e1000e_phy_has_link_generic(struct e
s32 ret_val = 0;
u16 i, phy_status;
+ *success = false;
for (i = 0; i < iterations; i++) {
/* Some PHYs require the MII_BMSR register to be read
* twice due to the link bit being sticky. No harm doing
@@ -1763,16 +1764,16 @@ s32 e1000e_phy_has_link_generic(struct e
ret_val = e1e_rphy(hw, MII_BMSR, &phy_status);
if (ret_val)
break;
- if (phy_status & BMSR_LSTATUS)
+ if (phy_status & BMSR_LSTATUS) {
+ *success = true;
break;
+ }
if (usec_interval >= 1000)
msleep(usec_interval / 1000);
else
udelay(usec_interval);
}
- *success = (i < iterations);
-
return ret_val;
}
Patches currently in stable-queue which might be from bpoirier(a)suse.com are
queue-4.4/e1000e-fix-error-path-in-link-detection.patch
queue-4.4/e1000e-separate-signaling-for-link-check-link-up.patch
queue-4.4/e1000e-fix-return-value-test.patch
This is a note to let you know that I've just added the patch titled
e1000e: Separate signaling for link check/link up
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
e1000e-separate-signaling-for-link-check-link-up.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 19110cfbb34d4af0cdfe14cd243f3b09dc95b013 Mon Sep 17 00:00:00 2001
From: Benjamin Poirier <bpoirier(a)suse.com>
Date: Fri, 21 Jul 2017 11:36:26 -0700
Subject: e1000e: Separate signaling for link check/link up
From: Benjamin Poirier <bpoirier(a)suse.com>
commit 19110cfbb34d4af0cdfe14cd243f3b09dc95b013 upstream.
Lennart reported the following race condition:
\ e1000_watchdog_task
\ e1000e_has_link
\ hw->mac.ops.check_for_link() === e1000e_check_for_copper_link
/* link is up */
mac->get_link_status = false;
/* interrupt */
\ e1000_msix_other
hw->mac.get_link_status = true;
link_active = !hw->mac.get_link_status
/* link_active is false, wrongly */
This problem arises because the single flag get_link_status is used to
signal two different states: link status needs checking and link status is
down.
Avoid the problem by using the return value of .check_for_link to signal
the link status to e1000e_has_link().
Reported-by: Lennart Sorensen <lsorense(a)csclub.uwaterloo.ca>
Signed-off-by: Benjamin Poirier <bpoirier(a)suse.com>
Tested-by: Aaron Brown <aaron.f.brown(a)intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com>
Signed-off-by: Amit Pundir <amit.pundir(a)linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/intel/e1000e/mac.c | 11 ++++++++---
drivers/net/ethernet/intel/e1000e/netdev.c | 2 +-
2 files changed, 9 insertions(+), 4 deletions(-)
--- a/drivers/net/ethernet/intel/e1000e/mac.c
+++ b/drivers/net/ethernet/intel/e1000e/mac.c
@@ -410,6 +410,9 @@ void e1000e_clear_hw_cntrs_base(struct e
* Checks to see of the link status of the hardware has changed. If a
* change in link status has been detected, then we read the PHY registers
* to get the current speed/duplex if link exists.
+ *
+ * Returns a negative error code (-E1000_ERR_*) or 0 (link down) or 1 (link
+ * up).
**/
s32 e1000e_check_for_copper_link(struct e1000_hw *hw)
{
@@ -423,7 +426,7 @@ s32 e1000e_check_for_copper_link(struct
* Change or Rx Sequence Error interrupt.
*/
if (!mac->get_link_status)
- return 0;
+ return 1;
/* First we want to see if the MII Status Register reports
* link. If so, then we want to get the current speed/duplex
@@ -461,10 +464,12 @@ s32 e1000e_check_for_copper_link(struct
* different link partner.
*/
ret_val = e1000e_config_fc_after_link_up(hw);
- if (ret_val)
+ if (ret_val) {
e_dbg("Error configuring flow control\n");
+ return ret_val;
+ }
- return ret_val;
+ return 1;
}
/**
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -5081,7 +5081,7 @@ static bool e1000e_has_link(struct e1000
case e1000_media_type_copper:
if (hw->mac.get_link_status) {
ret_val = hw->mac.ops.check_for_link(hw);
- link_active = !hw->mac.get_link_status;
+ link_active = ret_val > 0;
} else {
link_active = true;
}
Patches currently in stable-queue which might be from bpoirier(a)suse.com are
queue-4.14/e1000e-fix-error-path-in-link-detection.patch
queue-4.14/e1000e-separate-signaling-for-link-check-link-up.patch
queue-4.14/e1000e-fix-return-value-test.patch
queue-4.14/e1000e-avoid-receiver-overrun-interrupt-bursts.patch
This is a note to let you know that I've just added the patch titled
e1000e: Fix return value test
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
e1000e-fix-return-value-test.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From d3509f8bc7b0560044c15f0e3ecfde1d9af757a6 Mon Sep 17 00:00:00 2001
From: Benjamin Poirier <bpoirier(a)suse.com>
Date: Fri, 21 Jul 2017 11:36:25 -0700
Subject: e1000e: Fix return value test
From: Benjamin Poirier <bpoirier(a)suse.com>
commit d3509f8bc7b0560044c15f0e3ecfde1d9af757a6 upstream.
All the helpers return -E1000_ERR_PHY.
Signed-off-by: Benjamin Poirier <bpoirier(a)suse.com>
Tested-by: Aaron Brown <aaron.f.brown(a)intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com>
Signed-off-by: Amit Pundir <amit.pundir(a)linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/intel/e1000e/netdev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -5099,7 +5099,7 @@ static bool e1000e_has_link(struct e1000
break;
}
- if ((ret_val == E1000_ERR_PHY) && (hw->phy.type == e1000_phy_igp_3) &&
+ if ((ret_val == -E1000_ERR_PHY) && (hw->phy.type == e1000_phy_igp_3) &&
(er32(CTRL) & E1000_PHY_CTRL_GBE_DISABLE)) {
/* See e1000_kmrn_lock_loss_workaround_ich8lan() */
e_info("Gigabit has been disabled, downgrading speed\n");
Patches currently in stable-queue which might be from bpoirier(a)suse.com are
queue-4.14/e1000e-fix-error-path-in-link-detection.patch
queue-4.14/e1000e-separate-signaling-for-link-check-link-up.patch
queue-4.14/e1000e-fix-return-value-test.patch
queue-4.14/e1000e-avoid-receiver-overrun-interrupt-bursts.patch
This is a note to let you know that I've just added the patch titled
e1000e: Fix error path in link detection
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
e1000e-fix-error-path-in-link-detection.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From c4c40e51f9c32c6dd8adf606624c930a1c4d9bbb Mon Sep 17 00:00:00 2001
From: Benjamin Poirier <bpoirier(a)suse.com>
Date: Fri, 21 Jul 2017 11:36:23 -0700
Subject: e1000e: Fix error path in link detection
From: Benjamin Poirier <bpoirier(a)suse.com>
commit c4c40e51f9c32c6dd8adf606624c930a1c4d9bbb upstream.
In case of error from e1e_rphy(), the loop will exit early and "success"
will be set to true erroneously.
Signed-off-by: Benjamin Poirier <bpoirier(a)suse.com>
Tested-by: Aaron Brown <aaron.f.brown(a)intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com>
Signed-off-by: Amit Pundir <amit.pundir(a)linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/intel/e1000e/phy.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
--- a/drivers/net/ethernet/intel/e1000e/phy.c
+++ b/drivers/net/ethernet/intel/e1000e/phy.c
@@ -1744,6 +1744,7 @@ s32 e1000e_phy_has_link_generic(struct e
s32 ret_val = 0;
u16 i, phy_status;
+ *success = false;
for (i = 0; i < iterations; i++) {
/* Some PHYs require the MII_BMSR register to be read
* twice due to the link bit being sticky. No harm doing
@@ -1763,16 +1764,16 @@ s32 e1000e_phy_has_link_generic(struct e
ret_val = e1e_rphy(hw, MII_BMSR, &phy_status);
if (ret_val)
break;
- if (phy_status & BMSR_LSTATUS)
+ if (phy_status & BMSR_LSTATUS) {
+ *success = true;
break;
+ }
if (usec_interval >= 1000)
msleep(usec_interval / 1000);
else
udelay(usec_interval);
}
- *success = (i < iterations);
-
return ret_val;
}
Patches currently in stable-queue which might be from bpoirier(a)suse.com are
queue-4.14/e1000e-fix-error-path-in-link-detection.patch
queue-4.14/e1000e-separate-signaling-for-link-check-link-up.patch
queue-4.14/e1000e-fix-return-value-test.patch
queue-4.14/e1000e-avoid-receiver-overrun-interrupt-bursts.patch
This is a note to let you know that I've just added the patch titled
e1000e: Avoid receiver overrun interrupt bursts
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
e1000e-avoid-receiver-overrun-interrupt-bursts.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 4aea7a5c5e940c1723add439f4088844cd26196d Mon Sep 17 00:00:00 2001
From: Benjamin Poirier <bpoirier(a)suse.com>
Date: Fri, 21 Jul 2017 11:36:27 -0700
Subject: e1000e: Avoid receiver overrun interrupt bursts
From: Benjamin Poirier <bpoirier(a)suse.com>
commit 4aea7a5c5e940c1723add439f4088844cd26196d upstream.
When e1000e_poll() is not fast enough to keep up with incoming traffic, the
adapter (when operating in msix mode) raises the Other interrupt to signal
Receiver Overrun.
This is a double problem because 1) at the moment e1000_msix_other()
assumes that it is only called in case of Link Status Change and 2) if the
condition persists, the interrupt is repeatedly raised again in quick
succession.
Ideally we would configure the Other interrupt to not be raised in case of
receiver overrun but this doesn't seem possible on this adapter. Instead,
we handle the first part of the problem by reverting to the practice of
reading ICR in the other interrupt handler, like before commit 16ecba59bc33
("e1000e: Do not read ICR in Other interrupt"). Thanks to commit
0a8047ac68e5 ("e1000e: Fix msi-x interrupt automask") which cleared IAME
from CTRL_EXT, reading ICR doesn't interfere with RxQ0, TxQ0 interrupts
anymore. We handle the second part of the problem by not re-enabling the
Other interrupt right away when there is overrun. Instead, we wait until
traffic subsides, napi polling mode is exited and interrupts are
re-enabled.
Reported-by: Lennart Sorensen <lsorense(a)csclub.uwaterloo.ca>
Fixes: 16ecba59bc33 ("e1000e: Do not read ICR in Other interrupt")
Signed-off-by: Benjamin Poirier <bpoirier(a)suse.com>
Tested-by: Aaron Brown <aaron.f.brown(a)intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com>
Signed-off-by: Amit Pundir <amit.pundir(a)linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/intel/e1000e/defines.h | 1
drivers/net/ethernet/intel/e1000e/netdev.c | 31 +++++++++++++++++++++-------
2 files changed, 25 insertions(+), 7 deletions(-)
--- a/drivers/net/ethernet/intel/e1000e/defines.h
+++ b/drivers/net/ethernet/intel/e1000e/defines.h
@@ -398,6 +398,7 @@
#define E1000_ICR_LSC 0x00000004 /* Link Status Change */
#define E1000_ICR_RXSEQ 0x00000008 /* Rx sequence error */
#define E1000_ICR_RXDMT0 0x00000010 /* Rx desc min. threshold (0) */
+#define E1000_ICR_RXO 0x00000040 /* Receiver Overrun */
#define E1000_ICR_RXT0 0x00000080 /* Rx timer intr (ring 0) */
#define E1000_ICR_ECCER 0x00400000 /* Uncorrectable ECC Error */
/* If this bit asserted, the driver should claim the interrupt */
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -1910,14 +1910,30 @@ static irqreturn_t e1000_msix_other(int
struct net_device *netdev = data;
struct e1000_adapter *adapter = netdev_priv(netdev);
struct e1000_hw *hw = &adapter->hw;
+ u32 icr;
+ bool enable = true;
- hw->mac.get_link_status = true;
+ icr = er32(ICR);
+ if (icr & E1000_ICR_RXO) {
+ ew32(ICR, E1000_ICR_RXO);
+ enable = false;
+ /* napi poll will re-enable Other, make sure it runs */
+ if (napi_schedule_prep(&adapter->napi)) {
+ adapter->total_rx_bytes = 0;
+ adapter->total_rx_packets = 0;
+ __napi_schedule(&adapter->napi);
+ }
+ }
+ if (icr & E1000_ICR_LSC) {
+ ew32(ICR, E1000_ICR_LSC);
+ hw->mac.get_link_status = true;
+ /* guard against interrupt when we're going down */
+ if (!test_bit(__E1000_DOWN, &adapter->state))
+ mod_timer(&adapter->watchdog_timer, jiffies + 1);
+ }
- /* guard against interrupt when we're going down */
- if (!test_bit(__E1000_DOWN, &adapter->state)) {
- mod_timer(&adapter->watchdog_timer, jiffies + 1);
+ if (enable && !test_bit(__E1000_DOWN, &adapter->state))
ew32(IMS, E1000_IMS_OTHER);
- }
return IRQ_HANDLED;
}
@@ -2687,7 +2703,8 @@ static int e1000e_poll(struct napi_struc
napi_complete_done(napi, work_done);
if (!test_bit(__E1000_DOWN, &adapter->state)) {
if (adapter->msix_entries)
- ew32(IMS, adapter->rx_ring->ims_val);
+ ew32(IMS, adapter->rx_ring->ims_val |
+ E1000_IMS_OTHER);
else
e1000_irq_enable(adapter);
}
@@ -4204,7 +4221,7 @@ static void e1000e_trigger_lsc(struct e1
struct e1000_hw *hw = &adapter->hw;
if (adapter->msix_entries)
- ew32(ICS, E1000_ICS_OTHER);
+ ew32(ICS, E1000_ICS_LSC | E1000_ICS_OTHER);
else
ew32(ICS, E1000_ICS_LSC);
}
Patches currently in stable-queue which might be from bpoirier(a)suse.com are
queue-4.14/e1000e-fix-error-path-in-link-detection.patch
queue-4.14/e1000e-separate-signaling-for-link-check-link-up.patch
queue-4.14/e1000e-fix-return-value-test.patch
queue-4.14/e1000e-avoid-receiver-overrun-interrupt-bursts.patch
This is a note to let you know that I've just added the patch titled
USB: fix buffer overflows with parsing CDC headers
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
usb-fix-buffer-overflows-with-parsing-cdc-headers.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From oneukum(a)suse.com Tue Nov 28 10:13:45 2017
From: Oliver Neukum <oneukum(a)suse.com>
Date: Thu, 23 Nov 2017 16:20:05 +0100
Subject: USB: fix buffer overflows with parsing CDC headers
To: gregKH(a)linuxfoundation.org, linux-usb(a)vger.kernel.org, stable(a)kernel.org
Cc: Oliver Neukum <oneukum(a)suse.com>
Message-ID: <20171123152005.22493-1-oneukum(a)suse.com>
From: Oliver Neukum <oneukum(a)suse.com>
Parsing CDC headers a buffer overflow cannot just be prevented
by checking that the remainder of the buffer is longer than minimum
length. The size of the fields to be parsed must be figured in, too.
In newer kernels this issue has been fixed at a central location with
commit 2e1c42391ff2556387b3cb6308b24f6f65619feb
Author: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Date: Thu Sep 21 16:58:48 2017 +0200
USB: core: harden cdc_parse_cdc_header
on anything older the parsing had not been centralised, so a separate
fix for each driver is necessary.
Signed-off-by: Oliver Neukum <oneukum(a)suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/usb/cdc_ether.c | 9 ++++++++-
drivers/usb/class/cdc-acm.c | 2 +-
drivers/usb/class/cdc-wdm.c | 2 ++
3 files changed, 11 insertions(+), 2 deletions(-)
--- a/drivers/net/usb/cdc_ether.c
+++ b/drivers/net/usb/cdc_ether.c
@@ -171,6 +171,8 @@ int usbnet_generic_cdc_bind(struct usbne
dev_dbg(&intf->dev, "extra CDC header\n");
goto bad_desc;
}
+ if (len < sizeof(struct usb_cdc_header_desc))
+ break;
info->header = (void *) buf;
if (info->header->bLength != sizeof(*info->header)) {
dev_dbg(&intf->dev, "CDC header len %u\n",
@@ -184,6 +186,8 @@ int usbnet_generic_cdc_bind(struct usbne
*/
if (rndis) {
struct usb_cdc_acm_descriptor *acm;
+ if (len < sizeof(struct usb_cdc_acm_descriptor))
+ break;
acm = (void *) buf;
if (acm->bmCapabilities) {
@@ -200,6 +204,8 @@ int usbnet_generic_cdc_bind(struct usbne
dev_dbg(&intf->dev, "extra CDC union\n");
goto bad_desc;
}
+ if (len < sizeof(struct usb_cdc_union_desc))
+ break;
info->u = (void *) buf;
if (info->u->bLength != sizeof(*info->u)) {
dev_dbg(&intf->dev, "CDC union len %u\n",
@@ -258,6 +264,8 @@ int usbnet_generic_cdc_bind(struct usbne
dev_dbg(&intf->dev, "extra CDC ether\n");
goto bad_desc;
}
+ if (len < sizeof(struct usb_cdc_ether_desc))
+ break;
info->ether = (void *) buf;
if (info->ether->bLength != sizeof(*info->ether)) {
dev_dbg(&intf->dev, "CDC ether len %u\n",
@@ -275,7 +283,6 @@ int usbnet_generic_cdc_bind(struct usbne
dev_dbg(&intf->dev, "extra MDLM descriptor\n");
goto bad_desc;
}
-
desc = (void *)buf;
if (desc->bLength != sizeof(*desc))
--- a/drivers/usb/class/cdc-acm.c
+++ b/drivers/usb/class/cdc-acm.c
@@ -1139,7 +1139,7 @@ static int acm_probe(struct usb_interfac
}
}
- while (buflen > 0) {
+ while (buflen >= 3) { /* minimum length making sense */
elength = buffer[0];
if (!elength) {
dev_err(&intf->dev, "skipping garbage byte\n");
--- a/drivers/usb/class/cdc-wdm.c
+++ b/drivers/usb/class/cdc-wdm.c
@@ -891,6 +891,8 @@ static int wdm_probe(struct usb_interfac
case USB_CDC_HEADER_TYPE:
break;
case USB_CDC_DMM_TYPE:
+ if (buflen < sizeof(struct usb_cdc_dmm_desc))
+ break;
dmhd = (struct usb_cdc_dmm_desc *)buffer;
maxcom = le16_to_cpu(dmhd->wMaxCommand);
dev_dbg(&intf->dev,
Patches currently in stable-queue which might be from oneukum(a)suse.com are
queue-3.18/usb-fix-buffer-overflows-with-parsing-cdc-headers.patch
This is based on upstream commit 10e840dfb0b7, which did not touch the
iio-trig-periodic-rtc driver because it has been removed upstream.
The following explanation comes from that commit:
These stand-alone trigger drivers were using iio_trigger_put()
where they should have been using iio_trigger_free(). The
iio_trigger_put() adds a module_put which is bad since they
never did a module_get.
In the sysfs driver, module_get/put's are used as triggers are
added & removed. This extra module_put() occurs on an error path
in the probe routine (probably rare).
In the bfin-timer & interrupt trigger drivers, the module resources
are not explicitly managed, so it's doing a put on something that
was never get'd. It occurs on the probe error path and on the
remove path (not so rare).
Tested with the sysfs trigger driver.
The bfin & interrupt drivers were build tested & inspected only.
This was build tested only.
Cc: Alison Schofield <amsfield22(a)gmail.com>
Cc: Jonathan Cameron <jic23(a)kernel.org>
Signed-off-by: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
---
drivers/staging/iio/trigger/iio-trig-periodic-rtc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/iio/trigger/iio-trig-periodic-rtc.c b/drivers/staging/iio/trigger/iio-trig-periodic-rtc.c
index 00d139331261..52430e57e346 100644
--- a/drivers/staging/iio/trigger/iio-trig-periodic-rtc.c
+++ b/drivers/staging/iio/trigger/iio-trig-periodic-rtc.c
@@ -137,7 +137,7 @@ static int iio_trig_periodic_rtc_probe(struct platform_device *dev)
trig_info = kzalloc(sizeof(*trig_info), GFP_KERNEL);
if (!trig_info) {
ret = -ENOMEM;
- goto error_put_trigger_and_remove_from_list;
+ goto error_free_trigger_and_remove_from_list;
}
iio_trigger_set_drvdata(trig, trig_info);
trig->ops = &iio_prtc_trigger_ops;
@@ -164,9 +164,9 @@ error_close_rtc:
rtc_class_close(trig_info->rtc);
error_free_trig_info:
kfree(trig_info);
-error_put_trigger_and_remove_from_list:
+error_free_trigger_and_remove_from_list:
list_del(&trig->alloc_list);
- iio_trigger_put(trig);
+ iio_trigger_free(trig);
error_free_completed_registrations:
list_for_each_entry_safe(trig,
trig2,
--
2.15.0.rc0
This is a note to let you know that I've just added the patch titled
e1000e: Separate signaling for link check/link up
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
e1000e-separate-signaling-for-link-check-link-up.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 19110cfbb34d4af0cdfe14cd243f3b09dc95b013 Mon Sep 17 00:00:00 2001
From: Benjamin Poirier <bpoirier(a)suse.com>
Date: Fri, 21 Jul 2017 11:36:26 -0700
Subject: e1000e: Separate signaling for link check/link up
From: Benjamin Poirier <bpoirier(a)suse.com>
commit 19110cfbb34d4af0cdfe14cd243f3b09dc95b013 upstream.
Lennart reported the following race condition:
\ e1000_watchdog_task
\ e1000e_has_link
\ hw->mac.ops.check_for_link() === e1000e_check_for_copper_link
/* link is up */
mac->get_link_status = false;
/* interrupt */
\ e1000_msix_other
hw->mac.get_link_status = true;
link_active = !hw->mac.get_link_status
/* link_active is false, wrongly */
This problem arises because the single flag get_link_status is used to
signal two different states: link status needs checking and link status is
down.
Avoid the problem by using the return value of .check_for_link to signal
the link status to e1000e_has_link().
Reported-by: Lennart Sorensen <lsorense(a)csclub.uwaterloo.ca>
Signed-off-by: Benjamin Poirier <bpoirier(a)suse.com>
Tested-by: Aaron Brown <aaron.f.brown(a)intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com>
Signed-off-by: Amit Pundir <amit.pundir(a)linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/intel/e1000e/mac.c | 11 ++++++++---
drivers/net/ethernet/intel/e1000e/netdev.c | 2 +-
2 files changed, 9 insertions(+), 4 deletions(-)
--- a/drivers/net/ethernet/intel/e1000e/mac.c
+++ b/drivers/net/ethernet/intel/e1000e/mac.c
@@ -410,6 +410,9 @@ void e1000e_clear_hw_cntrs_base(struct e
* Checks to see of the link status of the hardware has changed. If a
* change in link status has been detected, then we read the PHY registers
* to get the current speed/duplex if link exists.
+ *
+ * Returns a negative error code (-E1000_ERR_*) or 0 (link down) or 1 (link
+ * up).
**/
s32 e1000e_check_for_copper_link(struct e1000_hw *hw)
{
@@ -423,7 +426,7 @@ s32 e1000e_check_for_copper_link(struct
* Change or Rx Sequence Error interrupt.
*/
if (!mac->get_link_status)
- return 0;
+ return 1;
/* First we want to see if the MII Status Register reports
* link. If so, then we want to get the current speed/duplex
@@ -461,10 +464,12 @@ s32 e1000e_check_for_copper_link(struct
* different link partner.
*/
ret_val = e1000e_config_fc_after_link_up(hw);
- if (ret_val)
+ if (ret_val) {
e_dbg("Error configuring flow control\n");
+ return ret_val;
+ }
- return ret_val;
+ return 1;
}
/**
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -4844,7 +4844,7 @@ static bool e1000e_has_link(struct e1000
case e1000_media_type_copper:
if (hw->mac.get_link_status) {
ret_val = hw->mac.ops.check_for_link(hw);
- link_active = !hw->mac.get_link_status;
+ link_active = ret_val > 0;
} else {
link_active = true;
}
Patches currently in stable-queue which might be from bpoirier(a)suse.com are
queue-3.18/e1000e-fix-error-path-in-link-detection.patch
queue-3.18/e1000e-separate-signaling-for-link-check-link-up.patch
queue-3.18/e1000e-fix-return-value-test.patch