From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f41.google.com (mail-pj1-f41.google.com [209.85.216.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 90F22256C61 for ; Fri, 22 May 2026 15:41:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.41 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779464491; cv=none; b=YW4CxI0c0cjkRm6kxx4fHw+5lg1O9cQ/I7wD1MTvLvQWJP+eGv/LRSLYkRIa4TTMpni83wmbekz26Q/P3D0PPtRiZnzy8m0v16m7SGPziBuIoXROUsGXKdHiPNCj33o3BSh9iVu0GOX4wA5QDFq7DduZrssO62SqtBavlbLnJQ4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779464491; c=relaxed/simple; bh=mQGHAvVaULvUTzHfl5O0N2R9WyRsRACnUIolwju07yE=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=JdnWbhpq7TBl46yhClJ2Cdh65sXO6A0FDqLzzHv0s4oJHAeupQoZf3Y0HDgYWC77qvS4vuOBmD+R9Qo4wE/i53qBQ38upT1CtmynNIaEzQjq7ZVBSG1WvkcyO4Wu/oMd+ZwAdTGmwNhehlhgqED0VkA48dKd9U5Izn1CosLThWE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=maFg3rz2; arc=none smtp.client-ip=209.85.216.41 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="maFg3rz2" Received: by mail-pj1-f41.google.com with SMTP id 98e67ed59e1d1-36974217d4eso4828412a91.2 for ; Fri, 22 May 2026 08:41:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779464490; x=1780069290; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=WYpGjrpcI/QWRW0u6cXWL87F6QxybhFOh1NZVYhUS8Q=; b=maFg3rz2SlbRluoIRGxievTyvsUN6hHKuh+Rb7rB4Z1S9/pGKPp/lBNFLg8qbw4gvE MzaR6CA0nNVhxS/SPJBQXjxGwol1pLaZG9rbABe02NI7/9Fi8NSv0yAccbhUxI3oLbrv iLqlmLsZQD5cY8/ZwVRmkpgGPzNClV4nz6fABYh3DwptwsScrVktVxin6Vi5lcMb1QID yxTf9n+wXR905YhcWH3aYgMRThiMK/h0/pmezP4T+1D01v/HjnwTE1e6o11R9uKcOLhn 7oOW7llm9bjc+MsYdc0fbl/gfdYPF2QFrjvte8BFuMvYXvMh4JN/y9yPxdDfl5uLQJ2O ovaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779464490; x=1780069290; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=WYpGjrpcI/QWRW0u6cXWL87F6QxybhFOh1NZVYhUS8Q=; b=SIMgCX8cKR+EwMn8R3IQwYpVJGjGT0mtZYufFMQhs1sL/MuYw21CFE4zMsVTmWEf6i zb5p0VmEYJMtKoEWoAvdJR+NejYdzrtLMjKu5sSB/ibbdTUD2KxUb/w4UzZ/pfpagFaa xLI8oqYQQRSzGdx2NJPRhw3IJ+Tsab5O43bolcshZ+FRG9ml8a7zpxHYmh/TVJxGuW4S Tv32QUZNbQBXGVwSYye3xZT5W8m7j+x3IVPIuFsey+1RY34mt6OoH9vHsfr6ZDO0poOm yRX4zhHhQ0s+fUQft95nWaugUV9k4vdlnJjesz0c3NgrspKGxQFro9boZ0UMXCYRaW1j 3UPg== X-Forwarded-Encrypted: i=1; AFNElJ8Rp17WfAkcrKXPRLDc9EmK3xcfs7s7agH1QmuOz4hY58jw8kmTeACh9GyNINfG933Ws6AALH3RrQq5roc=@vger.kernel.org X-Gm-Message-State: AOJu0YxmO34gFh55ynMR9w3s59EkJCH+3sfTAaHI0xSKTS8fR5AZw7em NPN9HiemM9nn/Mt5lejeX6Mn5Lp1t6YkMGws1KsxjW6gJ54Zaiq7HP9oJDgU1Q== X-Gm-Gg: Acq92OHYtbsqZrW5jHbD+xRWPD3USNp0Gk8u4oiFHP2FjT6dsJyPyrZVzqGa6IRp/aB 26yaafqFzkLbH8Jb3bE77nTbuPV2IbB6yOx3/zHPZRKEangqCskT1e9X9nTRpfdnJhPPoekfFSv 5Z/0JLa/d1hrck47LrMhmYxyR3zYX7Z/r0sHYlGm1boyrukk1tGA853pGpbkryqi1l/wY+Tk1Oz R546FJdkrjfhdIUbxdUXPivqPKhj+qVXlCiqnjMfA3+saZCHgBJmgtZmCqRfTaccLAVH4wg+B1u 3VQlOSlwgFNIIyIHDM2jzFCVKk5ufEL11oig3XSNGOPSqjeoaA3uVh110NWcOhTgl5pVk4ouePB YVZcG0hR77woG4AIZ9YbUqnx5F7AedRyC25zDdiOJk+Ji84IwzOkmpqS4d+yXLsPsq+IaXcacRR AMPZj0pfqvNBPeiQO9xRLya6X84e9i0UsVOTh1pvWB6dacbHkd X-Received: by 2002:a17:90b:3887:b0:369:7433:2fe with SMTP id 98e67ed59e1d1-36a676f5e4cmr4109664a91.6.1779464489866; Fri, 22 May 2026 08:41:29 -0700 (PDT) Received: from csl-conti-dell7858.ntu.edu.sg ([155.69.195.57]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-36a7212aa06sm1365450a91.3.2026.05.22.08.41.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 May 2026 08:41:29 -0700 (PDT) From: Maoyi Xie To: Ido Schimmel Cc: Petr Machata , netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: List iterator used after loop in mlxsw_sp_fid_port_vid_list_add? Date: Fri, 22 May 2026 23:41:25 +0800 Message-Id: <20260522154125.121895-1-maoyixie.tju@gmail.com> X-Mailer: git-send-email 2.34.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Hi all, I came across what looks like an iterator used after the loop ends in drivers/net/ethernet/mellanox/mlxsw/spectrum_fid.c (linux-7.1-rc1), in mlxsw_sp_fid_port_vid_list_add(). I would appreciate your input on whether this is worth fixing or whether I am misreading the pattern. list_for_each_entry(tmp_port_vid, &fid->port_vid_list, list) { if (tmp_port_vid->local_port > local_port) break; } list_add_tail(&port_vid->list, &tmp_port_vid->list); When the loop walks the whole list without break (the new local_port is larger than every existing one), `tmp_port_vid` walks past the end of the list and `&tmp_port_vid->list` aliases the list head via container_of() offset cancellation, so list_add_tail() resolves to inserting at the tail. That is the intended behaviour for the case where the loop falls through. The dereference of the iterator after the loop ends is the part I am unsure about. Same shape as the Koschel cleanups from 2022 (99d8ae4ec8a tracing, 2966a9918df clockevents, dc1acd5c946 dlm, and others) and the "controlled container confusion" pattern described in [1]. I drafted a candidate fix that initialises an explicit `insert_before` pointer to &fid->port_vid_list (the list head) and overwrites it to &tmp_port_vid->list only on early break, then passes insert_before to list_add_tail(). The iterator is no longer dereferenced after the loop and the diff is 5+/2-. I built spectrum_fid.o on x86_64 with MLXSW_CORE + MLXSW_PCI + MLXSW_SPECTRUM + NET_SWITCHDEV + VLAN_8021Q at W=1 and the object compiles clean with no warnings. I also ran a small userspace mock of the two versions across seven scenarios: empty list, single entry with the new local_port above, below, and equal to the existing one, and multi-entry insertion at head, middle, and tail (fall through). The final list ordering matches in every case. Does this look like something worth a [PATCH]? Happy to send one if so, or to drop it if the shape here is fine. Thanks, Maoyi https://maoyixie.com/ [1] Jakob Koschel et al., "UNCONTAINED: Uncovering Container Confusion in the Linux Kernel", USENIX Security 2023. https://www.usenix.org/conference/usenixsecurity23/presentation/koschel