From nobody Tue Feb 10 09:25:00 2026 Received: from mail-qt1-f176.google.com (mail-qt1-f176.google.com [209.85.160.176]) (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 8B62C30E828 for ; Mon, 9 Feb 2026 22:51:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.176 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770677471; cv=none; b=Fs7Sfu2SR6q1sfVpdUhZ2ZrdYlZcQ3bsHpztgN9V7aZN5vAkfFBWgmrrmLP2NLng1JuR27ewgGtmmeiFmtteV5m4XxAhichghPSi2XiCaIwbXdpCgA2Xum43iZ9tWXv7m3dxR8zntVHMCpRVX7tPWMm3Tjv7YpBHv5NqqMJc0jo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770677471; c=relaxed/simple; bh=6FoVXBBm/8Wo4jxEKVSL8pT+WGiQu5KbjsXqUY2KhD4=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=IQgXNtVT0JY8vI45bLayIyYGm2mq+Ia6ChYYbzRcrCvoeHSKxpgDIV9hxfAsa6Xc8SY4cvG6rW6sdf1iAFi2YZ6w3p+a4tDW+/Fkub9Dfpmd3sQRDo1+vEDcOnZNaTLeJhKs2jWn+E5Xq32UzO4/BsIgraytrX7ba26BHZVQLnc= 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=UkcDSlXt; arc=none smtp.client-ip=209.85.160.176 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="UkcDSlXt" Received: by mail-qt1-f176.google.com with SMTP id d75a77b69052e-506251815a3so42701441cf.0 for ; Mon, 09 Feb 2026 14:51:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1770677469; x=1771282269; 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=g+TvrkNSZE9ym2PFZpW4r5uQoR0rtxBqbUzuUkdsCDo=; b=UkcDSlXt3M1ZYjc0FnBVksKU/+dPvTkVng9foZT99Y8J33zBtV2jLNVM1O3VRG6ITH E0D26OkM8t0ISKGYNwpj0O2kVmSQGPN8GnNFReUyRsU3qN74GjtATiPRtTzehuTeh2B9 5pZS5hfeaTXgHL5SQUzeK0Ey+zRjfLG2SKn1CdnEnKbVEXwdDY3rM0Tkf2MSkuRjcg5I YspoARCOE8vRhX/JvAMtVvcAHdx4MZ7h87Umflo9VAoNYU49ecs1MDrExpGJPDGUbg2/ Wv/rylguQy/D2y0+Or7BUZEn+wqwgAsPmAcKuHPmvHHTSyqTJYb0Z+ykIphAVvfZtz7A w5tw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770677469; x=1771282269; 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=g+TvrkNSZE9ym2PFZpW4r5uQoR0rtxBqbUzuUkdsCDo=; b=jUSpH1hvqpRl85648NjwupuEI1EalecrsYLwM71PHGg/mfDPVeLsBBjjrMVLbtycb4 CQ+AGKvLT7qiOzoWS4vcDHjHuyDpf+/aplw41mRmfGrIFNVCgq15ylEtUOpXDQV2+rjs 74TL/THpu42uVZ7KZVgGE8frAgctOptyWf3jPinZJs35bJB+Psk39DOVwuULPLzDRw7F RtEOCNU61Sa5xFo4qME0RTe+nocFfJid4ZaAUBB7G/wj3u26KHEriiRhwm+3xw7laBpL mpzkAP0029xMkii3sWatcpgA6IJAbMGeEGCUd7HiV9lk8nGB8gXVimiyQDAC+ZpFafkx pENw== X-Forwarded-Encrypted: i=1; AJvYcCWylywTh60VII4u6HJzNNfS3KQJAtrPexCpvnajeGo+Z9KvydC0LTqW0wvOI7q/6GKi3mEq40VHX+jPUEE=@vger.kernel.org X-Gm-Message-State: AOJu0YxpUFlUKDbwkg4FVFEJQBaabHnl39Jr6Fgmk3iLrbZlMFarEw4j IsT0OPhQZGbBbwF0vPRfUTEITxBBCJpj5PL68Z3e+fzeEAkXPiYJQOLP X-Gm-Gg: AZuq6aIU7ciehadLl2OMpnBCLikOL0qByOo8Wznwrtb7Y/9d0KWQPM959NtkO0+DZwj Pxf0HFr/pg6Ry4tFAa5r0gJWwzVoKcRyyJ3zW/MQgnWX3u8lOtHKSgbTNz578S5wjj49dzNbNUR MRZv0hlc/088Dj55YCgnmyTOR03wvMyY/ag3dbvzELsj+RRaMtwo69Wjwosm5Fb/IBenvV4vxzK WD+GpXbqFDfr2IYJTcdawR1/7devx1jw0EJWgvjihQiVAz037a7bHv8SCCVVNAWW5WfPueY/Nbn t5XF50M0cFyBV8M3aewvK6kkHRRe42sdpe43Wg8RKTq2T7ijXp1AJvSQnSz31UzJPPahUplvMjq h96YLUVR1PZmPyfuuCggS4nH6v8N+VjgWU04LGD4hQd/QC8fuAzjgLjH+K2T8E+2I2qw0EWrit2 +AhNG1UrQBBJPEWbjka0pxWE1AQO/gjQh3FvvFxEbsSq9r8Qhb1ubvwq4mDC8g+vuVUAGiW2vq9 g8= X-Received: by 2002:a05:622a:314:b0:4ee:4a8b:d9f6 with SMTP id d75a77b69052e-50639999b38mr165019831cf.59.1770677469375; Mon, 09 Feb 2026 14:51:09 -0800 (PST) Received: from localhost.localdomain (h69-131-24-92.cntcnh.broadband.dynamic.tds.net. [69.131.24.92]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-50640c60b3csm87021861cf.8.2026.02.09.14.51.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 09 Feb 2026 14:51:08 -0800 (PST) From: Jie Zhang X-Google-Original-From: Jie Zhang To: netdev@vger.kernel.org Cc: jzhang918@gmail.com, jie.zhang@analog.com, horms@kernel.org, Jacob Keller , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Maxime Coquelin , Alexandre Torgue , "Russell King (Oracle)" , Maxime Chevallier , Vladimir Oltean , Jose Abreu , linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: [PATCH net v3] net: stmmac: fix oops when split header is enabled Date: Mon, 9 Feb 2026 17:50:32 -0500 Message-ID: <20260209225037.589130-1-jie.zhang@analog.com> X-Mailer: git-send-email 2.47.3 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" For GMAC4, when split header is enabled, in some rare cases, the hardware does not fill buf2 of the first descriptor with payload. Thus we cannot assume buf2 is always fully filled if it is not the last descriptor. Otherwise, the length of buf2 of the second descriptor will be calculated wrong and cause an oops: Unable to handle kernel paging request at virtual address ffff00019246bfc0 ... x2 : 0000000000000040 x1 : ffff00019246bfc0 x0 : ffff00009246c000 Call trace: dcache_inval_poc+0x28/0x58 (P) dma_direct_sync_single_for_cpu+0x38/0x6c __dma_sync_single_for_cpu+0x34/0x6c stmmac_napi_poll_rx+0x8f0/0xb60 __napi_poll.constprop.0+0x30/0x144 net_rx_action+0x160/0x274 handle_softirqs+0x1b8/0x1fc ... To fix this, the PL bit-field in RDES3 register is used for all descriptors, whether it is the last descriptor or not. Fixes: ec222003bd94 ("net: stmmac: Prepare to add Split Header support") Reviewed-by: Jacob Keller Signed-off-by: Jie Zhang --- v3: 1. Fix build error v2: 1. Update for the latest net HEAD 2. Reduce crash dump message in commit message 3. Add Fixes tag v1 link: https://lore.kernel.org/all/20251202025421.4560-1-jie.zhang@analog= .com/ --- .../net/ethernet/stmicro/stmmac/stmmac_main.c | 20 ++++++++++++++++--- 1 file changed, 17 insertions(+), 3 deletions(-) diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/ne= t/ethernet/stmicro/stmmac/stmmac_main.c index a379221b96a3..f98fd254315f 100644 --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c @@ -5023,13 +5023,27 @@ static unsigned int stmmac_rx_buf2_len(struct stmma= c_priv *priv, if (!priv->sph_active) return 0; =20 - /* Not last descriptor */ - if (status & rx_not_ls) + /* For GMAC4, when split header is enabled, in some rare cases, the + * hardware does not fill buf2 of the first descriptor with payload. + * Thus we cannot assume buf2 is always fully filled if it is not + * the last descriptor. Otherwise, the length of buf2 of the second + * descriptor will be calculated wrong and cause an oops. + * + * If this is the last descriptor, 'plen' is the length of the + * received packet that was transferred to system memory. + * Otherwise, it is the accumulated number of bytes that have been + * transferred for the current packet. + * + * Thus 'plen - len' always gives the correct length of buf2. + */ + + /* Not GMAC4 and not last descriptor */ + if (priv->plat->core_type !=3D DWMAC_CORE_GMAC4 && (status & rx_not_ls)) return priv->dma_conf.dma_buf_sz; =20 + /* GMAC4 or last descriptor */ plen =3D stmmac_get_rx_frame_len(priv, p, coe); =20 - /* Last descriptor */ return plen - len; } =20 --=20 2.47.3