All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Ellerman <mpe@ellerman.id.au>
To: Steven Price <steven.price@arm.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-mm@kvack.org
Cc: "Mark Rutland" <mark.rutland@arm.com>,
	x86@kernel.org, "Arnd Bergmann" <arnd@arndb.de>,
	"Ard Biesheuvel" <ard.biesheuvel@linaro.org>,
	"Peter Zijlstra" <peterz@infradead.org>,
	"Catalin Marinas" <catalin.marinas@arm.com>,
	"Dave Hansen" <dave.hansen@linux.intel.com>,
	linux-kernel@vger.kernel.org,
	"Jérôme Glisse" <jglisse@redhat.com>,
	"Ingo Molnar" <mingo@redhat.com>,
	"Borislav Petkov" <bp@alien8.de>,
	"Andy Lutomirski" <luto@kernel.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	"James Morse" <james.morse@arm.com>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Will Deacon" <will@kernel.org>,
	linux-arm-kernel@lists.infradead.org, "Liang,
	Kan" <kan.liang@linux.intel.com>
Subject: Re: [PATCH v17 01/23] mm: Add generic p?d_leaf() macros
Date: Sat, 21 Dec 2019 21:35:58 +1100	[thread overview]
Message-ID: <87v9qakltd.fsf@mpe.ellerman.id.au> (raw)
In-Reply-To: <0951d79f-919a-4a9d-00f7-b40be96af118@arm.com>

