Message ID | 26aba1b5-8393-a20a-3ce9-f82425673f4d@kernel.dk |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp976557vqo; Sat, 6 May 2023 03:46:10 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ7BKBKa+yNaD8wR8uREVRY4vNrG7H0eP5Ci9uOjgCWkJadTYI/qow/bzhAvm2eDF5paxgpN X-Received: by 2002:a17:90a:ea18:b0:249:7224:41cb with SMTP id w24-20020a17090aea1800b00249722441cbmr4243463pjy.31.1683369970069; Sat, 06 May 2023 03:46:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1683369970; cv=none; d=google.com; s=arc-20160816; b=RLZm8z4bIcuTIkxPF8knYL3AcHlZcJMh0+qlLBxvaQbQy9RZp7V34BDdj+JTGC7gwl AbD75Jn0M2dzCjdnfsFq1K2ml0cFXBrOyBMbI2V6yqfPDG6ERTJKPH0HearaCbBGxHuY EV6yvKOzHueZApfOhlvBywynFeU1qWjyg5wAL3hhV6gSmY7qldb5nrVj/aoJ3RhkL/9i RGMB9RkWW9D95zJSsjXG3LM7OPPI/icg/O7SWN+YritScd5djzJU3JAlavAEnHwErnln vJcu/S0Bg4hH7RR+FppKB8Y6MZ0+9XXCO2S5Mf07vgU7OmbQA4xKez0kMTRa0hRwR97T ru0g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id :dkim-signature; bh=pu7agQuYInO0yxZQecLTsewqB2PE2KJ8IfPCfiCnNHk=; b=o3gjjg9BiwbZnj1RXxPJoyXISxGOey5SZDpB2Rs/gZ7+xzZRm71g8ty9VffNZe2Vn6 sxk7z6gCT+H4g6XpHUgK5VVOdeBlHxz1Qyijh7Dr0UzOwQsG/iSLNHUvd4GlWSA2rCdG 78ntDEkmN0hLCe9Vr/sp/x3G016N5DLeM9fG8G41OjdYKUTMVNaVmHp3mvZmIO0VWxNP dUBmmHkzrF52GozcGlRZCBpXsfOw1+c0gXTc8JgCu+Q+9M9q5FY2n6n6rG72qx5J9JTW SSyz5GmvTXFHxeHVX/Fc//AcBWhI6NVzcGY2O2zyfrnUVQWhl/juk+G6CSf1xkpA1aQ+ MFug== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel-dk.20221208.gappssmtp.com header.s=20221208 header.b=3Kyv4bY+; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id cp18-20020a17090afb9200b002476be78cd2si8285300pjb.121.2023.05.06.03.45.51; Sat, 06 May 2023 03:46:10 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel-dk.20221208.gappssmtp.com header.s=20221208 header.b=3Kyv4bY+; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230209AbjEFKdW (ORCPT <rfc822;baris.duru.linux@gmail.com> + 99 others); Sat, 6 May 2023 06:33:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39566 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230196AbjEFKdU (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Sat, 6 May 2023 06:33:20 -0400 Received: from mail-yw1-x112a.google.com (mail-yw1-x112a.google.com [IPv6:2607:f8b0:4864:20::112a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5DDF972BA for <linux-kernel@vger.kernel.org>; Sat, 6 May 2023 03:33:19 -0700 (PDT) Received: by mail-yw1-x112a.google.com with SMTP id 00721157ae682-54f9e2d0714so3969917b3.1 for <linux-kernel@vger.kernel.org>; Sat, 06 May 2023 03:33:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel-dk.20221208.gappssmtp.com; s=20221208; t=1683369198; x=1685961198; h=content-transfer-encoding:subject:from:cc:to:content-language :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=pu7agQuYInO0yxZQecLTsewqB2PE2KJ8IfPCfiCnNHk=; b=3Kyv4bY+c218oKiE6dBD03v3LZEd7lL9KvnXZSdggGiOlrmbSKizXs8YzQ1bnwxbS8 6w6eJVaiUo6pbFEh+cUBHB9+At0oIPc4TY3MarDY53xW4dxckH41DpmZRhuvf14d5Xlg KJtNGtHZR0T9g/fgwncr7jxPAYQdxepxWWk1cZPZxg292wqBJdkLV2LNdsXdUL8I58ip /pGX37rxXbtVeFapS5TxsAfmtazv88fwyDt/QOAlnGaGYJ9lNp8s+xARJApWhGWdMw3q BtNuXyUI582O7BGjrZjepVHK0ppin5OxSvR23QDdyckqtBGAWn19v8/naONu0D+HNsbR X7Lw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683369198; x=1685961198; h=content-transfer-encoding:subject:from:cc:to:content-language :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=pu7agQuYInO0yxZQecLTsewqB2PE2KJ8IfPCfiCnNHk=; b=ZDtaQ7A40MDWK1l/1iarEhOH97y0B4F5S3eBlB0Cr4DE/NLMyVwdLTh3NsHYMEzNZE VIMZuEF0+UnX4igiksFGOC0QUi4bz027GAur7iQE/cCJk1nkodlQ4QQW2CoHmjOzlN0z 8PsqykPub07TbtXWn7HJdcZF+wuChM2gH6mbVgav8wVCGVuZK4vOxJEB40ZGTeFPJ+Zh q1zff/JZc7+2uK58TUErYq+o2anloojGe8nQUUxG7MQkna8qhjNcPiUbpbASttyi2L8k XRp7JJxtx/TqBiA6cmIUsZzwFCTYgKyna93nrvDAr59dCCR3PmxyeokIjkcg6M+BUZLr nEFg== X-Gm-Message-State: AC+VfDzDiDmVgzIYNLks0cYK4EOo4PKeiSgbDVwjxi7ZBsIaDMjyo/Z/ 5cTknGFbhyNzXueggGijOBcBUg== X-Received: by 2002:a81:1d07:0:b0:55d:7fd0:e3b9 with SMTP id d7-20020a811d07000000b0055d7fd0e3b9mr4673857ywd.1.1683369198504; Sat, 06 May 2023 03:33:18 -0700 (PDT) Received: from [172.20.2.186] ([12.153.103.3]) by smtp.gmail.com with ESMTPSA id k4-20020a0dc804000000b00555ca01b115sm1051375ywd.104.2023.05.06.03.33.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 06 May 2023 03:33:17 -0700 (PDT) Message-ID: <26aba1b5-8393-a20a-3ce9-f82425673f4d@kernel.dk> Date: Sat, 6 May 2023 04:33:17 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Content-Language: en-US To: Linus Torvalds <torvalds@linux-foundation.org> Cc: "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org> From: Jens Axboe <axboe@kernel.dk> Subject: [GIT PULL] Pipe FMODE_NOWAIT support Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1765141349738140716?= X-GMAIL-MSGID: =?utf-8?q?1765141349738140716?= |
Series |
[GIT,PULL] Pipe FMODE_NOWAIT support
|
|
Pull-request
git://git.kernel.dk/linux.git tags/pipe-nonblock-2023-05-06Message
Jens Axboe
May 6, 2023, 10:33 a.m. UTC
Hi Linus, Here's the revised edition of the FMODE_NOWAIT support for pipes, in which we just flag it as such supporting FMODE_NOWAIT unconditionally, but clear it if we ever end up using splice/vmsplice on the pipe. The pipe read/write side is perfectly fine for nonblocking IO, however splice and vmsplice can potentially wait for IO with the pipe lock held. Please pull! The following changes since commit 457391b0380335d5e9a5babdec90ac53928b23b4: Linux 6.3 (2023-04-23 12:02:52 -0700) are available in the Git repository at: git://git.kernel.dk/linux.git tags/pipe-nonblock-2023-05-06 for you to fetch changes up to afed6271f5b0d78ca1a3739c1da4aa3629b26bba: pipe: set FMODE_NOWAIT on pipes (2023-04-25 14:08:59 -0600) ---------------------------------------------------------------- pipe-nonblock-2023-05-06 ---------------------------------------------------------------- Jens Axboe (2): splice: clear FMODE_NOWAIT on file if splice/vmsplice is used pipe: set FMODE_NOWAIT on pipes fs/pipe.c | 3 +++ fs/splice.c | 34 ++++++++++++++++++++++++++++++---- 2 files changed, 33 insertions(+), 4 deletions(-)
Comments
On Sat, May 6, 2023 at 3:33 AM Jens Axboe <axboe@kernel.dk> wrote: > > Here's the revised edition of the FMODE_NOWAIT support for pipes, in > which we just flag it as such supporting FMODE_NOWAIT unconditionally, > but clear it if we ever end up using splice/vmsplice on the pipe. The > pipe read/write side is perfectly fine for nonblocking IO, however > splice and vmsplice can potentially wait for IO with the pipe lock held. Ok, pulled. It does strike me that one of the (few) users is the io_uring __io_file_supports_nowait() thing, and that thing is *disgusting*. Wouldn't it be much nicer if FMODE_NOWAIT ended up working automatically on a block file descriptor too? You did all this "make pipes set FMODE_NOWAIT", but then that io_uring code does if (S_ISBLK(mode)) { if (IS_ENABLED(CONFIG_BLOCK) && io_bdev_nowait(I_BDEV(file->f_mapping->host))) return true; return false; } rather than just rely on FMODE_NOWAIT for block devices too... And it's a bit odd in other ways, because the kiocb code for RWF_NOWAIT - which is the other user of FMODE_NOWAIT - does *not* seem to do any of those bdev games. So that other user does seem to just rely on the file mode bit having been set up by open. In fact, I see 'blkdev_open()' doing filp->f_mode |= FMODE_NOWAIT | FMODE_BUF_RASYNC; so I really don't see why __io_file_supports_nowait() then does that special check for S_ISBLK(). Something is very rotten in the state of Denmark. But that's all independent of this pipe side, which now looks fine to me. Linus
The pull request you sent on Sat, 6 May 2023 04:33:17 -0600:
> git://git.kernel.dk/linux.git tags/pipe-nonblock-2023-05-06
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/7644c8231987288e7aae378d2ff3c56a980d1988
Thank you!
On 5/6/23 9:27?AM, Linus Torvalds wrote: > On Sat, May 6, 2023 at 3:33?AM Jens Axboe <axboe@kernel.dk> wrote: >> >> Here's the revised edition of the FMODE_NOWAIT support for pipes, in >> which we just flag it as such supporting FMODE_NOWAIT unconditionally, >> but clear it if we ever end up using splice/vmsplice on the pipe. The >> pipe read/write side is perfectly fine for nonblocking IO, however >> splice and vmsplice can potentially wait for IO with the pipe lock held. > > Ok, pulled. > > It does strike me that one of the (few) users is the io_uring > __io_file_supports_nowait() thing, and that thing is *disgusting*. Hah yes, will not claim that's a thing of beauty. It has been getting better though, at least. > Wouldn't it be much nicer if FMODE_NOWAIT ended up working > automatically on a block file descriptor too? You did all this "make > pipes set FMODE_NOWAIT", but then that io_uring code does > > if (S_ISBLK(mode)) { > if (IS_ENABLED(CONFIG_BLOCK) && > io_bdev_nowait(I_BDEV(file->f_mapping->host))) > return true; > return false; > } > > rather than just rely on FMODE_NOWAIT for block devices too... > > And it's a bit odd in other ways, because the kiocb code for > RWF_NOWAIT - which is the other user of FMODE_NOWAIT - does *not* seem > to do any of those bdev games. So that other user does seem to just > rely on the file mode bit having been set up by open. > > In fact, I see 'blkdev_open()' doing > > filp->f_mode |= FMODE_NOWAIT | FMODE_BUF_RASYNC; > > so I really don't see why __io_file_supports_nowait() then does that > special check for S_ISBLK(). I need to double check if we can just do the io_bdev_nowait() check early and in the block code, so we cn make FMODE_NOWAIT reliable there. With that, yeah we could totally get rid of that odd checking and move it to the slower open path instead which would obviously be better. We should just set it for socket as well and just ultimately end up with: static bool __io_file_supports_nowait(struct file *file) { if (file->f_flags & O_NONBLOCK) return true; return file->f_mode & FMODE_NOWAIT; } and be done with it. Then we could also stop caching this state in the io_kiocb flags. > Something is very rotten in the state of Denmark. It's the Norwegians, always troublesome. > But that's all independent of this pipe side, which now looks fine to me. Thanks, I'll give the nowait side a once-over for the next kernel release and we can get that looking better too.
On Sat, May 6, 2023 at 3:28 PM Jens Axboe <axboe@kernel.dk> wrote: > > We should just set it for socket as well and just ultimately end up > with: > > static bool __io_file_supports_nowait(struct file *file) > { > if (file->f_flags & O_NONBLOCK) > return true; > return file->f_mode & FMODE_NOWAIT; > } Yup. > > Something is very rotten in the state of Denmark. > > It's the Norwegians, always troublesome. Something all Nordic people can agree on. Even the Norwegians, because they are easily confused. Linus
Linus Torvalds [07/05/2023 02.55]: >>> Something is very rotten in the state of Denmark. >> It's the Norwegians, always troublesome. > Something all Nordic people can agree on. Even the Norwegians, because > they are easily confused. You are all just jealous of our oil and gas. It's a result of being occupied first by the Danes from 1537 to 1814, then by the Swedes from 1814 to 1905. And the Finns moved through Sweden to Norway, where they burned down the forests in order to grow rye in the ashes ("svedjebruk" in the district of Finnskogen in eastern Norway). Actually, my family on my mother's side descend from some of these "skogfinner" ("forest Finns" for those on the list without language skills), as we call them.