From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f46.google.com (mail-wr1-f46.google.com [209.85.221.46]) (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 30CD640B395 for ; Tue, 9 Jun 2026 12:43:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.46 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781009020; cv=none; b=B0XEr96PUrhtnpA+G+zZn+R4oGqk+hJYDqR6266ug0zBa28Ix1WUUHUpNBlV83dS93zCx8FiJW435yMDYxNAkqxWMFkTPyS6gUHGvTgLLMfILcbQFh3o87kR4SHd/Te/BBZJMZJudQNf7wDzP3x0IC4j6tmXWzbZiojsOzEISmQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781009020; c=relaxed/simple; bh=r87AOgf09jBawFk7Oijp6ve8K4PXrB0C8y80U0hyvYY=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=oqv5bRamz7hpdxROI2JnnqJeWBv1TeuaQLvldMAscMClQ3Uz0E84+k+UomsRcq6U+2kNHR2oFuXJhkCb4spcNaslb335b9c889yJVZUcxv4cROH19hnVaSoKrPUU1d7ityqtCiPK9Negv0bnJzBfq3R1TjGJMM7McA1qzHY0WT0= 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=A72kV2gu; arc=none smtp.client-ip=209.85.221.46 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="A72kV2gu" Received: by mail-wr1-f46.google.com with SMTP id ffacd0b85a97d-46013161068so2740077f8f.2 for ; Tue, 09 Jun 2026 05:43:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1781009017; x=1781613817; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=kX0FouJIIFyZjl2k/xAPoma1e0chrivslO1nWJVjm1U=; b=A72kV2gueiUXShVnAFagtIoPsLnTEa3A8dCCgQXPKJBWG6IkUN2QHHl1CLX3hqr4vH uEhqBTqIknZ6+y1xTEHVudrjG33b73eWBabN6IJ0jrYu+7WGPoorxvSZdS08LlXeBPI9 pWCLm+VYqQEBKrH742GuK5UnUk/DesrNflzxYhtUaDXDLG+QpNWvymRNSnbMKsNt5ATq W3eOm7MY7d9Hmj41DdrJ5dgRQrAZ/+d/s+j4p6YdwN4tIx82SUDOFrYYEyf6bIRNu1l7 f6/A4rimCgAUiG0ZSiGJdZUK+1UdevfS19CbaxSU/S5nSupBPLr/68joQPCPT4vJT8Bb PyLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781009017; x=1781613817; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=kX0FouJIIFyZjl2k/xAPoma1e0chrivslO1nWJVjm1U=; b=AyBXAXHY7B1WmHUZkt2d7BhzW/Kr1+8UNGoyb1qeluJ/2f/ehcfvcaBDDB8XzzJqxM ySMuVRVhrXwH4p2Q5cpQFk0+f2YBAFTvCTRdU2iDTif0Gtt6UpOA97/Un2jGPdtNJPED y+Py5bMKtPgogZ+tS4uigt9iF175fLLgUDMmUwvE32gTbbjTw6OJZ/OR3t/vRJxxlzO4 OotZilugMq9TkY7hmDZU5Tzw6OL3Q8wgCs/P8fuLOxiewL29yxRdsTCa9OMj8kCTJ2rb VnR7t//YkgcCdfEX9Fk3TsQ+Kh3u7w+/StJlXCG6B+Ji7f/UUemFCQGR1hPXcelYV1K2 LGwg== X-Forwarded-Encrypted: i=1; AFNElJ9Z93KtciXK9jt6rZoYyvKPPMgPxP7Wo0QTPREtMSYBOsF0oP4kAsC980e+QJPaaEZ19ShP9jl/4qMXffQ=@vger.kernel.org X-Gm-Message-State: AOJu0YxsyvsBdMvzU/k6KQYLDvIoPKHLQuGOYG54RQFxKrf8N/V5Fl7r d0+KWbcOe4YAPNbPLz7/1csm8GecgSrhrTPYRXh7Q6l0AmIE/mRFS8gO X-Gm-Gg: Acq92OHwzdL+psEq31G7sqQEwAX+Jkpm/yZYG5pRa3a04hxvGXtN0MxLVXkwZxmh4BZ VmGRSMnaVk/bNPDOD2hQxkIQxARIpTpMMiIQ3KsVZpJ3UXXFGMZEQja+x+lAtc3cA4iYhaL34Jl PEWG8w7ipC5faX+WLtu2MHVhJbRzwB44YUZ7p/prLr1x/zNGXzJ2oCESxtr1w5rHr7GZHaYiYpH ZFpq/P54drR0xtMM1lRHJBg9Ynk7KIxHS9YI4wG1Snu6jwuSTlPTnnDqjD8tXd/O8RGCDcfPKrd 7An5giisPuapxwuQzHLBQPqKbcYhSk0gRSoMSle5JLNjKyy+gU3DXugqbsBfDwL9hbR06cp04YB kwYXuNsqjvdQRXKyAx9Uzx5EkA8tfuw+n8SDp/2etX/wqKB6GFyM8uA9efOzZmGUiI7Z1AIoDqj 0GzboWvlx2Lmc8TLhL40XlLxBPQ8IfQNDjpIjLRchuBdJMbHAmOT+Javu1efvgoVKRTYLZTWE= X-Received: by 2002:a05:600c:3495:b0:490:bf1a:ed04 with SMTP id 5b1f17b1804b1-490c258995fmr317840935e9.1.1781009017249; Tue, 09 Jun 2026 05:43:37 -0700 (PDT) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4601f2ec711sm60328903f8f.12.2026.06.09.05.43.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 09 Jun 2026 05:43:36 -0700 (PDT) Date: Tue, 9 Jun 2026 13:43:34 +0100 From: David Laight To: Justin Lai Cc: Simon Horman , "kuba@kernel.org" , "davem@davemloft.net" , "edumazet@google.com" , "pabeni@redhat.com" , "andrew+netdev@lunn.ch" , "linux-kernel@vger.kernel.org" , "netdev@vger.kernel.org" , "stable@vger.kernel.org" , "richardcochran@gmail.com" , "aleksander.lobakin@intel.com" , Ping-Ke Shih , Larry Chiu Subject: Re: [PATCH net v2] rtase: Workaround for IP fragmented UDP packet hardware bug Message-ID: <20260609134334.3225b076@pumpkin> In-Reply-To: <1340406ab190498ab857ad9017529722@realtek.com> References: <20260604101356.15611-1-justinlai0215@realtek.com> <20260608190627.182292-2-horms@kernel.org> <1340406ab190498ab857ad9017529722@realtek.com> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) 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=US-ASCII Content-Transfer-Encoding: 7bit On Tue, 9 Jun 2026 08:20:10 +0000 Justin Lai wrote: > Simon Horman wrote: > > > > From: 'Simon Horman' > > > > This is an AI-generated review of your patch. The human sending this email has > > considered the AI review valid, or at least plausible. > > Full review at: https://sashiko.dev > > --- > > rtase: Workaround for IP fragmented UDP packet hardware bug > > > > The hardware parser incorrectly interprets 319/320 in a short IP fragmented > > UDP packet payload as standard PTP destination ports and treats the fragment > > as a PTP packet for further parsing. Pad these packets so the transport data > > reaches RTASE_MIN_PAD_LEN before transmitting to avoid triggering the > > hardware issue. > > > > > diff --git a/drivers/net/ethernet/realtek/rtase/rtase_main.c > > > b/drivers/net/ethernet/realtek/rtase/rtase_main.c > > > index ef13109c49cff..b686b84e15fe2 100644 > > > --- a/drivers/net/ethernet/realtek/rtase/rtase_main.c > > > +++ b/drivers/net/ethernet/realtek/rtase/rtase_main.c > > > > [ ... ] > > > > > @@ -1247,6 +1248,52 @@ static u32 rtase_tx_csum(struct sk_buff *skb, > > const struct net_device *dev) > > > return csum_cmd; > > > } > > > > > > +static bool rtase_skb_is_udp(struct sk_buff *skb) { > > > + int no = skb_network_offset(skb); > > > + struct ipv6hdr *i6h, _i6h; > > > + struct iphdr *ih, _ih; > > > + > > > + switch (vlan_get_protocol(skb)) { > > > + case htons(ETH_P_IP): > > > + ih = skb_header_pointer(skb, no, sizeof(_ih), &_ih); > > > + return ih && ih->protocol == IPPROTO_UDP; > > > + case htons(ETH_P_IPV6): > > > + i6h = skb_header_pointer(skb, no, sizeof(_i6h), &_i6h); > > > + return i6h && i6h->nexthdr == IPPROTO_UDP; > > > > [Severity: High] > > Does this check fail to traverse IPv6 extension headers? > > > > If an IPv6 packet contains extension headers, such as an IPv6 fragment > > (IPPROTO_FRAGMENT), the nexthdr field will contain the extension header's > > protocol number instead of UDP. > > > > Doesn't this bypass the workaround for the exact fragmented packets it is > > intended to fix? > > > Thanks for the review. > > Unlike IPv4, IPv6 does not require extension header parsing for > this workaround. The hardware only treats IPv6 packets without > extension headers as PTP packets for further parsing. > > Therefore, IPv6 packets carrying extension headers, including > fragments, do not enter this parsing path and are not affected > by the hardware issue addressed by this workaround. > > Skipping such packets is intentional. I thought you said that the problem only arose with packets that are fragmented by IPv[46], in particular short final fragments. If your hardware checks for extension headers then doesn't that mean that you never have a problem with IPv6 packets. -- David ...