linux-kernel - Re: [PATCH v6 18/34] dio: Pin pages rather than ref'ing if appropriate

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Y8jafackRu7t2Jf4@infradead.org>
Date:   Wed, 18 Jan 2023 21:51:57 -0800
From:   Christoph Hellwig <hch@...radead.org>
To:     Al Viro <viro@...iv.linux.org.uk>
Cc:     David Howells <dhowells@...hat.com>, Jens Axboe <axboe@...nel.dk>,
        Jan Kara <jack@...e.cz>, Christoph Hellwig <hch@....de>,
        Matthew Wilcox <willy@...radead.org>,
        Logan Gunthorpe <logang@...tatee.com>,
        linux-fsdevel@...r.kernel.org, linux-block@...r.kernel.org,
        Christoph Hellwig <hch@...radead.org>,
        Jeff Layton <jlayton@...nel.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v6 18/34] dio: Pin pages rather than ref'ing if
 appropriate

On Thu, Jan 19, 2023 at 05:04:20AM +0000, Al Viro wrote:
> 1) fs/direct-io.c is ancient, grotty and has few remaining users.
> The case of block devices got split off first; these days it's in
> block/fops.c.  Then iomap-using filesystems went to fs/iomap/direct-io.c,
> leaving this sucker used only by affs, ext2, fat, exfat, hfs, hfsplus, jfs,
> nilfs2, ntfs3, reiserfs, udf and ocfs2.  And frankly, the sooner it dies
> the better off we are.  IOW, you've picked an uninteresting part and left
> the important ones untouched.

Agreed.  That being said if we want file systems (including those not
using this legacy version) to be able to rely on correct page dirtying
eventually everything needs to pin pages it writes to.  So we need to
either actually fix or remove this code in the forseeable future.  It's
by far not the most interesting and highest priority, though.   And as
I said this series is already too large too review anyway, I'd really
prefer to get a core set done ASAP and then iterate on the callers and
additional bits.

> Unless I misunderstand something fundamental about the whole thing,
> this crap should become useless with that conversion.

It should - mostly.  But we need to be very careful about that, so
I'd prefer a separate small series for it to be honest.

> BTW, where do we dirty the pages on IO_URING_OP_READ_FIXED with
> O_DIRECT file?  AFAICS, bio_set_pages_dirty() won't be called
> (ITER_BVEC iter) and neither will bio_release_pages() do anything
> (BIO_NO_PAGE_REF set on the bio by bio_iov_bvec_set() called
> due to the same ITER_BVEC iter).  Am I missing something trivial
> here?  Jens?

I don't think we do that all right now.