From mboxrd@z Thu Jan  1 00:00:00 1970
From: David Miller <davem@davemloft.net>
Subject: Re: [PATCH net] stmmac: reset last TSO segment size after device
 open
Date: Sun, 03 Dec 2017 09:48:25 -0500 (EST)
Message-ID: <20171203.094825.2018066401141815227.davem@davemloft.net>
References: <20171201101244.16675-1-larper@axis.com>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: peppe.cavallaro@st.com, alexandre.torgue@st.com,
        netdev@vger.kernel.org, larper@axis.com
To: lars.persson@axis.com
Return-path: <netdev-owner@vger.kernel.org>
Received: from shards.monkeyblade.net ([184.105.139.130]:35814 "EHLO
        shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1752546AbdLCOs0 (ORCPT
        <rfc822;netdev@vger.kernel.org>); Sun, 3 Dec 2017 09:48:26 -0500
In-Reply-To: <20171201101244.16675-1-larper@axis.com>
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>

From: Lars Persson <lars.persson@axis.com>
Date: Fri,  1 Dec 2017 11:12:44 +0100

> The mss variable tracks the last max segment size sent to the TSO
> engine. We do not update the hardware as long as we receive skb:s with
> the same value in gso_size.
> 
> During a network device down/up cycle (mapped to stmmac_release() and
> stmmac_open() callbacks) we issue a reset to the hardware and it
> forgets the setting for mss. However we did not zero out our mss
> variable so the next transmission of a gso packet happens with an
> undefined hardware setting.
> 
> This triggers a hang in the TSO engine and eventuelly the netdev
> watchdog will bark.
> 
> Fixes: f748be531d70 ("stmmac: support new GMAC4")
> Signed-off-by: Lars Persson <larper@axis.com>

Applied and queued up for -stable, thanks.