From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yw1-f169.google.com (mail-yw1-f169.google.com [209.85.128.169]) (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 06FED3939B8 for ; Mon, 9 Mar 2026 10:46:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.169 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773053176; cv=none; b=Lr+6u0yPo1lrcbz4nGuKAgG+jTsSmn55T6axWzSTQR2gQODHfnNDpsuiwT0Ovbr15XYBkIL+tBLzYOcOajx/7PSFzXqehvf3za8/d7I/adqARQOZnFYIJmWtMpMW6OWqFl/o21/gBproq/JsOZrfKuwTYi5CBToKp/TdV1TWj0w= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773053176; c=relaxed/simple; bh=o7zitKHdQAd9c2Tsyz3y+v+M/geb+4XgWhFo6cmTvJc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=IvAPCH2MllNXEy4uo0j72OQIEhjLGYm/kqoXl415irIPtTZp2Esc54wBg0LwIlOoA2MPWQCb6rySKRFvuXlOeZnfk4IPt1CM7jeVezfsMICwQff8UYBpMU8Ia8pQw6G1pafIww8WmXBUa4jZG6TSWvypaItHClOjZxbqkUlcPGE= 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=I2k+OyIA; arc=none smtp.client-ip=209.85.128.169 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="I2k+OyIA" Received: by mail-yw1-f169.google.com with SMTP id 00721157ae682-79900d6dc3cso4216017b3.3 for ; Mon, 09 Mar 2026 03:46:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773053173; x=1773657973; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=BZg1yY5ls1mtKKFKgOw9TLLgLzir1wngFNkwG/M8ZHo=; b=I2k+OyIAvNJbLV+mFqiAY5UfIw2E8zQjFIhuBGPQMlyYHx82YqZ4zJMsMpDuN9Z/R9 y31CPectduwyrgAz6+diCJJK4/3dJqN0QyFcLzlDXsMl0wrcggWGa8gchNp7H8Gpqj5V wWidMjdcUjWw9Tfh2zBDsY5pIMyY5hh6Ki5UzD2yn+QSdQnI9ZT5yb+6Gt036qU5OLU9 L3UO5GUxfFUJwHApT6cQNFhe2sLc2VquPK469w8b4d1e0r4ij4dlxfXALX4R+dAKi+qc b/MkXJWjACa+FAPdmR+O657ddiiUGYK+RrjutpG5i0sHGV8Jtp/jvckD14S6MaywS//9 D7cg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773053173; x=1773657973; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=BZg1yY5ls1mtKKFKgOw9TLLgLzir1wngFNkwG/M8ZHo=; b=vl7zSYsSUf+jTW5OyfYc6tcdbo9+VCqLLfGarFkKU60oPZ/MrMV49l6D/pQEQi/T6P +njIzlL2DenGGU/0Cdgwt8KwsViCAA3sBlrv+6FJU4xDp9LOLx4odGi/RYy7uCkpYEdi KYwo7Rz6zQycz7loJaDu6Lp/xPoKp6LQ+8Y/0adxm06GkgIiDzrYW7gAO8Bv+XToSaRs xaUyzd9xSa1cn0tC2r/+rtkroZhc05cLzuA2kBsDNjEUp6XTNvfIpcv0Zn8IS7T3CcW8 tygmsQKQ8vTM8o0SyhvbeDhwcyoIOtrG7AhbhtZTBNG9zb7iqfy66/wbG+p7/vMuHfPO MZmw== X-Forwarded-Encrypted: i=1; AJvYcCV3khHAtHj3n5SO/wZP3ZxXD7Pt/7ihBn+8f+NfsL4TBt4/SVkEKRU8m+71HAIUQc+QAfemnp9sftxd4nU=@vger.kernel.org X-Gm-Message-State: AOJu0YzDzKdq4H3CymwwiOdxQ387bTrFffVuHxJG0Y5icIA93mi7K8Or puCQJpWmn9s7oRaIOOvo4ueMRWFkkCXgdq4flbtCy5/iqj793b7XDYu/VdKu44m5OyildQ== X-Gm-Gg: ATEYQzzw/A50d4di2CkzrorZhwOSiw2yaYzFIWis2dzqB/AuvJ1BgPTiHjHIKk48yGy 3du7QVHz6Rp/xFc3PYkQl0PWJhT1RguM4WrNWTNjeiZ6ocsEw7Mo/ZCmPqZuEfLbD8klvxIEWw/ aAd3YUeLIN+DKQyO0wd5sj0jvOwAkmdtoqd1QLXl5877JApkGM3WjaxpRDtsO78Zttndw5iY+0w FAw9vKmjQ2H5MST0EUuWUIxB4owrUce49laqZr3Gg1JI74mrk/NzBtl0Zsbc/KYJvmWbruHjftx UERx3iMciWhVVes3okM5j2rrg8rhsZaHiIRlAXTI3nA5j3uudS+qWNMVe3JcAXdgdgUoY/eTrZC 3vNOPjGWlNhsi4elpFelkIlZENZSiNDQXcNicwrJSW7oOpSkjGq0skIoQZXP4saC7Xq4XbLQUEO iu4eR4H7FWFFWRBg2bHpuZow== X-Received: by 2002:a05:690c:c52e:b0:794:cf56:5bc4 with SMTP id 00721157ae682-798dd7967acmr94008297b3.43.1773053173020; Mon, 09 Mar 2026 03:46:13 -0700 (PDT) Received: from localhost.localdomain ([2a09:bac1:76c0:3d0::26a:dc]) by smtp.gmail.com with ESMTPSA id 00721157ae682-798dec8bba7sm44033197b3.2.2026.03.09.03.46.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 09 Mar 2026 03:46:12 -0700 (PDT) From: =?UTF-8?q?=E5=82=85=E7=BB=A7=E6=99=97?= To: johannes@sipsolutions.net Cc: linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org, oscar.alfonso.diaz@gmail.com, =?UTF-8?q?=E5=82=85=E7=BB=A7=E6=99=97?= Subject: Re: [PATCH] wifi: mac80211: fix monitor mode frame capture for real chanctx drivers Date: Mon, 9 Mar 2026 10:45:59 +0000 Message-ID: <20260309104559.22252-1-fjhhz1997@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <8155c8f93c233e430c75c98bcdaea219b16e9596.camel@sipsolutions.net> References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On Sun, 2026-03-08 at 16:45 +0000, 傅继晗 wrote: > Fix this by falling back to the first entry in local->chanctx_list > when the monitor vif has no chanctx and the driver uses real channel > contexts. This is analogous to how ieee80211_hw_conf_chan() already > uses the same pattern. On Mon, 2026-03-09, Johannes Berg wrote: > I did have pretty much the same attempt at a fix: > https://lore.kernel.org/linux-wireless/20251216111909.25076-2-johannes@sipsolutions.net/ > > but it was reported to cause crashes on certain devices, so we didn't > think it was very safe at the time. > > Is that no longer an issue? Hi Johannes, Thanks for the quick review and for pointing me to your earlier v2 patch. I see the key difference between our approaches: your v2 iterates the chanctx_list and only proceeds when there is exactly one entry (going to fail_rcu if more than one exists), while mine blindly takes the first entry via list_first_entry_or_null(). Your approach is clearly safer -- in a multi-chanctx scenario, there is no way to know which channel the user intends to inject on, so refusing is the correct behaviour. I have tested my patch on an MT7921AU (mt76, USB) adapter across v6.13, v6.19, and v7.0-rc2 with managed + monitor coexistence, and have not observed any crashes. However, my testing was limited to a single-chanctx scenario (one managed interface + one monitor interface), so it does not rule out crashes in multi-chanctx configurations. Could you share some details about the crashes that were reported with your v2? For example, which devices/drivers were affected and what the crash signature looked like? That would help me understand whether the issue was specific to multi-chanctx usage or something more fundamental with accessing the chanctx_list in this code path. If you agree, I would like to send a v2 that combines both approaches: use list_first_entry_or_null() for simplicity, but add a list_is_singular() guard so we only proceed when there is exactly one chanctx -- matching the safety constraint from your v2: --- a/net/mac80211/tx.c +++ b/net/mac80211/tx.c @@ -2399,10 +2399,24 @@ - if (chanctx_conf) + if (chanctx_conf) { chandef = &chanctx_conf->def; - else if (local->emulate_chanctx) + } else if (local->emulate_chanctx) { chandef = &local->hw.conf.chandef; - else - goto fail_rcu; + } else { + struct ieee80211_chanctx *ctx; + + ctx = list_first_entry_or_null(&local->chanctx_list, + struct ieee80211_chanctx, + list); + if (ctx && list_is_singular(&local->chanctx_list)) + chandef = &ctx->conf.def; + else + goto fail_rcu; + } This avoids the ambiguity of picking an arbitrary chanctx in multi-chanctx scenarios while still fixing the common single-chanctx case (e.g. one managed + one monitor interface). Alternatively, if you would prefer to revive your own patch, I am happy to help test it on mt76 hardware. Thanks, Jihan