From: Michael Ellerman <mpe@ellerman.id.au>
To: David Hildenbrand <david@redhat.com>, Peter Xu <peterx@redhat.com>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
James Houghton <jthoughton@google.com>,
stable@vger.kernel.org, Oscar Salvador <osalvador@suse.de>,
Muchun Song <muchun.song@linux.dev>,
Baolin Wang <baolin.wang@linux.alibaba.com>,
Christophe Leroy <christophe.leroy@csgroup.eu>,
Nicholas Piggin <npiggin@gmail.com>
Subject: Re: [PATCH v3] mm/hugetlb: fix hugetlb vs. core-mm PT locking
Date: Thu, 01 Aug 2024 12:03:30 +1000 [thread overview]
Message-ID: <871q39ov7x.fsf@mail.lhotse> (raw)
In-Reply-To: <2b0131cf-d066-44ba-96d9-a611448cbaf9@redhat.com>
David Hildenbrand <david@redhat.com> writes:
> On 31.07.24 16:54, Peter Xu wrote:
...
>>
>> The other nitpick is, I didn't yet find any arch that use non-zero order
>> page for pte pgtables. I would give it a shot with dropping the mask thing
>> then see what explodes (which I don't expect any, per my read..), but yeah
>> I understand we saw some already due to other things, so I think it's fine
>> in this hugetlb path (that we're removing) we do a few more math if you
>> think that's easier for you.
>
> I threw
> BUILD_BUG_ON(PTRS_PER_PTE * sizeof(pte_t) > PAGE_SIZE);
> into pte_lockptr() and did a bunch of cross-compiles.
>
> And for some reason it blows up for powernv (powernv_defconfig) and
> pseries (pseries_defconfig).
>
>
> In function 'pte_lockptr',
> inlined from 'pte_offset_map_nolock' at mm/pgtable-generic.c:316:11:
> ././include/linux/compiler_types.h:510:45: error: call to '__compiletime_assert_291' declared with attribute error: BUILD_BUG_ON failed: PTRS_PER_PTE * sizeof(pte_t) > PAGE_SIZE
> 510 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
> | ^
> ././include/linux/compiler_types.h:491:25: note: in definition of macro '__compiletime_assert'
> 491 | prefix ## suffix(); \
> | ^~~~~~
> ././include/linux/compiler_types.h:510:9: note: in expansion of macro '_compiletime_assert'
> 510 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
> | ^~~~~~~~~~~~~~~~~~~
> ./include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert'
> 39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
> | ^~~~~~~~~~~~~~~~~~
> ./include/linux/build_bug.h:50:9: note: in expansion of macro 'BUILD_BUG_ON_MSG'
> 50 | BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
> | ^~~~~~~~~~~~~~~~
> ./include/linux/mm.h:2926:9: note: in expansion of macro 'BUILD_BUG_ON'
> 2926 | BUILD_BUG_ON(PTRS_PER_PTE * sizeof(pte_t) > PAGE_SIZE);
> | ^~~~~~~~~~~~
...
>
> pte_alloc_one() ends up calling pte_fragment_alloc(mm, 0). But there we always
> end up calling pagetable_alloc(, 0).
>
> And fragments are supposed to be <= a single page.
>
> Now I'm confused what's wrong here ... am I missing something obvious?
>
> CCing some powerpc folks. Is this some pte_t oddity?
It will be because PTRS_PER_PTE is not a compile time constant :(
$ git grep "define PTRS_PER_PTE" arch/powerpc/include/asm/book3s/64
arch/powerpc/include/asm/book3s/64/pgtable.h:#define PTRS_PER_PTE (1 << PTE_INDEX_SIZE)
$ git grep "define PTE_INDEX_SIZE" arch/powerpc/include/asm/book3s/64
arch/powerpc/include/asm/book3s/64/pgtable.h:#define PTE_INDEX_SIZE __pte_index_size
$ git grep __pte_index_size arch/powerpc/mm/pgtable_64.c
arch/powerpc/mm/pgtable_64.c:unsigned long __pte_index_size;
Which is because the pseries/powernv (book3s64) kernel supports either
the HPT or Radix MMU at runtime, and they have different page table
geometry.
If you change it to use MAX_PTRS_PER_PTE it should work (that's defined
for all arches).
cheers
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 381750f41767..1fd9c296c0b6 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2924,6 +2924,8 @@ static inline spinlock_t *ptlock_ptr(struct ptdesc *ptdesc)
static inline spinlock_t *pte_lockptr(struct mm_struct *mm, pte_t *pte)
{
/* PTE page tables don't currently exceed a single page. */
+ BUILD_BUG_ON(MAX_PTRS_PER_PTE * sizeof(pte_t) > PAGE_SIZE);
+
return ptlock_ptr(virt_to_ptdesc(pte));
}
next prev parent reply other threads:[~2024-08-01 2:03 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-31 12:21 [PATCH v3] mm/hugetlb: fix hugetlb vs. core-mm PT locking David Hildenbrand
2024-07-31 14:54 ` Peter Xu
2024-07-31 16:33 ` David Hildenbrand
2024-08-01 2:03 ` Michael Ellerman [this message]
2024-08-01 7:35 ` David Hildenbrand
2024-08-14 17:25 ` Christophe Leroy
2024-08-01 8:50 ` David Hildenbrand
2024-08-01 13:52 ` Peter Xu
2024-08-01 15:35 ` David Hildenbrand
2024-08-01 16:07 ` Peter Xu
2024-08-01 16:24 ` David Hildenbrand
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=871q39ov7x.fsf@mail.lhotse \
--to=mpe@ellerman.id.au \
--cc=baolin.wang@linux.alibaba.com \
--cc=christophe.leroy@csgroup.eu \
--cc=david@redhat.com \
--cc=jthoughton@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=muchun.song@linux.dev \
--cc=npiggin@gmail.com \
--cc=osalvador@suse.de \
--cc=peterx@redhat.com \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).