From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com [209.85.128.49]) (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 3D07548C417 for ; Wed, 3 Jun 2026 22:43:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.49 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780526603; cv=none; b=DE+FwFdQR8x6FZe8kQwlQIGkUvYkns1lR/2SkMTT8JwzP0wJDIukxJg1reVuvDI9SPzPA1jI8EUiYhIB+HsSQYkAxoLJzpjBgkhO9jhzhejFeZaNA7l0cxRx4quiSbt1dYRbhUeayje3/jgcV6+sstCunEseemm/QOvsa58mumc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780526603; c=relaxed/simple; bh=bpSKopOh+lqC+IlYALKlFknmtsR6CYYa845dkB+uwqY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=RF2e5DhK0o9ziYBssAAtupUmpcYU2ri4irxmnpb0I8Q7/oFFZ2U/9kJaK/t1ZSGYYlcztDKdDbZh9M+OlpwPK+OVvrwCU5tEU2sXuTtLHFGXme8jEygIWLMBskfarIejRw1weSWt6hmHHVl2tcX+PG/LsYw3D+vVtx9e8ZwN4ow= 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=Wjj7uirC; arc=none smtp.client-ip=209.85.128.49 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="Wjj7uirC" Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-490b1bbcf3aso530645e9.1 for ; Wed, 03 Jun 2026 15:43:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1780526601; x=1781131401; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=iTE44OxcHCqYjYX+doIy+3NqUmI4SQrZkrHVFocDs+M=; b=Wjj7uirCmuM3oEx9Vkzc5+uo+3QV5z2Tw+aUW7f5mIXlMdcg8ub1+BrDboEcF4IBgh UuzgCxmX0Udg7LvXiOlztwQBl0xCSU1hkEjxgt5PsrLs0S/RJhoQYriKRSqchOzbXnmM HBFFdzuC30b6XcHVBX7JF5MqTCLyaFZr/VdloqdIHj6exver28+uqVOtUTDN7Jt58u+5 gGNwkNbUgN0FgT0RYFVQCtFD6lJ5vlMSmvWr7x598wn+lRmwSPTtNLj0aAkYcK8eqGKL +ihWY7zZ0xgV72sw/XrRzJNJR2siE6s7ng79IokAeNf1f2U67BKiyuHRAV8SrCLTD68Y w+bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780526601; x=1781131401; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=iTE44OxcHCqYjYX+doIy+3NqUmI4SQrZkrHVFocDs+M=; b=H82HiGgsynLquVjQ+jUl3XdthbX9Oa9xOienhAULhIRwqCk4orp+JvvOHPteR5gcM9 9SAcIA1TL0ckcV/JjzFf/y6t5dxqQovdAhnRtddD8FHwGq1Jh+wR1WHy0+8ke49SFeQT hoE+Q9XAGR6fg5Xcy5/JvpznyyoMnTA58/6RLHVJuc/7ZyJeUqrzrMDF4MwV/wJHu8uO UMVUZsHgT9z+BybYB/wK3D9A67dEm3dUEtCRudlQvy9tBkg0/3D4EcQvhxewsc3pVmHL TawGewIuPKvnoQM1M0UhnFd+Ewc02X317adQBPCS58u4zaiqTUpAFopaPDNEKGAYDSbc ZuGg== X-Forwarded-Encrypted: i=1; AFNElJ+ml+hsMCzbop0mOMy16UxLl0dccexaQEW/blQXVWevo5IFMcn3AXaBjj6XR3uqQd8/i2s7hWZFuvp9v3M=@vger.kernel.org X-Gm-Message-State: AOJu0YxkUu7Imu8eEDhsTvvwi90Dtc+8HEtko1Ns9SbZjNApDP15oNEY HR2SWXIOwKjzreTH00uKWGyAGAxHF66vIGrE5pTnJoyJBLFD8EVfvR3c X-Gm-Gg: Acq92OEFH8APa0et8o2aIOAkIvhwVqA6AcVlTRonb5mq4ffh4TaSPmArD/VwQbVS7ry Bf4jTCeJC6jbSy2BQP0iw6OJMAHIRFS6hxTkctp68UKdTuXBd2PSa6xVE4+Sg1Rzykkw9RN8tuN h9HOILdtxAXCFBfIHb+uMosMZmKlLi3qzs522qO683Twg4lDKkEerZ/yrG9mcHV9Z5TB3JxZFAL GZ1J2yI2ZXB1gjS6leo7M7oZfsZnhJhhP0HTqxK2nflO9o+Ac+eOt48lnc1uLZEVh094AQGPEEN Ir5XNqaIzI4qVx4wzVeEyl3csJcCgvCbWhXm+6OV8vAlmOwfvKPOZ9Frn1QD8aSWyfKdvULXoDp JG9yaEz/0PWNn3DyH4Nevz+qCxhd/5QZZ5DaTkQd8NRx9IQUa+lPiOnBn09xNmUpeQ+7SFVGrkU T/wJzbQYkW88TD56w2eIduJMZg3/Wiug== X-Received: by 2002:a05:600c:a09:b0:490:688b:f9f8 with SMTP id 5b1f17b1804b1-490b5fe6672mr83368675e9.27.1780526600498; Wed, 03 Jun 2026 15:43:20 -0700 (PDT) Received: from localhost ([212.73.77.104]) by smtp.gmail.com with UTF8SMTPSA id 5b1f17b1804b1-490bc391aaasm29855955e9.1.2026.06.03.15.43.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 03 Jun 2026 15:43:19 -0700 (PDT) From: Askar Safin To: luto@amacapital.net Cc: akpm@linux-foundation.org, axboe@kernel.dk, brauner@kernel.org, david@kernel.org, dhowells@redhat.com, hch@infradead.org, jack@suse.cz, linux-api@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, miklos@szeredi.hu, netdev@vger.kernel.org, patches@lists.linux.dev, pfalcato@suse.de, safinaskar@gmail.com, torvalds@linux-foundation.org, viro@zeniv.linux.org.uk, willy@infradead.org Subject: Re: [PATCH 0/3] vmsplice: make vmsplice a trivial wrapper for preadv2/pwritev2 Date: Thu, 4 Jun 2026 01:43:11 +0300 Message-ID: <20260603224311.834796-1-safinaskar@gmail.com> X-Mailer: git-send-email 2.47.3 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Andy Lutomirski : > Maybe we should keep an API that does an optimized copy, from one fd > to another, that can send from a file to the network with at most ONE > cpu-side copy. Not aiming for zero like sendfile / splice. Aiming > for one. Yes, this is what my hypothetical future patch will do. One copy from pagecache to pipe, and then network uses that buffer directly. > But splice_to_socket involves > MSG_SPLACE_PAGES, which I think is a part of the mess that you > dislike. And the path where one does copy_splice_read and then > splice_to_socket has to be a bit complex because of tee and (I think) > because splice_to_socket cannot assume that the incoming data is just > ordinary unshared buffers. My future patch will provide new guarantee: pipe buffers are always stable, i. e. they will not be externally-modified. So hopefully network code will be adjusted to use this guarantee. But pipe buffers will not be "ordinary unshared buffers". They still may be shared with other things because of tee(2). (But they are still stable! They will not be randomly modified!) But network code can do "pipe_buf_try_steal" and thus ensure that these buffers are not shared with anything else. So, network code can be modified to use "pipe_buf_try_steal", and you will get "ordinary unshared buffers" exactly as you want. This will give you in total exactly one copy. Also: as well as I understand, previously, pipe_buf_try_steal was kind of lie. It may return true for buffers created via vmsplice with GIFT. (I did not check this, but I think so.) I. e. pipe_buf_try_steal will return "true" in this case, but pages are still shared! But, thanks to my vmsplice patchset (which is already applied), this is no longer true! So now pipe_buf_try_steal is absolutely safe to use! Finally, we can degrade tee(2) to copy, and hopefully this will allow us to always be sure that pipe buffers are not shared with anything. This is possible future direction. -- Askar Safin