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

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] [day] [month] [year] [list]

Date:   Tue, 22 Aug 2023 16:18:55 +0100
From:   Matthew Wilcox <willy@...radead.org>
To:     Peter Xu <peterx@...hat.com>
Cc:     linux-mm@...ck.org, linux-kernel@...r.kernel.org,
        Yang Shi <shy828301@...il.com>,
        Mike Kravetz <mike.kravetz@...cle.com>,
        David Hildenbrand <david@...hat.com>,
        "Kirill A . Shutemov" <kirill@...temov.name>,
        Hugh Dickins <hughd@...gle.com>,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH] mm: Wire up tail page poisoning over ->mappings

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@infradead.org/

> 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.