Steven Price <steven.price@arm.com> writes:
> On 19/12/2019 11:43, Michael Ellerman wrote:
>> Steven Price <steven.price@arm.com> writes:
>>> Exposing the pud/pgd levels of the page tables to walk_page_range() means
>>> we may come across the exotic large mappings that come with large areas
>>> of contiguous memory (such as the kernel's linear map).
>>>
>>> For architectures that don't provide all p?d_leaf() macros, provide
>>> generic do nothing default that are suitable where there cannot be leaf
>>> pages at that level. Futher patches will add implementations for
>>> individual architectures.
>>>
>>> The name p?d_leaf() is chosen to minimize the confusion with existing
>>> uses of "large" pages and "huge" pages which do not necessary mean that
>>> the entry is a leaf (for example it may be a set of contiguous entries
>>> that only take 1 TLB slot). For the purpose of walking the page tables
>>> we don't need to know how it will be represented in the TLB, but we do
>>> need to know for sure if it is a leaf of the tree.
>>>
>>> Signed-off-by: Steven Price <steven.price@arm.com>
>>> Acked-by: Mark Rutland <mark.rutland@arm.com>
>>> ---
>>>  include/asm-generic/pgtable.h | 20 ++++++++++++++++++++
>>>  1 file changed, 20 insertions(+)
>>>
>>> diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
>>> index 798ea36a0549..e2e2bef07dd2 100644
>>> --- a/include/asm-generic/pgtable.h
>>> +++ b/include/asm-generic/pgtable.h
>>> @@ -1238,4 +1238,24 @@ static inline bool arch_has_pfn_modify_check(void)
>>>  #define mm_pmd_folded(mm)	__is_defined(__PAGETABLE_PMD_FOLDED)
>>>  #endif
>>>  
>>> +/*
>>> + * p?d_leaf() - true if this entry is a final mapping to a physical address.
>>> + * This differs from p?d_huge() by the fact that they are always available (if
>>> + * the architecture supports large pages at the appropriate level) even
>>> + * if CONFIG_HUGETLB_PAGE is not defined.
>>> + * Only meaningful when called on a valid entry.
>>> + */
>>> +#ifndef pgd_leaf
>>> +#define pgd_leaf(x)	0
>>> +#endif
>>> +#ifndef p4d_leaf
>>> +#define p4d_leaf(x)	0
>>> +#endif
>>> +#ifndef pud_leaf
>>> +#define pud_leaf(x)	0
>>> +#endif
>>> +#ifndef pmd_leaf
>>> +#define pmd_leaf(x)	0
>>> +#endif
>> 
>> Any reason you made these #defines rather than static inlines?
>
> No strong reason - but these have to be #defines in the arch overrides
> so the #ifndef works, so I was being consistent here.

We handle that usually just with eg:

static inline bool pgd_leaf(pgd_t pgd)
{
	...
}
#define pgd_leaf pgd_leaf

> I guess a static inline might avoid warnings although I haven't seen
> any.

If anything I'd expect it to cause warnings, for example if someone is
doing pgd_leaf(pmd), but that would be good to catch.

cheers

WARNING: multiple messages have this Message-ID (diff)
From: Michael Ellerman <mpe@ellerman.id.au>
To: Steven Price <steven.price@arm.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-mm@kvack.org
Cc: "Mark Rutland" <mark.rutland@arm.com>,
	"Dave Hansen" <dave.hansen@linux.intel.com>,
	"Arnd Bergmann" <arnd@arndb.de>,
	"Ard Biesheuvel" <ard.biesheuvel@linaro.org>,
	"Peter Zijlstra" <peterz@infradead.org>,
	"Catalin Marinas" <catalin.marinas@arm.com>,
	x86@kernel.org, linux-kernel@vger.kernel.org,
	"Jérôme Glisse" <jglisse@redhat.com>,
	"Ingo Molnar" <mingo@redhat.com>,
	"Borislav Petkov" <bp@alien8.de>,
	"Andy Lutomirski" <luto@kernel.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	"James Morse" <james.morse@arm.com>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Will Deacon" <will@kernel.org>,
	linux-arm-kernel@lists.infradead.org, "Liang,
	Kan" <kan.liang@linux.intel.com>
Subject: Re: [PATCH v17 01/23] mm: Add generic p?d_leaf() macros
Date: Sat, 21 Dec 2019 21:35:58 +1100	[thread overview]
Message-ID: <87v9qakltd.fsf@mpe.ellerman.id.au> (raw)
In-Reply-To: <0951d79f-919a-4a9d-00f7-b40be96af118@arm.com>

Steven Price <steven.price@arm.com> writes:
> On 19/12/2019 11:43, Michael Ellerman wrote:
>> Steven Price <steven.price@arm.com> writes:
>>> Exposing the pud/pgd levels of the page tables to walk_page_range() means
>>> we may come across the exotic large mappings that come with large areas
>>> of contiguous memory (such as the kernel's linear map).
>>>
>>> For architectures that don't provide all p?d_leaf() macros, provide
>>> generic do nothing default that are suitable where there cannot be leaf
>>> pages at that level. Futher patches will add implementations for
>>> individual architectures.
>>>
>>> The name p?d_leaf() is chosen to minimize the confusion with existing
>>> uses of "large" pages and "huge" pages which do not necessary mean that
>>> the entry is a leaf (for example it may be a set of contiguous entries
>>> that only take 1 TLB slot). For the purpose of walking the page tables
>>> we don't need to know how it will be represented in the TLB, but we do
>>> need to know for sure if it is a leaf of the tree.
>>>
>>> Signed-off-by: Steven Price <steven.price@arm.com>
>>> Acked-by: Mark Rutland <mark.rutland@arm.com>
>>> ---
>>>  include/asm-generic/pgtable.h | 20 ++++++++++++++++++++
>>>  1 file changed, 20 insertions(+)
>>>
>>> diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
>>> index 798ea36a0549..e2e2bef07dd2 100644
>>> --- a/include/asm-generic/pgtable.h
>>> +++ b/include/asm-generic/pgtable.h
>>> @@ -1238,4 +1238,24 @@ static inline bool arch_has_pfn_modify_check(void)
>>>  #define mm_pmd_folded(mm)	__is_defined(__PAGETABLE_PMD_FOLDED)
>>>  #endif
>>>  
>>> +/*
>>> + * p?d_leaf() - true if this entry is a final mapping to a physical address.
>>> + * This differs from p?d_huge() by the fact that they are always available (if
>>> + * the architecture supports large pages at the appropriate level) even
>>> + * if CONFIG_HUGETLB_PAGE is not defined.
>>> + * Only meaningful when called on a valid entry.
>>> + */
>>> +#ifndef pgd_leaf
>>> +#define pgd_leaf(x)	0
>>> +#endif
>>> +#ifndef p4d_leaf
>>> +#define p4d_leaf(x)	0
>>> +#endif
>>> +#ifndef pud_leaf
>>> +#define pud_leaf(x)	0
>>> +#endif
>>> +#ifndef pmd_leaf
>>> +#define pmd_leaf(x)	0
>>> +#endif
>> 
>> Any reason you made these #defines rather than static inlines?
>
> No strong reason - but these have to be #defines in the arch overrides
> so the #ifndef works, so I was being consistent here.

We handle that usually just with eg:

static inline bool pgd_leaf(pgd_t pgd)
{
	...
}
#define pgd_leaf pgd_leaf

> I guess a static inline might avoid warnings although I haven't seen
> any.

If anything I'd expect it to cause warnings, for example if someone is
doing pgd_leaf(pmd), but that would be good to catch.

cheers

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2019-12-21 10:36 UTC|newest]

Thread overview: 75+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-18 16:23 [PATCH v17 00/23] Generic page walk and ptdump Steven Price
2019-12-18 16:23 ` Steven Price
2019-12-18 16:23 ` [PATCH v17 01/23] mm: Add generic p?d_leaf() macros Steven Price
2019-12-18 16:23   ` Steven Price
2019-12-19 11:43   ` Michael Ellerman
2019-12-19 11:43     ` Michael Ellerman
2019-12-20 11:48     ` Steven Price
2019-12-20 11:48       ` Steven Price
2019-12-21 10:35       ` Michael Ellerman [this message]
2019-12-21 10:35         ` Michael Ellerman
2019-12-18 16:23 ` [PATCH v17 02/23] arc: mm: Add p?d_leaf() definitions Steven Price
2019-12-18 16:23   ` Steven Price
2019-12-18 16:23   ` Steven Price
2019-12-18 16:23 ` [PATCH v17 03/23] arm: " Steven Price
2019-12-18 16:23   ` Steven Price
2019-12-18 16:23 ` [PATCH v17 04/23] arm64: " Steven Price
2019-12-18 16:23   ` Steven Price
2019-12-18 16:23 ` [PATCH v17 05/23] mips: " Steven Price
2019-12-18 16:23   ` Steven Price
2019-12-18 16:23 ` [PATCH v17 06/23] powerpc: " Steven Price
2019-12-18 16:23   ` Steven Price
2019-12-18 16:23   ` Steven Price
2019-12-19 11:49   ` Michael Ellerman
2019-12-19 11:49     ` Michael Ellerman
2019-12-19 11:49     ` Michael Ellerman
2019-12-19 11:49     ` Michael Ellerman
2019-12-20 11:53     ` Steven Price
2019-12-20 11:53       ` Steven Price
2019-12-20 11:53       ` Steven Price
2019-12-18 16:23 ` [PATCH v17 07/23] riscv: " Steven Price
2019-12-18 16:23   ` Steven Price
2019-12-18 16:23   ` Steven Price
2019-12-18 16:23 ` [PATCH v17 08/23] s390: " Steven Price
2019-12-18 16:23   ` Steven Price
2019-12-18 16:23 ` [PATCH v17 09/23] sparc: " Steven Price
2019-12-18 16:23   ` Steven Price
2019-12-18 16:23   ` Steven Price
2019-12-18 16:23 ` [PATCH v17 10/23] x86: " Steven Price
2019-12-18 16:23   ` Steven Price
2019-12-18 16:23 ` [PATCH v17 11/23] mm: pagewalk: Add p4d_entry() and pgd_entry() Steven Price
2019-12-18 16:23   ` Steven Price
2019-12-19 14:25   ` Thomas Hellström (VMware)
2019-12-19 14:25     ` Thomas Hellström (VMware)
2019-12-20 15:35     ` Steven Price
2019-12-20 15:35       ` Steven Price
2019-12-18 16:23 ` [PATCH v17 12/23] mm: pagewalk: Allow walking without vma Steven Price
2019-12-18 16:23   ` Steven Price
2019-12-18 16:23 ` [PATCH v17 13/23] mm: pagewalk: Don't lock PTEs for walk_page_range_novma() Steven Price
2019-12-18 16:23   ` Steven Price
2019-12-18 16:23 ` [PATCH v17 14/23] mm: pagewalk: fix termination condition in walk_pte_range() Steven Price
2019-12-18 16:23   ` Steven Price
2019-12-18 16:23 ` [PATCH v17 15/23] mm: pagewalk: Add 'depth' parameter to pte_hole Steven Price
2019-12-18 16:23   ` Steven Price
2019-12-18 16:23 ` [PATCH v17 16/23] x86: mm: Point to struct seq_file from struct pg_state Steven Price
2019-12-18 16:23   ` Steven Price
2019-12-18 16:23 ` [PATCH v17 17/23] x86: mm+efi: Convert ptdump_walk_pgd_level() to take a mm_struct Steven Price
2019-12-18 16:23   ` Steven Price
2019-12-18 16:23 ` [PATCH v17 18/23] x86: mm: Convert ptdump_walk_pgd_level_debugfs() to take an mm_struct Steven Price
2019-12-18 16:23   ` Steven Price
2019-12-18 16:23 ` [PATCH v17 19/23] mm: Add generic ptdump Steven Price
2019-12-18 16:23   ` Steven Price
2019-12-18 16:23 ` [PATCH v17 20/23] x86: mm: Convert dump_pagetables to use walk_page_range Steven Price
2019-12-18 16:23   ` Steven Price
2019-12-18 16:24 ` [PATCH v17 21/23] arm64: mm: Convert mm/dump.c to use walk_page_range() Steven Price
2019-12-18 16:24   ` Steven Price
2020-02-16 16:25   ` Ard Biesheuvel
2020-02-16 16:25     ` Ard Biesheuvel
2020-02-17 10:01     ` Steven Price
2020-02-17 10:01       ` Steven Price
2020-02-17 10:16       ` Ard Biesheuvel
2020-02-17 10:16         ` Ard Biesheuvel
2019-12-18 16:24 ` [PATCH v17 22/23] arm64: mm: Display non-present entries in ptdump Steven Price
2019-12-18 16:24   ` Steven Price
2019-12-18 16:24 ` [PATCH v17 23/23] mm: ptdump: Reduce level numbers by 1 in note_page() Steven Price
2019-12-18 16:24   ` Steven Price

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=87v9qakltd.fsf@mpe.ellerman.id.au \
    --to=mpe@ellerman.id.au \
    --cc=akpm@linux-foundation.org \
    --cc=ard.biesheuvel@linaro.org \
    --cc=arnd@arndb.de \
    --cc=bp@alien8.de \
    --cc=catalin.marinas@arm.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=james.morse@arm.com \
    --cc=jglisse@redhat.com \
    --cc=kan.liang@linux.intel.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=luto@kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=steven.price@arm.com \
    --cc=tglx@linutronix.de \
    --cc=will@kernel.org \
    --cc=x86@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.