Message ID | 20240206123054.3052966-1-horatiu.vultur@microchip.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-54956-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7301:168b:b0:106:860b:bbdd with SMTP id ma11csp1506698dyb; Tue, 6 Feb 2024 04:37:07 -0800 (PST) X-Google-Smtp-Source: AGHT+IETttZd37ulwazYBgTcbYJ5atVMr9rjrTZosAXgQBY3TfuEMBYWnBYGGw16P7YBEnQ6EzDj X-Received: by 2002:a17:906:710b:b0:a37:f127:8c0d with SMTP id x11-20020a170906710b00b00a37f1278c0dmr1764913ejj.64.1707223027332; Tue, 06 Feb 2024 04:37:07 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1707223027; cv=pass; d=google.com; s=arc-20160816; b=jqHKxDCethtZKDt3OBNMKBiXzCQzAgbEUSWgOQeB1D9a6/qI5mlu4pvqCtNMFavAA1 8XscMFtsr+k0iDGwLIn9lYzAH2HFg/QL8RKp24CB8k4KeyxKproOZN2fZh2i1QhXyXGn BCOx27gzUB74zWEjlwjhVzK041NH+/KM47sbpJ1oNdTL8yz1sRlYH6m77td9QcULEmxC 66o3xODC6AczTSeY4Zx1mLKlipyHgc6izBDnHyngvdywbZQa6t/VQ4PK5F93WsdRx6q+ i5ey5N4HX4SjmQ9vaSY0HtVat+7CgZlWp4bp8bJ+LUtpAKLP5+LWm6+nMvIPSPfNBV0y 3+YA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:date:subject:cc:to :from:dkim-signature; bh=OsfJDNAu3qx4Dv2L5zfOToX/xhcjkKfSzR9w6R9pZ3g=; fh=hUhHQsfDC1AajelcR48EteabExWwgxT65PZq3QyQ2Qk=; b=f78Q+hxEmM1i8TD07K+jhG6zuQyg+UEjqKio8iEVg39M0cFYOcaCVJDzGB1LCGr13o Tth17heM5Pgj1xCcVlIyN36ArDvVSfhapAIAxqjv3GC3jt5us79+AUToF8vDtDgQC3Az VepaMtjotLlECfGyKRcapmNmxSL9OXHAfoGh+kA+LIvxIvINc/YfugVfbzlaJCdn9vDL L2bVdn+S3/0yiyaiftH4+NGLQfmEFv0G2WscNbsje84/hGDwHwyg5l/6RKXnHQyPwgxT a3dGPBhLP7zvIEU/MusqF8xIbgcBRRFF4mNvezGTQMqE0fAqor/PC2H9znS6P2ONz0zY P37A==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@microchip.com header.s=mchp header.b=W73jhNOc; arc=pass (i=1 spf=pass spfdomain=microchip.com dkim=pass dkdomain=microchip.com dmarc=pass fromdomain=microchip.com); spf=pass (google.com: domain of linux-kernel+bounces-54956-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-54956-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=QUARANTINE sp=REJECT dis=NONE) header.from=microchip.com X-Forwarded-Encrypted: i=1; AJvYcCUzkpj1ip9gIWWP1H2pzb+NKJV3g7fgA758S44p/NJud+WdXhPsijBWoWFcFLTy6Zr+LA/B6UIOwKCbo8clr9zvUthYVw== Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [147.75.80.249]) by mx.google.com with ESMTPS id t22-20020a17090616d600b00a37b63c88ebsi1025095ejd.223.2024.02.06.04.37.07 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 06 Feb 2024 04:37:07 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-54956-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249; Authentication-Results: mx.google.com; dkim=pass header.i=@microchip.com header.s=mchp header.b=W73jhNOc; arc=pass (i=1 spf=pass spfdomain=microchip.com dkim=pass dkdomain=microchip.com dmarc=pass fromdomain=microchip.com); spf=pass (google.com: domain of linux-kernel+bounces-54956-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-54956-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=QUARANTINE sp=REJECT dis=NONE) header.from=microchip.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id 5095B1F25C8E for <ouuuleilei@gmail.com>; Tue, 6 Feb 2024 12:36:58 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id B29BA131746; Tue, 6 Feb 2024 12:31:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=microchip.com header.i=@microchip.com header.b="W73jhNOc" Received: from esa.microchip.iphmx.com (esa.microchip.iphmx.com [68.232.154.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 05021130E48; Tue, 6 Feb 2024 12:31:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=68.232.154.123 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707222715; cv=none; b=qjKZZ8BYcRiRFOCABd3EZX9GawyRj7TxlzXZkFXC0Esq9JDBWDtptZBsAqpSU2YzcsVEdt55ET1oUTZCeH2bWB+1UGvMvIFI4CDBkp7V2O3MdBMOOuEzxRh1Em+HamsVh0yg+FXg4ScFx2rCSQQ7yKHozEu9L196uL4CRW+taGY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707222715; c=relaxed/simple; bh=lKFmIHEUO+dJrK7RCAPNBhE2qNe6Nhep6pxKGWFpkfo=; h=From:To:CC:Subject:Date:Message-ID:MIME-Version:Content-Type; b=J3EWWZC4+4GEcFCz6CxbOypvRX4TF9cZd+AeTk5NaKQPeUMv9aZ+InEeohyr4znuYVcEqm70dHPx342+xswJLRS7vm44NS6NTs2Kq1cBzXDo9fAg5HJRgdeYlmjpq3v/Sor6reBCtHhrU2uU/LQXGfQZSJG4aRCAyRraWkgakmo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=microchip.com; spf=pass smtp.mailfrom=microchip.com; dkim=pass (2048-bit key) header.d=microchip.com header.i=@microchip.com header.b=W73jhNOc; arc=none smtp.client-ip=68.232.154.123 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=microchip.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=microchip.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=microchip.com; i=@microchip.com; q=dns/txt; s=mchp; t=1707222713; x=1738758713; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=lKFmIHEUO+dJrK7RCAPNBhE2qNe6Nhep6pxKGWFpkfo=; b=W73jhNOc8459Y2bJC/7CrDini+cNR1rcWAuv5NDes62zODzb37e4mL8I Rvt/k7S2rEh7htSOvlwaVp5p6Y9X0RqiOEea3aNbxAs8pT6Fe1KitwI/b tXG5yqMNL0YBdbF+4WheWWmcd+H9rmTO7Y0JuHislh2YZ9sg9aBveTLAK IyTQNZC2IG/J5m86jXpH9bUUOhC3MkS+JH6d0XFapdFkTVZOMPfAethVU lhs8vN/h04yYBMdLcO2C6Xi0A3KEjDOjIm0p2C5OiKEjT/muditudC5in o85Cmio0ekoaCZ6sJzqZTzNAQxEgkT4P4ujgA7czk1E0l48Kt75c/Z/bR Q==; X-CSE-ConnectionGUID: VSc2D1OUSp6Kb5lb+VdjZg== X-CSE-MsgGUID: DPYhfQf4SVCc0h/wLVDLSg== X-IronPort-AV: E=Sophos;i="6.05,247,1701154800"; d="scan'208";a="16349947" X-Amp-Result: SKIPPED(no attachment in message) Received: from unknown (HELO email.microchip.com) ([170.129.1.10]) by esa2.microchip.iphmx.com with ESMTP/TLS/ECDHE-RSA-AES128-GCM-SHA256; 06 Feb 2024 05:31:52 -0700 Received: from chn-vm-ex04.mchp-main.com (10.10.85.152) by chn-vm-ex03.mchp-main.com (10.10.85.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Tue, 6 Feb 2024 05:31:21 -0700 Received: from DEN-DL-M31836.microsemi.net (10.10.85.11) by chn-vm-ex04.mchp-main.com (10.10.85.152) with Microsoft SMTP Server id 15.1.2507.35 via Frontend Transport; Tue, 6 Feb 2024 05:31:19 -0700 From: Horatiu Vultur <horatiu.vultur@microchip.com> To: <davem@davemloft.net>, <edumazet@google.com>, <kuba@kernel.org>, <pabeni@redhat.com>, <UNGLinuxDriver@microchip.com> CC: <netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org>, Horatiu Vultur <horatiu.vultur@microchip.com>, Michal Swiatkowski <michal.swiatkowski@linux.intel.com> Subject: [PATCH net v2] lan966x: Fix crash when adding interface under a lag Date: Tue, 6 Feb 2024 13:30:54 +0100 Message-ID: <20240206123054.3052966-1-horatiu.vultur@microchip.com> X-Mailer: git-send-email 2.34.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1790153093316666971 X-GMAIL-MSGID: 1790153093316666971 |
Series |
[net,v2] lan966x: Fix crash when adding interface under a lag
|
|
Commit Message
Horatiu Vultur
Feb. 6, 2024, 12:30 p.m. UTC
There is a crash when adding one of the lan966x interfaces under a lag interface. The issue can be reproduced like this: ip link add name bond0 type bond miimon 100 mode balance-xor ip link set dev eth0 master bond0 The reason is because when adding a interface under the lag it would go through all the ports and try to figure out which other ports are under that lag interface. And the issue is that lan966x can have ports that are NULL pointer as they are not probed. So then iterating over these ports it would just crash as they are NULL pointers. The fix consists in actually checking for NULL pointers before accessing something from the ports. Like we do in other places. Fixes: cabc9d49333d ("net: lan966x: Add lag support for lan966x") Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com> Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com> --- v1->v2: - replace lan966x->ports[lag]->bond with port->bond as it is the same and easier to follow --- drivers/net/ethernet/microchip/lan966x/lan966x_lag.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)
Comments
On Tue, Feb 06, 2024 at 01:30:54PM +0100, Horatiu Vultur wrote: > There is a crash when adding one of the lan966x interfaces under a lag > interface. The issue can be reproduced like this: > ip link add name bond0 type bond miimon 100 mode balance-xor > ip link set dev eth0 master bond0 > > The reason is because when adding a interface under the lag it would go > through all the ports and try to figure out which other ports are under > that lag interface. And the issue is that lan966x can have ports that are > NULL pointer as they are not probed. So then iterating over these ports > it would just crash as they are NULL pointers. > The fix consists in actually checking for NULL pointers before accessing > something from the ports. Like we do in other places. > > Fixes: cabc9d49333d ("net: lan966x: Add lag support for lan966x") > Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com> > Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com> Reviewed-by: Simon Horman <horms@kernel.org>
On Tue, 6 Feb 2024 13:30:54 +0100 Horatiu Vultur wrote: > for (lag = 0; lag < lan966x->num_phys_ports; ++lag) { > - struct net_device *bond = lan966x->ports[lag]->bond; > + struct lan966x_port *port = lan966x->ports[lag]; > int num_active_ports = 0; > + struct net_device *bond; > unsigned long bond_mask; > u8 aggr_idx[16]; > > - if (!bond || (visited & BIT(lag))) > + if (!port || !port->bond || (visited & BIT(lag))) > continue; > > + bond = port->bond; > bond_mask = lan966x_lag_get_mask(lan966x, bond); > > for_each_set_bit(p, &bond_mask, lan966x->num_phys_ports) { > struct lan966x_port *port = lan966x->ports[p]; > > + if (!port) > + continue; Why would lan966x_lag_get_mask() set a bit for a port that doesn't exist? Earlier check makes sense. This one seems too defensive.
The 02/09/2024 13:52, Jakub Kicinski wrote: Hi Jakub, > > On Tue, 6 Feb 2024 13:30:54 +0100 Horatiu Vultur wrote: > > for (lag = 0; lag < lan966x->num_phys_ports; ++lag) { > > - struct net_device *bond = lan966x->ports[lag]->bond; > > + struct lan966x_port *port = lan966x->ports[lag]; > > int num_active_ports = 0; > > + struct net_device *bond; > > unsigned long bond_mask; > > u8 aggr_idx[16]; > > > > - if (!bond || (visited & BIT(lag))) > > + if (!port || !port->bond || (visited & BIT(lag))) > > continue; > > > > + bond = port->bond; > > bond_mask = lan966x_lag_get_mask(lan966x, bond); > > > > for_each_set_bit(p, &bond_mask, lan966x->num_phys_ports) { > > struct lan966x_port *port = lan966x->ports[p]; > > > > + if (!port) > > + continue; > > Why would lan966x_lag_get_mask() set a bit for a port that doesn't > exist? Earlier check makes sense. This one seems too defensive. You are right, the lan966x_lag_get_mask() will not set a bit for a port that doesn't exist[1]. Therefore this check is not needed. [1] https://elixir.bootlin.com/linux/latest/source/drivers/net/ethernet/microchip/lan966x/lan966x_lag.c#L354 > -- > pw-bot: cr
The 02/12/2024 09:10, Horatiu Vultur wrote: > The 02/09/2024 13:52, Jakub Kicinski wrote: > > Hi Jakub, > > > > > On Tue, 6 Feb 2024 13:30:54 +0100 Horatiu Vultur wrote: > > > for (lag = 0; lag < lan966x->num_phys_ports; ++lag) { > > > - struct net_device *bond = lan966x->ports[lag]->bond; > > > + struct lan966x_port *port = lan966x->ports[lag]; > > > int num_active_ports = 0; > > > + struct net_device *bond; > > > unsigned long bond_mask; > > > u8 aggr_idx[16]; > > > > > > - if (!bond || (visited & BIT(lag))) > > > + if (!port || !port->bond || (visited & BIT(lag))) > > > continue; > > > > > > + bond = port->bond; > > > bond_mask = lan966x_lag_get_mask(lan966x, bond); > > > > > > for_each_set_bit(p, &bond_mask, lan966x->num_phys_ports) { > > > struct lan966x_port *port = lan966x->ports[p]; > > > > > > + if (!port) > > > + continue; > > > > Why would lan966x_lag_get_mask() set a bit for a port that doesn't > > exist? Earlier check makes sense. This one seems too defensive. > > You are right, the lan966x_lag_get_mask() will not set a bit for a port > that doesn't exist[1]. Therefore this check is not needed. > > [1] https://elixir.bootlin.com/linux/latest/source/drivers/net/ethernet/microchip/lan966x/lan966x_lag.c#L354 While trying to rebase on net, the next version of this patch, I have seen that actually this version was accepted even though it was marked as "Changes Requested". The commit sha is: 15faa1f67ab405d47789d4702f587ec7df7ef03e How do you prefer to go forward from here? - do you want to revert this and then I will send a new version? - should I send a patch that just removes this unneeded check? - any other suggestion? > > > -- > > pw-bot: cr > > -- > /Horatiu
On Mon, 12 Feb 2024 09:32:29 +0100 Horatiu Vultur wrote: > > You are right, the lan966x_lag_get_mask() will not set a bit for a port > > that doesn't exist[1]. Therefore this check is not needed. > > > > [1] https://elixir.bootlin.com/linux/latest/source/drivers/net/ethernet/microchip/lan966x/lan966x_lag.c#L354 > > While trying to rebase on net, the next version of this patch, I have seen that > actually this version was accepted even though it was marked as "Changes > Requested". > The commit sha is: 15faa1f67ab405d47789d4702f587ec7df7ef03e > > How do you prefer to go forward from here? > - do you want to revert this and then I will send a new version? > - should I send a patch that just removes this unneeded check? > - any other suggestion? Sorry about that, I must have forgotten to reset the tree after viewing and didn't spot this between Brenos patches :S No big deal, let's leave it as is.
diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_lag.c b/drivers/net/ethernet/microchip/lan966x/lan966x_lag.c index 41fa2523d91d3..5f2cd9a8cf8fb 100644 --- a/drivers/net/ethernet/microchip/lan966x/lan966x_lag.c +++ b/drivers/net/ethernet/microchip/lan966x/lan966x_lag.c @@ -37,19 +37,24 @@ static void lan966x_lag_set_aggr_pgids(struct lan966x *lan966x) /* Now, set PGIDs for each active LAG */ for (lag = 0; lag < lan966x->num_phys_ports; ++lag) { - struct net_device *bond = lan966x->ports[lag]->bond; + struct lan966x_port *port = lan966x->ports[lag]; int num_active_ports = 0; + struct net_device *bond; unsigned long bond_mask; u8 aggr_idx[16]; - if (!bond || (visited & BIT(lag))) + if (!port || !port->bond || (visited & BIT(lag))) continue; + bond = port->bond; bond_mask = lan966x_lag_get_mask(lan966x, bond); for_each_set_bit(p, &bond_mask, lan966x->num_phys_ports) { struct lan966x_port *port = lan966x->ports[p]; + if (!port) + continue; + lan_wr(ANA_PGID_PGID_SET(bond_mask), lan966x, ANA_PGID(p)); if (port->lag_tx_active)