lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wj=LwLDYrjHpMM+QnE2T+u4P9-UXhXGkAMXiyfGjGnNEA@mail.gmail.com>
Date:   Sat, 6 May 2023 08:27:39 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Jens Axboe <axboe@...nel.dk>
Cc:     "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] Pipe FMODE_NOWAIT support

On Sat, May 6, 2023 at 3:33 AM Jens Axboe <axboe@...nel.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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