linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Christophe Leroy <christophe.leroy@csgroup.eu>
To: Oscar Salvador <osalvador@suse.de>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Peter Zijlstra <peterz@infradead.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Jason Gunthorpe <jgg@nvidia.com>, Peter Xu <peterx@redhat.com>,
	Nicholas Piggin <npiggin@gmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [RFC PATCH v2 06/20] powerpc/8xx: Fix size given to set_huge_pte_at()
Date: Wed, 22 May 2024 12:18:19 +0000	[thread overview]
Message-ID: <3ba5fdd6-8d37-4c82-91bf-0517bb751901@csgroup.eu> (raw)
In-Reply-To: <f09a21cd-4152-44b2-9874-5afaa894bcbc@csgroup.eu>

+Peter Z. who added that commit.

Le 22/05/2024 à 10:32, Christophe Leroy a écrit :
> 
> 
> Le 21/05/2024 à 11:26, Oscar Salvador a écrit :
>> On Tue, May 21, 2024 at 10:48:21AM +1000, Michael Ellerman wrote:
>>> Yeah I can. Does it actually cause a bug at runtime (I assume so)?
>>
>> No, currently set_huge_pte_at() from 8xx ignores the 'sz' parameter.
>> But it will be used after this series.
>>
> 
> Ah yes, I mixed things up with something else in my mind.
> 
> So this patch doesn't qualify as a fix and doesn't need to be handled 
> separately from the series and doesn't really need to go on top of the 
> series either, I think it is better to keep it grouped with other 8xx 
> changes.
> 

I remember now, what I had in mind was commit c5eecbb58f65 
("powerpc/8xx: Implement pXX_leaf_size() support")

That commit is buggy, because pgd_leaf() will always return false on 
8xx. First of all pgd_leaf() could only return true on a target with 
P4Ds. Without P4Ds it should just return 0 like pgd_none(), pgd_bad(), 
... as defined in include/asm-generic/pgtable-nop4d.h

So it is pmd_leaf_size() that could eventually return something for 8xx.
But as 8xx is using hugepd, at the best case it will return crap, worst 
case the read will go in the weed.

