linux-kernel - Re: [PATCH v2 12/12] mm/filemap: Return only head pages from find_get

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: <20200930172321.GS20115@casper.infradead.org>
Date:   Wed, 30 Sep 2020 18:23:21 +0100
From:   Matthew Wilcox <willy@...radead.org>
To:     Jan Kara <jack@...e.cz>
Cc:     linux-mm@...ck.org, Andrew Morton <akpm@...ux-foundation.org>,
        Hugh Dickins <hughd@...gle.com>,
        William Kucharski <william.kucharski@...cle.com>,
        Johannes Weiner <hannes@...xchg.org>,
        Yang Shi <yang.shi@...ux.alibaba.com>,
        Dave Chinner <dchinner@...hat.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 12/12] mm/filemap: Return only head pages from
 find_get_entries

On Wed, Sep 30, 2020 at 07:08:07PM +0200, Jan Kara wrote:
> On Wed 30-09-20 13:36:37, Matthew Wilcox wrote:
> > On Wed, Sep 30, 2020 at 02:15:12PM +0200, Jan Kara wrote:
> > > On Mon 14-09-20 14:00:42, Matthew Wilcox (Oracle) wrote:
> > > > All callers now expect head (and base) pages, and can handle multiple
> > > > head pages in a single batch, so make find_get_entries() behave that way.
> > > > Also take the opportunity to make it use the pagevec infrastructure
> > > > instead of open-coding how pvecs behave.  This has the side-effect of
> > > > being able to append to a pagevec with existing contents, although we
> > > > don't make use of that functionality anywhere yet.
> > > > 
> > > > Signed-off-by: Matthew Wilcox (Oracle) <willy@...radead.org>
> > > 
> > > Looks good to me. You can add:
> > > 
> > > Reviewed-by: Jan Kara <jack@...e.cz>
> > > 
> > > I'm just curious: What has happened to pagevec_lookup_entries() call in
> > > invalidate_inode_pages2_range()? Your series appears to be based on a tree
> > > where the call already does not exist...
> > 
> > That went away in patch 10 of this series.
> 
> Ah, I see. Thanks. Then I'm somewhat wondering is really
> invalidate_inode_pages2_range() safe for THP head pages? At least the:
> 
> 	unmap_mapping_pages(mapping, index, 1, false);
> 
> doesn't look adequate for THP head pages... do_launder_page() is also
> doubtful but probably currently OK because THPs cannot be dirty at this
> moment. But how about THPs that are partialy inside start-end range? So far
> the function didn't care because it was operating on page basis so it
> didn't care but now it is probably relevant... At least it would warrant a
> comment in some changelog if you are convinced everything is safe.

You're right, it's inadequate.  It's safe to apply this series to the
mainline as-is because the only filesystem which creates THP today
is tmpfs and it won't call invalidate_inode_pages2_range() (afaics).
I have a followup patch which isn't part of this series which fixes it:

http://git.infradead.org/users/willy/pagecache.git/commitdiff/364283163847d1c106463223b858308c730592a1

There are other similar fixes which are also needed before we get to
allowing THPs to be added to the page cache for normal filesystems,
but I think I'm out of time for this merge window.  My plan is to submit
everything that's in this tree for the next merge window; the page cache
pieces through Andrew and the filesystem/iomap/XFS pieces through Darrick.
With good luck, all of this will be in place for 5.11.  I have about 50
patches in flight for 5.10 and it'll be about another 50 for 5.11.

Reviewer bandwidth is probably the biggest issue right now, and I
really appreciate your thoughtful comments.