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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.