From mboxrd@z Thu Jan 1 00:00:00 1970 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 62C15C636D4 for ; Fri, 10 Feb 2023 22:18:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233799AbjBJWSS (ORCPT ); Fri, 10 Feb 2023 17:18:18 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50998 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233340AbjBJWSR (ORCPT ); Fri, 10 Feb 2023 17:18:17 -0500 Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 07B8F2BF17 for ; Fri, 10 Feb 2023 14:18:16 -0800 (PST) Received: by mail-ed1-x535.google.com with SMTP id r3so6021086edq.13 for ; Fri, 10 Feb 2023 14:18:15 -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=N+TOeH19iOq0vdQyV1Prof3NpM6QGVmHTyGEbxYTvX8=; b=TFoinpe3pITLVHtLti947pihmGAzoNViv44DXoHnGTTszOCmnwyESdP0lt/lbOrP7t 8YDtBz+IGoaYOl0Ob5HxjVWGYnebyxpw932EfN70qrgWIPO+7+T6hBCeJjUjrPieoXRM laPRsn73b5fpWuslCZ6zcJBfNorWMVHntxmcc= 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=N+TOeH19iOq0vdQyV1Prof3NpM6QGVmHTyGEbxYTvX8=; b=KR66e6SOsSNPV6zOI5HyisnoDniIgGtP+WaEujT+3kQ8EM5UrEHvEa/Ql8zopZHICx o545+Bn1nt4huUl20/xPGg0UCBksFa3ZU1qJ0uAihFh1mBWtBa0QEU04bKK6spx+aCDF TH9PFmVRqYt5j5jxtm4YO6WrPrHRxDQ+E9Z7tUvmK1zWwfTJ0zZuUfuj96do0i0KDy11 zpYc/UVnuEhsA7qV3MbxNRdwJiIrKOjPAKxnJmVXkjPwefD0Dy7nRc4HsKIo1XTD7TrR 0lbofE3RBrGgQ1Y4ffhtonrlstss76y3FV1ZqyLbm9KqG1R1WnKtFi7YpU4HCY0FGthT rQuA== X-Gm-Message-State: AO0yUKXebAwpIC+YBHtqPjb1JMbPJ0YIsU0qJiy+o0Vc/wAIYHjS44ia qmTHsSo+zu3+jB9C/LC8mFHJ2qqYtiTJ3af6P/Y= X-Google-Smtp-Source: AK7set9eGBdQ5gNxp3jo4p1gaAJv5Ex4vWVt2TP9aMQDig/hHmb0T0xnai/9r40TjZGzQCbY6LL0gQ== X-Received: by 2002:a50:998c:0:b0:4a2:4675:2162 with SMTP id m12-20020a50998c000000b004a246752162mr13151843edb.3.1676067494394; Fri, 10 Feb 2023 14:18:14 -0800 (PST) Received: from mail-ed1-f48.google.com (mail-ed1-f48.google.com. [209.85.208.48]) by smtp.gmail.com with ESMTPSA id z96-20020a509e69000000b004acb6d659eesm50301ede.52.2023.02.10.14.18.12 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 10 Feb 2023 14:18:12 -0800 (PST) Received: by mail-ed1-f48.google.com with SMTP id l12so6155122edb.0 for ; Fri, 10 Feb 2023 14:18:12 -0800 (PST) X-Received: by 2002:a50:f603:0:b0:49d:ec5e:1e98 with SMTP id c3-20020a50f603000000b0049dec5e1e98mr3399923edn.5.1676067492117; Fri, 10 Feb 2023 14:18:12 -0800 (PST) MIME-Version: 1.0 References: <0cfd9f02-dea7-90e2-e932-c8129b6013c7@samba.org> <1dd85095-c18c-ed3e-38b7-02f4d13d9bd6@kernel.dk> <7a2e5b7f-c213-09ff-ef35-d6c2967b31a7@kernel.dk> <2bb12591-9d24-6b26-178f-05e939bf3251@kernel.dk> In-Reply-To: From: Linus Torvalds Date: Fri, 10 Feb 2023 14:17:55 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: copy on write for splice() from file to pipe? To: Jens Axboe , Ming Lei Cc: Andy Lutomirski , Dave Chinner , Matthew Wilcox , Stefan Metzmacher , 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-api@vger.kernel.org On Fri, Feb 10, 2023 at 2:08 PM Linus Torvalds wrote: > > (a) the first one is to protect from endless loops Just to clarify: they're not "endless loops" per se, but we have splice sources and destinations that always succeed, like /dev/zero and /dev/null. So things like "sendfile()" that are happy to just repeat until done do need to have some kind of signal handling even for the case when we're not actually waiting for data. That's what that whole /* * Check for signal early to make process killable when there are * always buffers available */ this is all about. See commit c725bfce7968 ("vfs: Make sendfile(2) killable even better") for a less obvious example than that "zero->null" kind of thing. (I actually suspect that /dev/zero no longer works as a splice source, since we disabled the whole "fall back to regular IO" that Christoph did in 36e2c7421f02 "fs: don't allow splice read/write without explicit ops"). Linus