From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Miller Subject: Re: [net] e1000e: DoS while TSO enabled caused by link partner with small MSS Date: Thu, 30 Aug 2012 12:40:54 -0400 (EDT) Message-ID: <20120830.124054.1909938204959144888.davem@davemloft.net> References: <1345876691-22254-1-git-send-email-jeffrey.t.kirsher@intel.com> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: bruce.w.allan@intel.com, netdev@vger.kernel.org, gospo@redhat.com, sassmann@redhat.com, bhutchings@solarflare.com, stable@vger.kernel.org To: jeffrey.t.kirsher@intel.com Return-path: Received: from shards.monkeyblade.net ([149.20.54.216]:37655 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754472Ab2H3Qk5 (ORCPT ); Thu, 30 Aug 2012 12:40:57 -0400 In-Reply-To: <1345876691-22254-1-git-send-email-jeffrey.t.kirsher@intel.com> Sender: netdev-owner@vger.kernel.org List-ID: From: Jeff Kirsher Date: Fri, 24 Aug 2012 23:38:11 -0700 > From: Bruce Allan > > With a low enough MSS on the link partner and TSO enabled locally, the > networking stack can periodically send a very large (e.g. 64KB) TCP > message for which the driver will attempt to use more Tx descriptors than > are available by default in the Tx ring. This is due to a workaround in > the code that imposes a limit of only 4 MSS-sized segments per descriptor > which appears to be a carry-over from the older e1000 driver and may be > applicable only to some older PCI or PCIx parts which are not supported in > e1000e. When the driver gets a message that is too large to fit across the > configured number of Tx descriptors, it stops the upper stack from queueing > any more and gets stuck in this state. After a timeout, the upper stack > assumes the adapter is hung and calls the driver to reset it. > > Remove the unnecessary limitation of using up to only 4 MSS-sized segments > per Tx descriptor, and put in a hard failure test to catch when attempting > to check for message sizes larger than would fit in the whole Tx ring. > Refactor the remaining logic that limits the size of data per Tx descriptor > from a seemingly arbitrary 8KB to a limit based on the dynamic size of the > Tx packet buffer as described in the hardware specification. > > Also, fix the logic in the check for space in the Tx ring for the next > largest possible packet after the current one has been successfully queued > for transmit, and use the appropriate defines for default ring sizes in > e1000_probe instead of magic values. > > This issue goes back to the introduction of e1000e in 2.6.24 when it was > split off from e1000. > > Reported-by: Ben Hutchings > Signed-off-by: Bruce Allan > Cc: Stable [2.6.24+] > Tested-by: Aaron Brown > Signed-off-by: Jeff Kirsher Applied, thanks.