From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailtransmit05.runbox.com (mailtransmit05.runbox.com [185.226.149.38]) (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 341F31A2C04 for ; Wed, 6 Aug 2025 21:15:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.226.149.38 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1754514953; cv=none; b=iLsn/casb61EVf6vpkXxBHcBm0Db+RiTBdltt8kk3zNlo2tvIdGW0oJjj8AgscTE/BC2A5fjqy4w9/yHDZRoR4v6AFQwwU2gyjo4FW2/63uP++Bwk2vxAEXr4dDP2WChWrbFjLw5mZQ309wDWkOi1KVEtuCKAbUdTT01kMpuqBA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1754514953; c=relaxed/simple; bh=XG2iaiadFFnq9XwRGdlA5z9IM93Tsw6Fk02sG4YudNo=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=uyf3BKLqGgNWB9MGj3vyHpaxEqlGdUNDIh/Zp0Hj3PfqrGp6f4Ngr8qV7xWaENZuJTTuScKJ4XyQNfL2oNzFmQKTeOk4UB+vIpZmkiFle8+Qfea6xmGBIkalKptiLHwVRxjGB07mPV2goz45Jz4sXr6wajdArFEOud0d0uR9jL8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=rbox.co; spf=pass smtp.mailfrom=rbox.co; dkim=pass (2048-bit key) header.d=rbox.co header.i=@rbox.co header.b=TR2mvOlj; arc=none smtp.client-ip=185.226.149.38 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=rbox.co Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=rbox.co Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=rbox.co header.i=@rbox.co header.b="TR2mvOlj" Received: from mailtransmit03.runbox ([10.9.9.163] helo=aibo.runbox.com) by mailtransmit05.runbox.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1ujlTy-00EGQY-Nh; Wed, 06 Aug 2025 23:15:34 +0200 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=rbox.co; s=selector2; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID; bh=JEAvvLpXo03U5nTOjudQP/w82ZK7J9xTsTdVQJuUPT4=; b=TR2mvOlj/ssM041N+Pq0I/2VhP ZYKARAxo1LGGfMByB7Xg5O/GSN6ltAq2BPKvnxsFNp9DUuSV9TVlK+Dank/E/2ZY+cBgG47o4KdUF tEnMOueLFj2AXzcjMQUHyYHYDhJ386E37KECg3w91t5YP8McSQi+LXzH/tAJvH9kGNstTpScwigzX rkP6pkmG+IcqQFRdGi7JpGFtvoyQdMj3xUHjXFT1cC0zEltgcKQZ8HZXgkndNXoOAU583mqNNAn47 /K99dHNuyrUSpZzMU0pzEkA6fjuiEbjmNic7KNFqloTwQ4LIFpzL3Umz69HYaSl4x4DePmsoaX3pO Nx4ZbeDw==; Received: from [10.9.9.73] (helo=submission02.runbox) by mailtransmit03.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1ujlTx-0000al-Fo; Wed, 06 Aug 2025 23:15:33 +0200 Received: by submission02.runbox with esmtpsa [Authenticated ID (604044)] (TLS1.2:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.93) id 1ujlTn-00BdRi-Ua; Wed, 06 Aug 2025 23:15:24 +0200 Message-ID: <54f5b076-4648-4d2b-b50b-e775c4ddb4bf@rbox.co> Date: Wed, 6 Aug 2025 23:15:22 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH net] kcm: Fix splice support To: Jakub Kicinski Cc: "David S. Miller" , Eric Dumazet , Paolo Abeni , Simon Horman , Cong Wang , Tom Herbert , netdev@vger.kernel.org, linux-kernel@vger.kernel.org References: <20250725-kcm-splice-v1-1-9a725ad2ee71@rbox.co> <20250730180215.2ad7df72@kernel.org> <20250804165155.44a32242@kernel.org> Content-Language: pl-PL, en-GB From: Michal Luczaj In-Reply-To: <20250804165155.44a32242@kernel.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 8/5/25 01:51, Jakub Kicinski wrote: > On Sun, 3 Aug 2025 12:00:38 +0200 Michal Luczaj wrote: >> On 7/31/25 03:02, Jakub Kicinski wrote: >>> On Fri, 25 Jul 2025 12:33:04 +0200 Michal Luczaj wrote: >>>> Flags passed in for splice() syscall should not end up in >>>> skb_recv_datagram(). As SPLICE_F_NONBLOCK == MSG_PEEK, kernel gets >>>> confused: skb isn't unlinked from a receive queue, while strp_msg::offset >>>> and strp_msg::full_len are updated. >>>> >>>> Unbreak the logic a bit more by mapping both O_NONBLOCK and >>>> SPLICE_F_NONBLOCK to MSG_DONTWAIT. This way we align with man splice(2) in >>>> regard to errno EAGAIN: >>>> >>>> SPLICE_F_NONBLOCK was specified in flags or one of the file descriptors >>>> had been marked as nonblocking (O_NONBLOCK), and the operation would >>>> block. >>> >>> Coincidentally looks like we're not honoring >>> >>> sock->file->f_flags & O_NONBLOCK >>> >>> in TLS.. >> >> I'm a bit confused. >> >> Comparing AF_UNIX and pure (non-TLS) TCP, I see two non-blocking-splice >> interpretations. Unix socket doesn't block on `f_flags & O_NONBLOCK || >> flags & SPLICE_F_NONBLOCK` (which this patch follows), while TCP, after >> commit 42324c627043 ("net: splice() from tcp to pipe should take into >> account O_NONBLOCK"), honours O_NONBLOCK and ignores SPLICE_F_NONBLOCK. >> >> Should KCM (and TLS) follow TCP behaviour instead? > > I didn't look closely, but FWIW - yes, in principle KCM and TLS should > copy TCP. Ugh, so this KCM patch is incorrect. Sorry, I'll submit a follow up tweaking KCM and TLS, as suggested. Note about SPLICE_F_NONBLOCK: besides AF_UNIX, it is also honoured in AF_SMC and tracefs.