linux-kernel - Re: [PATCH] mm: remove an avoidable load of page refcount in page_ref_add

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]

Message-ID: <CAOUHufZrt_QKM7HnNAGkFwJk1x5J5FtfUdoaAHUPoWtvSMLjPA@mail.gmail.com>
Date: Mon, 6 Jan 2025 21:41:51 -0700
From: Yu Zhao <yuzhao@...gle.com>
To: David Hildenbrand <david@...hat.com>, Mateusz Guzik <mjguzik@...il.com>
Cc: akpm@...ux-foundation.org, willy@...radead.org, 
	linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH] mm: remove an avoidable load of page refcount in page_ref_add_unless

On Mon, Dec 9, 2024 at 7:46 AM David Hildenbrand <david@...hat.com> wrote:
>
> On 09.12.24 15:30, Mateusz Guzik wrote:
> > On Mon, Dec 9, 2024 at 3:22 PM David Hildenbrand <david@...hat.com> wrote:
> >>
> >> On 09.12.24 13:33, Mateusz Guzik wrote:
> >>> That is to say I think this thread just about exhausted the time
> >>> warranted by this patch. No hard feelz if it gets dropped, but then I
> >>> do strongly suggest adding a justification to the extra load.
> >>
> >> Maybe it's sufficient for now to simply do your change with a comment:
> >>
> >> diff --git a/include/linux/page_ref.h b/include/linux/page_ref.h
> >> index 8c236c651d1d6..1efc992ad5687 100644
> >> --- a/include/linux/page_ref.h
> >> +++ b/include/linux/page_ref.h
> >> @@ -234,7 +234,13 @@ static inline bool page_ref_add_unless(struct page *page, int nr, int u)
> >>
> >>           rcu_read_lock();
> >>           /* avoid writing to the vmemmap area being remapped */
> >> -       if (!page_is_fake_head(page) && page_ref_count(page) != u)
> >> +       if (!page_is_fake_head(page))
> >> +               /*
> >> +                * atomic_add_unless() will currently never modify the value
> >> +                * if it already is u. If that ever changes, we'd have to have
> >> +                * a separate check here, such that we won't be writing to
> >> +                * write-protected vmemmap areas.
> >> +                */
> >>                   ret = atomic_add_unless(&page->_refcount, nr, u);
> >>           rcu_read_unlock();
> >>
> >>
> >> It would bail out during testing ... hopefully, such that we can detect any such change.
> >>
> >
> > Not my call to make, but looks good. ;)
> >
> > fwiw I don't need any credit and I would be more than happy if you
> > just submitted the thing as your own without me being mentioned. *No*
> > cc would also be appreciated.
>
> Likely Andrew can add the comment as a fixup.

Sorry for not getting back to you sooner: the page_ref_count() test
actually is a must, however, I didn't do it in the right order.

I only realized my carelessness after Will asked me about it here [1]
-- I just posted a fix here [2], CC'ing both of you. If any of you
have concerns about it, please let me know in that thread. Otherwise
I'll ask Andew to drop this patch. Thank you.

[1] https://lore.kernel.org/linux-mm/20241128142028.GA3506@willie-the-truck/
[2] https://lore.kernel.org/linux-mm/20250107043505.351925-1-yuzhao@google.com/