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 53F0FC636D7 for ; Fri, 10 Feb 2023 22:18:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233340AbjBJWSS (ORCPT ); Fri, 10 Feb 2023 17:18:18 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50986 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232840AbjBJWSQ (ORCPT ); Fri, 10 Feb 2023 17:18:16 -0500 Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3BB4B7CCA8 for ; Fri, 10 Feb 2023 14:18:15 -0800 (PST) Received: by mail-ej1-x62c.google.com with SMTP id gr7so19377873ejb.5 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=ZG05KIz82dOuFFdQp6udFQsyhJHgNjvC/4j84sf6EjwutAEb6gp/FdiLPB+C8WWMEH hs8HuWU8EAJmuKhXwDOA4ITcAtfLI65fOl+7Er9GdlOjeEdCr3pU65X54BefjcRmt006 7mW1I5P75BwqPy7bmFtaOUU0+Y+JigM/OKuJIJoLplRVg2aOwwFB/hCUVcVvqDBwLxmi jhMJgdTQZpiXMJJCitN2jVGa3R/pgU5j84g53owEWrPS/j0ZGO12p4u0CxHoCFdPF91d 9SzVTHLFvR/k9TwWOuEhSokMtZ1mSGfPhC01wc7qwSyPe3KpQuJAy8zOtEe17YpyODPx uxcA== X-Gm-Message-State: AO0yUKVmiEhWsU299GieJtimkfUDa+YxQAwHGd/w9VN1R+g00oSezPgk LYbVfQBzQU/whaMnZxp1HCAF7x1KcmAR4gsXezM= X-Google-Smtp-Source: AK7set+cEeOLiMDIyeK7FtXLC7FXCziTfrZzPsx+KuT7UMt9KiYkWBidRRtmxaA8ahnrN5QAlBUQjg== X-Received: by 2002:a17:906:5a91:b0:8af:2bb3:80d7 with SMTP id l17-20020a1709065a9100b008af2bb380d7mr8032018ejq.31.1676067493502; Fri, 10 Feb 2023 14:18:13 -0800 (PST) Received: from mail-ed1-f50.google.com (mail-ed1-f50.google.com. [209.85.208.50]) by smtp.gmail.com with ESMTPSA id aa22-20020a170907355600b008af2b5cc1a2sm2938626ejc.69.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-f50.google.com with SMTP id fi26so6070740edb.7 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-kernel@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