From nobody Sun Feb 8 10:43:35 2026 Received: from mail-qv1-f54.google.com (mail-qv1-f54.google.com [209.85.219.54]) (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 E23741C84DE for ; Fri, 6 Feb 2026 19:56:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.54 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770407815; cv=none; b=i691K5X9y+RFYeH3DMBzc9XJ6e49E5jh6nMGho8hYqryhjG/UiF4il1p4W2kZN1hlrURR919dd7xZp1ZLGDNUOk60fMHYS1A7UQ6oO8DuYRI6fArhwCWl1UYfJqHmCO1E4xxS6AVZe7l5vpfLW3nOfIC1Id2CUR2NsVjO1Qhr2Y= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770407815; c=relaxed/simple; bh=yOiNt1aWz3rmuRvVHG/FxRWDdY/QOPIXXMSzVnqbyFk=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=BLVgmNv1O2EmouYUDrZMrQFBR1/SyC8xm02kre5I0AeXWSXAvAaPoQkyZW5pMuL2HMi5PcPltvRIs1rJUPZ/fIVLC7JzFAWPj46AIicB9hjb2Gngkw01dpOHUGrWsXrC51Nt/cHpbOOUe5I+yB7uWq+svQ9AW0tEJtXaXVk1yw8= 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=ARqKUE7Y; arc=none smtp.client-ip=209.85.219.54 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="ARqKUE7Y" Received: by mail-qv1-f54.google.com with SMTP id 6a1803df08f44-88a35a00506so18109606d6.2 for ; Fri, 06 Feb 2026 11:56:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1770407814; x=1771012614; 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=B6IArvx0vdf7oFz1KRMa/JnNwWUDCFupKTsMgFUEvU4=; b=ARqKUE7Y2Ha7e7zYJTLhGEYwou/S8xCdZm7AhclSZCXuTIz1yvm4T5nwbWLCnno8pm 0p1ubaKrygoCOftkR7ALrIaoEHpWD7w/lQlIvlOvOEm9v3X+JbUYzd+Ra7cBWCSXAdME FkVF2LfUmLqinnzcbHJkQ64D4th+0DrqXuBRvkb1eBGyIGSgjAumQ8ex5hKkanyxmRmQ 35k3jl9RSYSn5v113AdGqZagl7C7K3x3hPxA4qP0zFUhjTroKAwuAqsb/zUBs5cRVT2M oTAE3x62aIL6DT9tLvArY6zGfiAkGXKg3Z06UxeO8nAOiRUaH2K3IRv5YgpOcsvPeuU1 LKgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770407814; x=1771012614; 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=B6IArvx0vdf7oFz1KRMa/JnNwWUDCFupKTsMgFUEvU4=; b=beYUhcGnBZ8TDvCvJsH/ZsMd7bpoPokwX8f8hkav50HrnimBLeKPlqOz/f5lX1hmwS lzZxOEBig48TlxwnnCrPlUtIVa09Dor00c8Hfo1LOmDhFmcpB4amcprNfiUHAARoCTFC Aeiz/9ix0IH12ofnBt6pVqRKNO8l1A3UnvOkNitRdc/E7/SyPJ+TgzHwZxlMg8FCrzQv ILMzlbKKh5C3PtsB5xSc6teJHy0WfjLNv1c5Y1FCLvN7lYBykJ7koI0EV+xX6cZzarqC E8kiSFlS5b4mQ6u+jSuA5gnihD6xCR0jYP9HooeRkBOVPvO/U7xOp6yfdKGZKgbuV2S3 QlEw== X-Forwarded-Encrypted: i=1; AJvYcCWm34B8ClDtF3zS831z4lyprnpONH33wC/6OlOEs45pjUTe4ErUZYbxJ2zpNc8Rv/epQUKRd3HaZYhBm7c=@vger.kernel.org X-Gm-Message-State: AOJu0Yx5/E99lfP3uwMseklVUldSxa9G60qhi4xKOUrA/nE6wlhct4V7 zvRQgpOYf3nT9vkeFH7vKxV0S4dbpZgD5uQPLCzSKdQY1q/qc2jyfFSJ X-Gm-Gg: AZuq6aKJxbzu2+L9liJBC2Tx2JwwUGljB3AVUxwDTlx9uKxLex+AWGwzzKPCPjL7zBN vz/4pltWrTXP0IjSMW3q3iCuNml4nX3n6MsenhP9SCSQVEpWkXXL5rrYcwtp/J5l3gfxG/D1xVf ZFg3oPH/gke6OYgnh6WzDvnwQtXToMS7EGPBodwqkM60amYPFWKLZO+4L7vUOOurfBY87wElmiM SjPlClc2H44BuV56AS0yDU1qWVJcyK2kfHpXAPVJHftQJfsLdsEd+Y/sJGjes0dRbDVFWW8uGAX QcE2Ut08TNRsy0ucXuSHPJUn6dpmXYZxzCEqyFRMyFlhaFevnrR6CDgSXwiplUNE+FWUyPUZF3b c1/EjQhWJAbe8ydQqFyrN6FghYUS7fdjuHnpdWR9zQSarFvhJhfstQDcNl25YyiM6TJm9FqmtmN Lh5ef7xNL8ST5OD9gc/8BJa49/Fc0lPv8vWqAMGU55AHJ8tooacvkR+J31kTOpd4fAwc9kfjUOe Ec= X-Received: by 2002:a05:6214:e6c:b0:894:68fa:37e6 with SMTP id 6a1803df08f44-8953cd9897cmr55323726d6.58.1770407813759; Fri, 06 Feb 2026 11:56:53 -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-50638c37b75sm23139701cf.0.2026.02.06.11.56.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 06 Feb 2026 11:56:53 -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 v2] net: stmmac: fix oops when split header is enabled Date: Fri, 6 Feb 2026 14:56:38 -0500 Message-ID: <20260206195643.11333-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 --- 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..8adc02003517 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->has_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