[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZmjFD8jRt4JkKbxN@x1n>
Date: Tue, 11 Jun 2024 17:43:43 -0400
From: Peter Xu <peterx@...hat.com>
To: LEROY Christophe <christophe.leroy2@...soprasteria.com>
Cc: Oscar Salvador <osalvador@...e.de>,
Andrew Morton <akpm@...ux-foundation.org>,
Jason Gunthorpe <jgg@...dia.com>,
Michael Ellerman <mpe@...erman.id.au>,
Nicholas Piggin <npiggin@...il.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
"linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>
Subject: Re: [PATCH v5 02/18] mm: Define __pte_leaf_size() to also take a PMD
entry
On Tue, Jun 11, 2024 at 07:00:14PM +0000, LEROY Christophe wrote:
> But what about something like
>
> static inline pte_t pmd_pte(pmd_t pmd)
> {
> return *(pte_t *)pmd_page_vaddr(pmd);
> }
>
> Would it do the trick ?
>
> Of course it would require to carefully make sure all accesses are done
> through pmd_pte().
>
> Would that work ?
Looks possible to me. It's just that we may miss some spots, and it can
hide in the details.
I'm looking at Power's pmd_access_permitted() right below pmd_write(),
which indeed uses pmd_pte() already. However before that there's also the
other call to pmd_is_serializing(), which doesn't look alright to work on
pgtable pages.. In this case maybe it's easy, as I assume pgtable page is
stable. Didn't further look, though.
Said that, this doesn't look like a blocker. So maybe worth trying if we're
careful and with some good testing coverages.
Thanks,
--
Peter Xu
Powered by blists - more mailing lists