linux-kernel - Re: [PATCH mm-unstable v1] mm/hugetlb_vmemmap: fix memory loads ordering

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: <559ea5ca-fea2-4a0a-a099-23e2d972f6e6@redhat.com>
Date: Tue, 7 Jan 2025 18:02:05 +0100
From: David Hildenbrand <david@...hat.com>
To: Matthew Wilcox <willy@...radead.org>
Cc: Yu Zhao <yuzhao@...gle.com>, Andrew Morton <akpm@...ux-foundation.org>,
 Mateusz Guzik <mjguzik@...il.com>, Muchun Song <muchun.song@...ux.dev>,
 linux-mm@...ck.org, linux-kernel@...r.kernel.org,
 Will Deacon <will@...nel.org>
Subject: Re: [PATCH mm-unstable v1] mm/hugetlb_vmemmap: fix memory loads
 ordering

On 07.01.25 17:35, Matthew Wilcox wrote:
> On Tue, Jan 07, 2025 at 09:49:18AM +0100, David Hildenbrand wrote:
>>> +++ b/include/linux/page-flags.h
>>> @@ -212,7 +212,7 @@ static __always_inline const struct page *page_fixed_fake_head(const struct page
>>>    	 * cold cacheline in some cases.
>>>    	 */
>>>    	if (IS_ALIGNED((unsigned long)page, PAGE_SIZE) &&
>>> -	    test_bit(PG_head, &page->flags)) {
>>> +	    test_bit_acquire(PG_head, &page->flags)) {
>>
>> This change will affect all page_fixed_fake_head() users, like ordinary
>> PageTail even on !hugetlb.
> 
> I've been looking at the callers of PageTail() because it's going to
> be a bit of a weird thing to be checking in the separate-page-and-folio
> world.  Obviously we can implement it, but there's a bit of a "But why
> would you want to ask that question" question.
> 
> Most current occurrences of PageTail() are in assertions of one form or
> another.  Fair enough, not performance critical.
> 
> make_device_exclusive_range() is a little weird; looks like it's trying
> to make sure that each folio is only made exclusive once, and ignore any
> partial folios which overlap the start of the area.

I could have sworn we only support small folios here, but looks like
we do support large folios.

IIUC, there is no way to identify reliably "this folio is device exclusive",
the only hint is "no mappings". The following might do:

diff --git a/mm/rmap.c b/mm/rmap.c
index c6c4d4ea29a7e..1424d0a351a86 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -2543,7 +2543,13 @@ int make_device_exclusive_range(struct mm_struct *mm, unsigned long start,
  
         for (i = 0; i < npages; i++, start += PAGE_SIZE) {
                 struct folio *folio = page_folio(pages[i]);
-               if (PageTail(pages[i]) || !folio_trylock(folio)) {
+
+               /*
+                * If there are no mappings, either the folio is actually
+                * unmapped or only device-exclusive swap entries point at
+                * this folio.
+                */
+               if (!folio_mapped(folio) || !folio_trylock(folio)) {
                         folio_put(folio);
                         pages[i] = NULL;
                         continue;


> 
> damon_get_folio() wants to fail for tail pages.  Fair enough.
> 
> split_huge_pages_all() is debug code.
> 
> page_idle_get_folio() is like damon.
> 
> That's it.  We don't seem to have any PageTail() callers in critical
> code any more.

Ah, you're right. Interestingly, PageTransTail() is even unused?

-- 
Cheers,

David / dhildenb