From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-184.mta0.migadu.com (out-184.mta0.migadu.com [91.218.175.184]) (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 D807E17745 for ; Mon, 29 Jun 2026 01:18:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.184 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782695923; cv=none; b=kdhisSVxhRif1uJEeLYE2hg3kWLBbV3dceEn135UFjpdPobEdH9FGO5dDTX3Vj0wKofrgJ3rf4x5u3lxOHAdhc4yRHmQsFH8z8bKSDjqG9AhR6CVhVfhaj5McXywKYbpPdxwEPcJOayCkhVNVzBCu9wpikqP2Ieu2rYjNjGNt/4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782695923; c=relaxed/simple; bh=JJPvMl3C5EwiyNDQZfdSCn+pGhz8kCdu5r0Z2+2OqBs=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=NO3bpXL5qGFC9K2rBmIw0HdQktxV5UD5dTVGgqISBfEZth4P+qq1uMGc5+ROk0Tn5ALdQJtCM6ZF6ZuH7OiqncnMCBmsQIb0P0wjTtlFhIrgyn1A1zfelobxsMAYad2Qb47JFSVhYBjQneWEKsQCy2Y7d6EijlJNwJYKdQaD8xE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=uLNt3yQb; arc=none smtp.client-ip=91.218.175.184 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="uLNt3yQb" Message-ID: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1782695918; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=92MI5kENEF5zQ2yYEaLwm6Sik2fV4GEydFbExF+S0wk=; b=uLNt3yQbcl+GpCAxTenm6oZ8MecAQCxbpGIjarrFZkALrW31IXszZNsfL0VsL2RqgIp5H/ dIb9vunYRthU05oTL4xw+tXsJRbGogeMHnsaDs7XK+TLGdzRrW72UD62BBbr+ya5YchMko U9j7DJ00T+T0OEsOmfDMPVmDdArJdYI= Date: Mon, 29 Jun 2026 09:18:22 +0800 Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH bpf-next v2] bpf, unix: Guard sk_msg-dependent code behind CONFIG_NET_SOCK_MSG To: John Fastabend , Jakub Sitnicki Cc: Alexei Starovoitov , Amery Hung , Kuniyuki Iwashima , bpf , Alexei Starovoitov , Daniel Borkmann , Jakub Kicinski , Network Development , kernel-team References: <87v7b9ysep.fsf@cloudflare.com> <87mrwlyqg4.fsf@cloudflare.com> <878q85yoy5.fsf@cloudflare.com> <87cxxey09d.fsf@cloudflare.com> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Jiayuan Chen In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_OUT On 6/27/26 2:04 AM, John Fastabend wrote: > On Thu, Jun 25, 2026 at 07:53:50PM +0200, Jakub Sitnicki wrote: >> On Wed, Jun 24, 2026 at 01:57 PM -07, Alexei Starovoitov wrote: >>> On Tue Jun 23, 2026 at 6:32 PM PDT, Jiayuan Chen wrote: >>>> >>>> Hi Alexei and Jakub, >>>> >>>> skmsg is actually still pretty useful for gateways. >>>> I started with bpf by integrating skmsg into nginx as a module and >>>> envoy >>>> has something similar. >>>> The usual setup is cgroup/sk for L4 bypass (reject SYN), and skmsg for >>>> L7, redirecting >>>> between local apps by looking at the payload. So there are real users. > > Interesting. > >>> >>> ... >>> >>>> Agree, just like we remove skmsg from KTLS which is rarely used. >>> >>> ... >>> >>>> Hope not have skmsg disabled by default. >>> >>> I wasn't suggesting to delete the whole skmsg, >>> but to disable combinations that are causing issues. >>> Like what was done for skmsg and ktls. >>> I'd allow plain tcp and udp sockets only. >>> Allowing unix sockets was fishy. I think we should reject it too. >> >> For unix & vsock we know Bytedance built a proxy using it. >> We've been showcasing it as one of sockmap use cases [1]. >> That said, I don't know if it's still being used or not. >> >> If we don't want to go through the config-knob-then-deprecate process, >> then I guess the only option is to kill it and see if anyone complains. >> >> [1] Slide 117, >> https://github.com/sockmap-project/sockmap-project/blob/810d259af6e7a5793922af3991c9dc7ff502fe19/talks/2024-09%20-%20NDC%20TechTown%20-%20Splicing%20Sockets%20with%20SOCKMAP.pdf > > Most the bugs I'm seeing are combinations of push/pop/pull/tail/head > calls over sk_msg scatter gather list no one ever considered. Or at > least I never considered. Add in additional socket combinations that > came later and we get bugs. IMO, the helper has issues, but it's simple. We can test every edge case, so problems will be resolved over time. > > Do the nginx/envoy offloads manipulate the scatter gather list as > well? > We use a helper to insert an HTTP header to mark that the packet has been processed by BPF, which helps with debugging and tracing. > Do we need all these helpers? At some point I thought I was going to > build a real kernel proxy with this, but never did it. Another option > would be better test framework. > > .John