Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id BA767C636D4 for ; Fri, 10 Feb 2023 17:24:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232925AbjBJRYU (ORCPT ); Fri, 10 Feb 2023 12:24:20 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37670 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232613AbjBJRYR (ORCPT ); Fri, 10 Feb 2023 12:24:17 -0500 Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CE9A736696 for ; Fri, 10 Feb 2023 09:24:14 -0800 (PST) Received: by mail-wm1-x334.google.com with SMTP id n13so4323979wmr.4 for ; Fri, 10 Feb 2023 09:24:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=jK4GcD8hacKVWz6zl8bBrz233whrxcoTUY/2ygZZfmc=; b=M2jDhbmblGLdfowPWsAysOenXMHJGfjKF4XBxa3qOAJbzKq8BVW5Bi70WAjt5O9fGN qp+ANsnVyXQKsU16qsl+FTAEnXVOzh8BC6x36hX/4beu9BTYwt7CqPuJFw/mHj4k+UR8 H8YDYi8jHuZgdrghm16rzRYLYR86rDIbo1cgI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=jK4GcD8hacKVWz6zl8bBrz233whrxcoTUY/2ygZZfmc=; b=yaWmGYCZ7ITecoHrneel/y+DpKSiI/eosMkGZIIU7DStIFWCKDJI7gqcydDdOIQ97X VMuM3+UszZ8si49mtzlhChnjZB93TtWP9wYVAqKRjXH+qI7DN1FEU6bYi9w+MKcIeWTv n++uEPGF+L7OCAWlP32vn58q6X5MkFhZMQG4elTFuyQNfdMw5lm2wBUSfjXSpijvQDhg RcdghLffy2zA24YnEk+RzEIRMOkTAQjO4n42p2Z4j1yTkOnAjtP5k225UST9kHlbJ1jx An9LtVp4zipegyxLp+VhbuTJqMzlazzueQKmFLsDScSeShoedl+TzxTDCxGlCkxCWDwW NrIQ== X-Gm-Message-State: AO0yUKXxxUrr161SIRZ8IhvUQZkUseQ7n5HgwzxGt8S8vK4Jq9NkucVe XRNClnAmKqhV4T8m0llL9qAhiovgqeztHDr3pPI= X-Google-Smtp-Source: AK7set99jH25zhi+9fV0kZPh0KFerphOOQ2vkTU90q6l+NP/vza0e0v5o4cIOzSl4NNbRQi3VAvpYQ== X-Received: by 2002:a05:600c:45cf:b0:3df:9858:c03c with SMTP id s15-20020a05600c45cf00b003df9858c03cmr10696634wmo.17.1676049852990; Fri, 10 Feb 2023 09:24:12 -0800 (PST) Received: from mail-ej1-f41.google.com (mail-ej1-f41.google.com. [209.85.218.41]) by smtp.gmail.com with ESMTPSA id q11-20020a7bce8b000000b003dd9232f036sm8496260wmj.23.2023.02.10.09.24.12 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 10 Feb 2023 09:24:12 -0800 (PST) Received: by mail-ej1-f41.google.com with SMTP id gr7so17742188ejb.5 for ; Fri, 10 Feb 2023 09:24:12 -0800 (PST) X-Received: by 2002:a17:906:4e46:b0:87a:7098:ca09 with SMTP id g6-20020a1709064e4600b0087a7098ca09mr3050972ejw.78.1676049852037; Fri, 10 Feb 2023 09:24:12 -0800 (PST) MIME-Version: 1.0 References: <0cfd9f02-dea7-90e2-e932-c8129b6013c7@samba.org> <20230210021603.GA2825702@dread.disaster.area> <20230210040626.GB2825702@dread.disaster.area> <20230210061953.GC2825702@dread.disaster.area> In-Reply-To: <20230210061953.GC2825702@dread.disaster.area> From: Linus Torvalds Date: Fri, 10 Feb 2023 09:23:55 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: copy on write for splice() from file to pipe? To: Dave Chinner Cc: Stefan Metzmacher , Jens Axboe , linux-fsdevel , Linux API Mailing List , io-uring , "linux-kernel@vger.kernel.org" , Al Viro , Samba Technical Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Feb 9, 2023 at 10:19 PM Dave Chinner wrote: > > Splice has two sides - a source where we splice to the transport > pipe, then a destination where we splice pages from the transport > pipe. For better or worse, time in the transport pipe is unbounded, > but that does not mean the srouce or destination have unbound > processing times. Well, they are possibly fairly unbounded too - think things like network packet re-send timeouts etc. So the data lifetime - even just on just one side - can _easily_ be "multiple seconds" even when things are normal, and if you have actual network connectivity issues we are easily talking minutes. So I don't think a scheme based on locking works even for just the "one side" operations - at least in the general case. That said, I wasn't really serious about my "retry" model either. Maybe it could be made to work, but it sounds messy. And when it comes to networking, in general things like TCP checksums etc should be ok even with data that isn't stable. When doing things by hand, networking should always use the "copy-and-checksum" functions that do the checksum while copying (so even if the source data changes, the checksum is going to be the checksum for the data that was copied). And in many (most?) smarter network cards, the card itself does the checksum, again on the data as it is transferred from memory. So it's not like "networking needs a stable source" is some really _fundamental_ requirement for things like that to work. But it may well be that we have situations where some network driver does the checksumming separately from then copying the data. Linus