From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 303AC33123D for ; Thu, 21 May 2026 15:46:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779378403; cv=none; b=dGSMIboTAWCbM4syccjQhxA5YXnlEyemslXgbiM6omDq4IscskQ4jquszl1TJTP/Q2DsnG8aH2+73+Lx7YBL3pwRcalf/EWN6ABJEBXWLFxDzWvnnIEyzsqnNnOna6SCCmnKiemoZBOHsCCnvkehMk2qk8+0NUs2YiPellKqsoY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779378403; c=relaxed/simple; bh=wvXDD1ma/iYRTVZ5bpg4r7exu5q5j5s1o/cAIPHrbPE=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=MnatHwCioditY+vg4robky4kDT2wCCXcb+2WJboVdGmLCyUCSDxv6Db7+0yUmW5Z1mxOzKfmnH8MLJJHy2ZC/2ZFKDvmFhrF9pok2Oe+7vMmHf3iQyvSF+nT6YCzblzZnK/uurhGrRoKQ1YG7uSk+KbVdjVe1JAiebB14vpwzAQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=KMN4jEMq; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="KMN4jEMq" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6082C1F000E9; Thu, 21 May 2026 15:46:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1779378401; bh=wvXDD1ma/iYRTVZ5bpg4r7exu5q5j5s1o/cAIPHrbPE=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=KMN4jEMqD0Gm1QA2vaaHePklRHefQZysxZ/4jJJ0k52zBNrGbn/gFghRBgqodfTWQ 7RwwYrDhnjn/jwEVC7lE9u5nKvCDaNw60aC8ON2CALLg19u/gxZFRoToizNsQ2v33l 8QM+j1axKXQ6JSvPWrTBISq91ePuT1hXPyAgXuQncr8srgx+nz6+zGbH5QEtenOFax HyUPg+HTqlIYMlJFyorddKWdPdiAMhulNtBFKBW/RFyUMHSmsIkFH8+C+02xXJwKQu kZtozPCkzHcVIeTpikuLQgclXMJp7l3cPbqSInklW+SXwUgt6TsOUI4xNu8S4uP9kK 447AM/edVb0eA== Date: Thu, 21 May 2026 08:46:40 -0700 From: Jakub Kicinski To: Jamal Hadi Salim Cc: Rajat Gupta , netdev@vger.kernel.org, davem@davemloft.net, edumazet@google.com, pabeni@redhat.com, horms@kernel.org, jiri@resnulli.us, yimingqian591@gmail.com, keenanat2000@gmail.com, 2045gemini@gmail.com, rollkingzzc@gmail.com Subject: Re: [PATCH net] net/sched: fix pedit partial COW leading to page cache corruption Message-ID: <20260521084640.683c1ee6@kernel.org> In-Reply-To: References: <20260519033950.2037-1-rajat.gupta@oss.qualcomm.com> <20260521073526.793d30c3@kernel.org> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, 21 May 2026 11:16:35 -0400 Jamal Hadi Salim wrote: > On Thu, May 21, 2026 at 10:35=E2=80=AFAM Jakub Kicinski = wrote: > > > To be precise, something like attached (untested, uncompiled) =20 > > > > Can we not pull the headers? Do you know of anyone modifying payloads > > with pedit? >=20 > not sure - but it is not unreasonable if someone used it for such a case. Ack, we'd still support modifying any offset in the packet. But not optimize for modifying frags until we know user exists. > > The concept of "shared frags" is silly IMHO, if I'm checking right only > > rxrpc and xfrm think that it's a thing. I'm hoping to delete that and > > reclaim the flag id in net-next... =20 >=20 > All these issues stem from the shared frags point, but the patchlet i > showed is unrelated to SKBFL_SHARED_FRAG, it is more related to > cloned+frags. Right, right. Just pointing it out cause Rajat's patch adds another skb_has_shared_frag(). Which we'll then have to delete in net-next :\ > If you remove it in net-next - does that necessitate removing all > "fixes" that tried to address that issue? It seems like that would be > sensible, but it makes me wonder why the shared frags concept exists > in the first place. IDK. We have in the tree plenty of "good ideas that went nowhere".. As I said elsewhere IMO having the maintain this flag correctly 100% of the time will only create more CVEs, and there's no practical reason to optimize for frags not being shared.