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 AF859C6379F for ; Fri, 10 Feb 2023 22:18:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233220AbjBJWSS (ORCPT ); Fri, 10 Feb 2023 17:18:18 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51000 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233497AbjBJWSR (ORCPT ); Fri, 10 Feb 2023 17:18:17 -0500 Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2C5AA4FC1E for ; Fri, 10 Feb 2023 14:18:16 -0800 (PST) Received: by mail-ej1-x632.google.com with SMTP id lu11so19409504ejb.3 for ; Fri, 10 Feb 2023 14:18:16 -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=2JiftSYvuHwm98eOojJ1p+0iyCwbeVAXdHU8QNfYGGb78r32IQTOqqMqDsupRf7a/5 ujlP6ZMi3ON2Lp3Cjaj2LFYKrgd8S8m3WnhrDTPGYbujEwRhdIxbw01YG/dk+UEAZuDJ TtFfi+uiJZ/zYmhgZBECyEzB2yFFdZKOyRliNmsTst3tEBm0t1UXR4y9BprdcrZ1xj8k 46bObZ2aMU9CqUV5LQQAc3f+USOx21Iqdy8glJH0XTxDxQSCGs4XOM/GyuAgSMjybVEd 0/XTYAYEJ3/JweU72U0JEoGfmWlH1OeXuROgkGSZeGGkWePqVgfNpH0bIw+1hkShYXjY AcxQ== X-Gm-Message-State: AO0yUKX8eKKTARU0S5RIT4Ve4QnEUt6ffWy4sSOInEB1XZe98X16Pfkp ngLsb6khyewavKmVXGrS90MKFOLI6cuzwbqw1ic= X-Google-Smtp-Source: AK7set+GnlYhiP4vEWefZTcwOAZV78xpp5w60xLHEhFDDFFqprkY9qa6wWyX9Uhjns6PB6xZdtrLqg== X-Received: by 2002:a17:907:7da8:b0:8ad:531d:3606 with SMTP id oz40-20020a1709077da800b008ad531d3606mr14288778ejc.35.1676067494487; Fri, 10 Feb 2023 14:18:14 -0800 (PST) Received: from mail-ed1-f54.google.com (mail-ed1-f54.google.com. [209.85.208.54]) by smtp.gmail.com with ESMTPSA id lr21-20020a170906fb9500b008af0a1f9596sm2928408ejb.218.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-f54.google.com with SMTP id eq11so6082268edb.6 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: io-uring@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