From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dean Nelson Subject: Re: net: thunder: change q_len's type to handle max ring size Date: Thu, 8 Feb 2018 15:57:21 -0600 Message-ID: <41824374-cdea-a3ef-0109-20565dbba43e@redhat.com> References: <151811766130.10712.18293368656209944798.email-sent-by-dnelson@aqua> <20180208.153453.774785043965984772.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: rric@kernel.org, sgoutham@cavium.com, netdev@vger.kernel.org, Vadim.Lomovtsev@cavium.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org To: David Miller Return-path: Received: from mx1.redhat.com ([209.132.183.28]:37864 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752185AbeBHV5X (ORCPT ); Thu, 8 Feb 2018 16:57:23 -0500 In-Reply-To: <20180208.153453.774785043965984772.davem@davemloft.net> Content-Language: en-US Sender: netdev-owner@vger.kernel.org List-ID: On 02/08/2018 02:34 PM, David Miller wrote: > From: Dean Nelson > Date: > >> The Cavium thunder nicvf driver supports rx/tx rings of up to 65536 entries per. >> The number of entires are stored in the q_len member of struct q_desc_mem. The >> problem is that q_len being a u16, results in 65536 becoming 0. >> >> In getting pointers to descriptors in the rings, the driver uses q_len minus 1 >> as a mask after incrementing the pointer, in order to go back to the beginning >> and not go past the end of the ring. >> >> With the q_len set to 0 the mask is no longer correct and the driver does go >> beyond the end of the ring, causing various ills. Usually the first thing that >> shows up is a "NETDEV WATCHDOG: enP2p1s0f1 (nicvf): transmit queue 7 timed out" >> warning. >> >> This patch remedies the problem by changing q_len to a u32. >> >> Signed-off-by: Dean Nelson > > Applied, thanks. Thank you! > > Another way to solve this could have been to encode that length > as "length - 1" True. I had pondered that, but felt that since changing q_len's type didn't add any length to the structure and that it was less impactful from a number-of-lines of code changed perspective, I'd opt for this route. Cavium, if you'd prefer this goes the route that Dave just mentioned, please let me know and I can make a new patch against what's been applied? Thanks, Dean