Re: [PATCH] mm: Wire up tail page poisoning over ->mappings

[Matthew Wilcox]

On Mon, Aug 21, 2023 at 12:48:18PM -0400, Peter Xu wrote:
> On Mon, Aug 21, 2023 at 03:29:01AM +0100, Matthew Wilcox wrote:
> > On Sun, Aug 20, 2023 at 09:13:55PM -0400, Peter Xu wrote:
> > > Setting tail mapping for tail 1/2 is even wrong, which part of this patch
> > > fixes:
> > > 
> > > @@ -428,7 +428,8 @@ static inline void prep_compound_tail(struct page *head, int tail_idx)
> > >  {
> > >         struct page *p = head + tail_idx;
> > > 
> > > -       p->mapping = TAIL_MAPPING;
> > > +       if (tail_idx > TAIL_MAPPING_REUSED_MAX)
> > > +               p->mapping = TAIL_MAPPING;
> > >         set_compound_head(p, head);
> > >         set_page_private(p, 0);
> > >  }
> > 
> > I didn't see this.  This is wrong.  tail->mapping is only reused for
> > large rmappable pages.  It's not reused for other compound pages.
> 
> Just to make sure we're on the same page: I think it's not only
> _deferred_list (of tail page 2) that reused the mapping field (word offset
> 3), but also _nr_pages_mapped (of tail page 1)?

I don't see how this comment is related to the part of the email you're
replying to.  But yes, prep_large_rmappable overwrites ->mapping in
two tail pages.

> > However, I have a small patch series which enables 'allnoconfig' to
> > build after renaming page->mapping to page->_mapping.  Aside from fs/
> > there are *very* few places which look at page->mapping [1].  I'll post
> > that patch series tomorrow.
> 
> Assuming it's still not yet posted; I can wait and read it.

I sent out a few patches.  Some have made it to -next already because
they're almost trivial.  Nobody's commented on the difficult one.

https://lore.kernel.org/linux-mm/20230821202016.2910321-1-willy@xxxxxxxxxxxxx/

> If you plan to remove the whole TAIL_MAPPING in a few days then I agree
> this patch is not needed, but so far I don't know when it'll land and also
> why, before that it does sound like we can still keep this patch.

This patch is putting fresh paint on a condemned building.  Just stop
it.

> Regarding the question on "why removing TAIL_MAPPING": poisoning an unused
> field is always helpful to me even if not referenced with "page->mapping".
> So I don't see an immediate benefit from removing the poisoning if it's
> already there; OTOH not sure whether poison more unused fields will be more
> helpful in general?

You are wrong.