To be correct we should had support of hugepd in perf_get_pgtable_size() 
but that's not trivial and this series is aiming at removing hugepd 
completely so there is no point in fixing stuff here, except maybe for 
stable ?

  reply	other threads:[~2024-05-22 12:18 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-17 18:59 [RFC PATCH v2 00/20] Reimplement huge pages without hugepd on powerpc (8xx, e500, book3s/64) Christophe Leroy
2024-05-17 18:59 ` [RFC PATCH v2 01/20] mm: Provide pagesize to pmd_populate() Christophe Leroy
2024-05-20  9:01   ` Oscar Salvador
2024-05-20 16:24     ` Christophe Leroy
2024-05-21 11:57       ` Oscar Salvador
2024-05-22  8:37         ` Christophe Leroy
2024-05-17 18:59 ` [RFC PATCH v2 02/20] mm: Provide page size to pte_alloc_huge() Christophe Leroy
2024-05-17 18:59 ` [RFC PATCH v2 03/20] mm: Provide pmd to pte_leaf_size() Christophe Leroy
2024-05-21  9:39   ` Oscar Salvador
2024-05-22 10:22     ` Christophe Leroy
2024-05-17 18:59 ` [RFC PATCH v2 04/20] mm: Provide mm_struct and address to huge_ptep_get() Christophe Leroy
2024-05-17 18:59 ` [RFC PATCH v2 05/20] powerpc/mm: Allow hugepages without hugepd Christophe Leroy
2024-05-17 19:00 ` [RFC PATCH v2 06/20] powerpc/8xx: Fix size given to set_huge_pte_at() Christophe Leroy
2024-05-20  9:14   ` Oscar Salvador
2024-05-20 16:31     ` Christophe Leroy
2024-05-20 17:42       ` Oscar Salvador
2024-05-22  8:45         ` Christophe Leroy
2024-05-21  0:48       ` Michael Ellerman
2024-05-21  9:26         ` Oscar Salvador
2024-05-22  8:32           ` Christophe Leroy
2024-05-22 12:18             ` Christophe Leroy [this message]
2024-05-17 19:00 ` [RFC PATCH v2 07/20] powerpc/8xx: Rework support for 8M pages using contiguous PTE entries Christophe Leroy
2024-05-24 10:02   ` Oscar Salvador
2024-05-24 11:47     ` Christophe Leroy
2024-05-17 19:00 ` [RFC PATCH v2 08/20] powerpc/8xx: Simplify struct mmu_psize_def Christophe Leroy
2024-05-25  3:36   ` Oscar Salvador
2024-05-17 19:00 ` [RFC PATCH v2 09/20] powerpc/mm: Remove _PAGE_PSIZE Christophe Leroy
2024-05-25  3:40   ` Oscar Salvador
2024-05-17 19:00 ` [RFC PATCH v2 10/20] powerpc/mm: Fix __find_linux_pte() on 32 bits with PMD leaf entries Christophe Leroy
2024-05-25  4:12   ` Oscar Salvador
2024-05-25  6:41     ` Christophe Leroy
2024-05-17 19:00 ` [RFC PATCH v2 11/20] powerpc/mm: Complement huge_pte_alloc() for all non HUGEPD setups Christophe Leroy
2024-05-25  4:29   ` Oscar Salvador
2024-05-25  6:44     ` Christophe Leroy
2024-05-25 10:33       ` Oscar Salvador
2024-05-17 19:00 ` [RFC PATCH v2 12/20] powerpc/64e: Remove unneeded #ifdef CONFIG_PPC_E500 Christophe Leroy
2024-05-24  7:31   ` Michael Ellerman
2024-05-24  8:45     ` Christophe Leroy
2024-05-17 19:00 ` [RFC PATCH v2 13/20] powerpc/64e: Clean up impossible setups Christophe Leroy
2024-05-17 19:00 ` [RFC PATCH v2 14/20] powerpc/e500: Remove enc field from struct mmu_psize_def Christophe Leroy
2024-05-25  4:35   ` Oscar Salvador
2024-05-17 19:00 ` [RFC PATCH v2 15/20] powerpc/85xx: Switch to 64 bits PGD Christophe Leroy
2024-05-25  4:54   ` Oscar Salvador
2024-05-25  9:02     ` Christophe Leroy
2024-05-17 19:00 ` [RFC PATCH v2 16/20] powerpc/e500: Encode hugepage size in PTE bits Christophe Leroy
2024-05-17 19:00 ` [RFC PATCH v2 17/20] powerpc/e500: Use contiguous PMD instead of hugepd Christophe Leroy
2024-05-17 19:00 ` [RFC PATCH v2 18/20] powerpc/64s: Use contiguous PMD/PUD instead of HUGEPD Christophe Leroy
2024-05-20 12:54   ` Nicholas Piggin
2024-05-20 16:43     ` Christophe Leroy
2024-05-22  1:13       ` Nicholas Piggin
2024-05-22  9:32         ` Christophe Leroy
2024-05-22 12:23         ` Jason Gunthorpe
2024-05-17 19:00 ` [RFC PATCH v2 19/20] powerpc/mm: Remove hugepd leftovers Christophe Leroy
2024-05-17 19:00 ` [RFC PATCH v2 20/20] mm: Remove CONFIG_ARCH_HAS_HUGEPD Christophe Leroy
2024-05-17 19:06 ` [RFC PATCH v2 00/20] Reimplement huge pages without hugepd on powerpc (8xx, e500, book3s/64) Jason Gunthorpe
2024-05-18  6:28   ` Christophe Leroy
2024-05-23 19:40 ` Peter Xu
2024-05-24  4:46   ` Michael Ellerman
2024-05-27 14:14     ` Peter Xu
2024-05-24  6:31   ` Oscar Salvador

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=3ba5fdd6-8d37-4c82-91bf-0517bb751901@csgroup.eu \
    --to=christophe.leroy@csgroup.eu \
    --cc=akpm@linux-foundation.org \
    --cc=jgg@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=npiggin@gmail.com \
    --cc=osalvador@suse.de \
    --cc=peterx@redhat.com \
    --cc=peterz@infradead.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