On Tue, Nov 28, 2017 at 11:23:23AM -0800, Jeff Kirsher wrote: > On Tue, 2017-11-28 at 11:18 +0100, Greg KH wrote: > > On Tue, Nov 28, 2017 at 11:56:41AM +0200, Neftin, Sasha wrote: > > > On 28/11/2017 11:27, gregkh@xxxxxxxxxxxxxxxxxxx wrote: > > > > This is a note to let you know that I've just added the patch titled > > > > > > > > e1000e: fix buffer overrun while the I219 is processing DMA > > > > transactions > > > > > > > > to the 4.14-stable tree which can be found at: > > > > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queu > > > > e.git;a=summary > > > > > > > > The filename of the patch is: > > > > e1000e-fix-buffer-overrun-while-the-i219-is-processing-dma- > > > > transactions.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@xxxxxxxxxxxxxxx> know about it. > > > > > > > > > > > > From b10effb92e272051dd1ec0d7be56bf9ca85ab927 Mon Sep 17 00:00:00 > > > > 2001 > > > > From: Sasha Neftin <sasha.neftin@xxxxxxxxx> > > > > Date: Sun, 6 Aug 2017 16:49:18 +0300 > > > > Subject: e1000e: fix buffer overrun while the I219 is processing DMA > > > > transactions > > > > MIME-Version: 1.0 > > > > Content-Type: text/plain; charset=UTF-8 > > > > Content-Transfer-Encoding: 8bit > > > > > > > > From: Sasha Neftin <sasha.neftin@xxxxxxxxx> > > > > > > > > commit b10effb92e272051dd1ec0d7be56bf9ca85ab927 upstream. > > > > > > > > Intel® 100/200 Series Chipset platforms reduced the round-trip > > > > latency for the LAN Controller DMA accesses, causing in some high > > > > performance cases a buffer overrun while the I219 LAN Connected > > > > Device is processing the DMA transactions. I219LM and I219V devices > > > > can fall into unrecovered Tx hang under very stressfully UDP traffic > > > > and multiple reconnection of Ethernet cable. This Tx hang of the LAN > > > > Controller is only recovered if the system is rebooted. Slightly slow > > > > down DMA access by reducing the number of outstanding requests. > > > > This workaround could have an impact on TCP traffic performance > > > > on the platform. Disabling TSO eliminates performance loss for TCP > > > > traffic without a noticeable impact on CPU performance. > > > > > > > > Please, refer to I218/I219 specification update: > > > > https://www.intel.com/content/www/us/en/embedded/products/networking/ > > > > ethernet-connection-i218-family-documentation.html > > > > > > > > Signed-off-by: Sasha Neftin <sasha.neftin@xxxxxxxxx> > > > > Reviewed-by: Dima Ruinskiy <dima.ruinskiy@xxxxxxxxx> > > > > Reviewed-by: Raanan Avargil <raanan.avargil@xxxxxxxxx> > > > > Tested-by: Aaron Brown <aaron.f.brown@xxxxxxxxx> > > > > Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@xxxxxxxxx> > > > > Signed-off-by: Amit Pundir <amit.pundir@xxxxxxxxxx> > > > > Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> > > > > > > > > --- > > > > drivers/net/ethernet/intel/e1000e/netdev.c | 8 +++++--- > > > > 1 file changed, 5 insertions(+), 3 deletions(-) > > > > > > > > --- a/drivers/net/ethernet/intel/e1000e/netdev.c > > > > +++ b/drivers/net/ethernet/intel/e1000e/netdev.c > > > > @@ -3021,8 +3021,8 @@ static void e1000_configure_tx(struct e1 > > > > hw->mac.ops.config_collision_dist(hw); > > > > - /* SPT and CNP Si errata workaround to avoid data corruption > > > > */ > > > > - if (hw->mac.type >= e1000_pch_spt) { > > > > + /* SPT and KBL Si errata workaround to avoid data corruption > > > > */ > > > > + if (hw->mac.type == e1000_pch_spt) { > > > > u32 reg_val; > > > > reg_val = er32(IOSFPC); > > > > @@ -3030,7 +3030,9 @@ static void e1000_configure_tx(struct e1 > > > > ew32(IOSFPC, reg_val); > > > > reg_val = er32(TARC(0)); > > > > - reg_val |= E1000_TARC0_CB_MULTIQ_3_REQ; > > > > + /* SPT and KBL Si errata workaround to avoid Tx hang > > > > */ > > > > + reg_val &= ~BIT(28); > > > > + reg_val |= BIT(29); > > > > ew32(TARC(0), reg_val); > > > > } > > > > } > > > > > > > > > > > > Patches currently in stable-queue which might be from sasha.neftin@in > > > > tel.com are > > > > > > > > queue-4.14/e1000e-fix-buffer-overrun-while-the-i219-is-processing- > > > > dma-transactions.patch > > > > > > This is good. To follow of this one we have sent (Jeff sent today) > > > another > > > one, same functionality but more fundamental and clear patch, please, > > > refer > > > to https://patchwork.ozlabs.org/patch/834472/. I believe you can take > > > it too > > > for stable build . > > > > What is the git commit id of the patch in Linus's tree? > > > > You all do know how to properly tag patches to be included automatically > > in stable releases, right? If so, how come no one does this for this > > driver? > > Sorry Greg, I did not realize the above commit was queued up for stable, > which is why the follow on commit that Sasha was referring to was not CC'd > to stable mailing list. I do and will usual add the stable mailing list > to commits that need to be queued up for the stable trees. > > Anyways, here is the commit id for the follow on patch for the changes > above. David Miller just accepted it into his net tree this morning, here > is the commit id info: > > commit c0f4b163a03e73055dd734eaca64b9580e72e7fb > Author: Sasha Neftin <sasha.neftin@xxxxxxxxx> > Date: Mon Nov 6 08:31:59 2017 +0200 > > e1000e: fix the use of magic numbers for buffer overrun issue > > This is a follow on to commit b10effb92e27 ("fix buffer overrun while > the > I219 is processing DMA transactions") to address David Laights > concerns > about the use of "magic" numbers. So define masks as well as add > additional code comments to give a better understanding of what needs > to > be done to avoid a buffer overrun. > > Signed-off-by: Sasha Neftin <sasha.neftin@xxxxxxxxx> > Reviewed-by: Alexander H Duyck <alexander.h.duyck@xxxxxxxxx> > Reviewed-by: Dima Ruinskiy <dima.ruinskiy@xxxxxxxxx> > Reviewed-by: Raanan Avargil <raanan.avargil@xxxxxxxxx> > Tested-by: Aaron Brown <aaron.f.brown@xxxxxxxxx> > Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@xxxxxxxxx> Now added to the 4.14-stable tree, thanks. greg k-h