Received-SPF: pass (google.com: domain of linux-kernel+bounces-176647-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Date: Sat, 11 May 2024 17:38:10 +0100
From: Simon Horman <horms@kernel.org>
To: Larysa Zaremba <larysa.zaremba@intel.com>
Cc: Tony Nguyen <anthony.l.nguyen@intel.com>,
	intel-wired-lan@lists.osuosl.org, linux-kernel@vger.kernel.org,
	netdev@vger.kernel.org, alan.brady@intel.com,
	maciej.fijalkowski@intel.com, jesse.brandeburg@intel.com,
	Emil Tantilov <emil.s.tantilov@intel.com>,
	Pavan Kumar Linga <pavan.kumar.linga@intel.com>,
	joshua.a.hay@intel.com,
	Przemek Kitszel <przemyslaw.kitszel@intel.com>,
	Igor Bagnucki <igor.bagnucki@intel.com>
Subject: Re: [PATCH iwl-net] idpf: Interpret .set_channels() input differently
Message-ID: <20240511163810.GN2347895@kernel.org>
References: <20240426154125.235977-1-larysa.zaremba@intel.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20240426154125.235977-1-larysa.zaremba@intel.com>

On Fri, Apr 26, 2024 at 05:41:22PM +0200, Larysa Zaremba wrote:
> Unlike ice, idpf does not check, if user has requested at least 1 combined
> channel. Instead, it relies on a check in the core code. Unfortunately, the
> check does not trigger for us because of the hacky .set_channels()
> interpretation logic that is not consistent with the core code.
> 
> This naturally leads to user being able to trigger a crash with an invalid
> input. This is how:
> 
> 1. ethtool -l <IFNAME> -> combined: 40
> 2. ethtool -L <IFNAME> rx 0 tx 0
>    combined number is not specified, so command becomes {rx_count = 0,
>    tx_count = 0, combined_count = 40}.
> 3. ethnl_set_channels checks, if there is at least 1 RX and 1 TX channel,
>    comparing (combined_count + rx_count) and (combined_count + tx_count)
>    to zero. Obviously, (40 + 0) is greater than zero, so the core code
>    deems the input OK.
> 4. idpf interprets `rx 0 tx 0` as 0 channels and tries to proceed with such
>    configuration.
> 
> The issue has to be solved fundamentally, as current logic is also known to
> cause AF_XDP problems in ice [0].
> 
> Interpret the command in a way that is more consistent with ethtool
> manual [1] (--show-channels and --set-channels) and new ice logic.
> 
> Considering that in the idpf driver only the difference between RX and TX
> queues forms dedicated channels, change the correct way to set number of
> channels to:
> 
> ethtool -L <IFNAME> combined 10 /* For symmetric queues */
> ethtool -L <IFNAME> combined 8 tx 2 rx 0 /* For asymmetric queues */
> 
> [0] https://lore.kernel.org/netdev/20240418095857.2827-1-larysa.zaremba@intel.com/
> [1] https://man7.org/linux/man-pages/man8/ethtool.8.html
> 
> Fixes: 02cbfba1add5 ("idpf: add ethtool callbacks")
> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
> Reviewed-by: Igor Bagnucki <igor.bagnucki@intel.com>
> Signed-off-by: Larysa Zaremba <larysa.zaremba@intel.com>

Reviewed-by: Simon Horman <horms@kernel.org>