From: Anshuman Khandual <anshuman.khandual@arm.com>
To: "Kirill A. Shutemov" <kirill@shutemov.name>
Cc: linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>,
Vlastimil Babka <vbabka@suse.cz>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Thomas Gleixner <tglx@linutronix.de>,
Mike Rapoport <rppt@linux.vnet.ibm.com>,
Jason Gunthorpe <jgg@ziepe.ca>,
Dan Williams <dan.j.williams@intel.com>,
Peter Zijlstra <peterz@infradead.org>,
Michal Hocko <mhocko@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Mark Brown <broonie@kernel.org>,
Steven Price <Steven.Price@arm.com>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
Masahiro Yamada <yamada.masahiro@socionext.com>,
Kees Cook <keescook@chromium.org>,
Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
Matthew Wilcox <willy@infradead.org>,
Sri Krishna chowdary <schowdary@nvidia.com>,
Dave Hansen <dave.hansen@intel.com>,
Russell King - ARM Linux <linux@armlinux.org.uk>,
Michael Ellerman <mpe@ellerman.id.au>,
Paul Mackerras <paulus@samba.org>,
Martin Schwidefsky <schwidefsky@de.ibm.com>,
Heiko Carstens <heiko.carstens@de.ibm.com>,
"David S. Miller" <davem@davemloft.net>,
Vineet Gupta <vgupta@synopsys.com>,
James Hogan <jhogan@kernel.org>,
Paul Burton <paul.burton@mips.com>,
Ralf Baechle <ralf@linux-mips.org>,
linux-snps-arc@lists.infradead.org, linux-mips@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-ia64@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org,
linux-sh@vger.kernel.org, sparclinux@vger.kernel.org,
x86@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/1] mm/pgtable/debug: Add test validating architecture page table helpers
Date: Fri, 6 Sep 2019 12:33:14 +0530 [thread overview]
Message-ID: <9c226f84-fe8f-8438-b378-b6659cccfcd1@arm.com> (raw)
In-Reply-To: <20190905085910.i6dppgnqi4ple22w@box.shutemov.name>
On 09/05/2019 02:29 PM, Kirill A. Shutemov wrote:
> On Thu, Sep 05, 2019 at 01:48:27PM +0530, Anshuman Khandual wrote:
>>>> +#define VADDR_TEST (PGDIR_SIZE + PUD_SIZE + PMD_SIZE + PAGE_SIZE)
>>>
>>> What is special about this address? How do you know if it is not occupied
>>> yet?
>>
>> We are creating the page table from scratch after allocating an mm_struct
>> for a given random virtual address 'VADDR_TEST'. Hence nothing is occupied
>> just yet. There is nothing special about this address, just that it tries
>> to ensure the page table entries are being created with some offset from
>> beginning of respective page table page at all levels ? The idea is to
>> have a more representative form of page table structure for test.
>
> Why P4D_SIZE is missing?
That was an omission even though I was wondering whether it will be
applicable or even make sense on platforms which dont have real P4D.
>
> Are you sure it will not land into kernel address space on any arch?
Can it even cross user virtual address range with just a single span
at each page table level ? TBH I did not think about that possibility.
>
> I think more robust way to deal with this would be using
> get_unmapped_area() instead of fixed address.
Makes sense and probably its better to get a virtual address which
is known to have been checked against all boundary conditions. Will
explore around get_unmapped_area() in this regard.
>
>> This makes sense for runtime cases but there is a problem here.
>>
>> On arm64, pgd_populate() which takes (pud_t *) as last argument instead of
>> (p4d_t *) will fail to build when not wrapped in !__PAGETABLE_P4D_FOLDED
>> on certain configurations.
>>
>> ./arch/arm64/include/asm/pgalloc.h:81:75: note:
>> expected ‘pud_t *’ {aka ‘struct <anonymous> *’}
>> but argument is of type ‘pgd_t *’ {aka ‘struct <anonymous> *’}
>> static inline void pgd_populate(struct mm_struct *mm, pgd_t *pgdp, pud_t *pudp)
>> ~~~~~~~^~~~
>> Wondering if this is something to be fixed on arm64 or its more general
>> problem. Will look into this further.
>
> I think you need wrap this into #ifndef __ARCH_HAS_5LEVEL_HACK.
Okay.
>
>>>> + pmd_populate_tests(mm, pmdp, (pgtable_t) page);
>>>
>>> This is not correct for architectures that defines pgtable_t as pte_t
>>> pointer, not struct page pointer.
>>
>> Right, a grep on the source confirms that.
>>
>> These platforms define pgtable_t as struct page *
>>
>> arch/alpha/include/asm/page.h:typedef struct page *pgtable_t;
>> arch/arm/include/asm/page.h:typedef struct page *pgtable_t;
>> arch/arm64/include/asm/page.h:typedef struct page *pgtable_t;
>> arch/csky/include/asm/page.h:typedef struct page *pgtable_t;
>> arch/hexagon/include/asm/page.h:typedef struct page *pgtable_t;
>> arch/ia64/include/asm/page.h: typedef struct page *pgtable_t;
>> arch/ia64/include/asm/page.h: typedef struct page *pgtable_t;
>> arch/m68k/include/asm/page.h:typedef struct page *pgtable_t;
>> arch/microblaze/include/asm/page.h:typedef struct page *pgtable_t;
>> arch/mips/include/asm/page.h:typedef struct page *pgtable_t;
>> arch/nds32/include/asm/page.h:typedef struct page *pgtable_t;
>> arch/nios2/include/asm/page.h:typedef struct page *pgtable_t;
>> arch/openrisc/include/asm/page.h:typedef struct page *pgtable_t;
>> arch/parisc/include/asm/page.h:typedef struct page *pgtable_t;
>> arch/riscv/include/asm/page.h:typedef struct page *pgtable_t;
>> arch/sh/include/asm/page.h:typedef struct page *pgtable_t;
>> arch/sparc/include/asm/page_32.h:typedef struct page *pgtable_t;
>> arch/um/include/asm/page.h:typedef struct page *pgtable_t;
>> arch/unicore32/include/asm/page.h:typedef struct page *pgtable_t;
>> arch/x86/include/asm/pgtable_types.h:typedef struct page *pgtable_t;
>> arch/xtensa/include/asm/page.h:typedef struct page *pgtable_t;
>>
>> These platforms define pgtable_t as pte_t *
>>
>> arch/arc/include/asm/page.h:typedef pte_t * pgtable_t;
>> arch/powerpc/include/asm/mmu.h:typedef pte_t *pgtable_t;
>> arch/s390/include/asm/page.h:typedef pte_t *pgtable_t;
>> arch/sparc/include/asm/page_64.h:typedef pte_t *pgtable_t;
>>
>> Should we need have two pmd_populate_tests() definitions with
>> different arguments (struct page pointer or pte_t pointer) and then
>> call either one after detecting the given platform ?
>
> Use pte_alloc_one() instead of alloc_mapped_page() to allocate the page
> table.
Right, the PTE page table page should come from pte_alloc_one() instead
directly from a struct page. The functions pte_alloc_one() and pte_free()
operate on (struct page or pte_t) pointers depending applicable pgtable_t
definition (in cases where platform defines otherwise). Will fix it.
>
>>>> + pud_populate_tests(mm, pudp, pmdp);
>>>> + p4d_populate_tests(mm, p4dp, pudp);
>>>> + pgd_populate_tests(mm, pgdp, p4dp);
>>>
>>> This is wrong. All p?dp points to the second entry in page table entry.
>>> This is not valid pointer for page table and triggers p?d_bad() on x86.
>>
>> Yeah these are second entries because of the way we create the page table.
>> But I guess its applicable only to the second argument in all these above
>> cases because the first argument can be any valid entry on previous page
>> table level.
>
> Yes:
>
> @@ -397,9 +396,9 @@ static int __init arch_pgtable_tests_init(void)
> pgd_clear_tests(pgdp);
>
> pmd_populate_tests(mm, pmdp, (pgtable_t) page);
> - pud_populate_tests(mm, pudp, pmdp);
> - p4d_populate_tests(mm, p4dp, pudp);
> - pgd_populate_tests(mm, pgdp, p4dp);
> + pud_populate_tests(mm, pudp, saved_pmdp);
> + p4d_populate_tests(mm, p4dp, saved_pudp);
> + pgd_populate_tests(mm, pgdp, saved_p4dp);
Sure.
next prev parent reply other threads:[~2019-09-06 7:03 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-03 8:01 [PATCH 0/1] mm/debug: Add tests for architecture exported page table helpers Anshuman Khandual
2019-09-03 8:01 ` [PATCH 1/1] mm/pgtable/debug: Add test validating architecture " Anshuman Khandual
2019-09-03 11:13 ` kbuild test robot
2019-09-04 6:14 ` Anshuman Khandual
2019-09-04 14:19 ` Kirill A. Shutemov
2019-09-05 8:18 ` Anshuman Khandual
2019-09-05 8:59 ` Kirill A. Shutemov
2019-09-06 7:03 ` Anshuman Khandual [this message]
2019-09-04 20:16 ` Gerald Schaefer
2019-09-05 9:18 ` Anshuman Khandual
2019-09-05 17:06 ` Gerald Schaefer
2019-09-06 6:28 ` Anshuman Khandual
2019-09-06 19:03 ` Gerald Schaefer
2019-09-09 6:26 ` Anshuman Khandual
2019-09-09 15:13 ` Kirill A. Shutemov
2019-09-10 3:56 ` Anshuman Khandual
2019-09-10 4:45 ` Christophe Leroy
2019-09-10 5:43 ` Anshuman Khandual
2019-09-09 16:51 ` Gerald Schaefer
2019-09-04 23:14 ` Dave Hansen
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=9c226f84-fe8f-8438-b378-b6659cccfcd1@arm.com \
--to=anshuman.khandual@arm.com \
--cc=Steven.Price@arm.com \
--cc=akpm@linux-foundation.org \
--cc=ard.biesheuvel@linaro.org \
--cc=broonie@kernel.org \
--cc=dan.j.williams@intel.com \
--cc=dave.hansen@intel.com \
--cc=davem@davemloft.net \
--cc=gregkh@linuxfoundation.org \
--cc=heiko.carstens@de.ibm.com \
--cc=jgg@ziepe.ca \
--cc=jhogan@kernel.org \
--cc=keescook@chromium.org \
--cc=kirill@shutemov.name \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-s390@vger.kernel.org \
--cc=linux-sh@vger.kernel.org \
--cc=linux-snps-arc@lists.infradead.org \
--cc=linux@armlinux.org.uk \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mark.rutland@arm.com \
--cc=mhocko@kernel.org \
--cc=mpe@ellerman.id.au \
--cc=paul.burton@mips.com \
--cc=paulus@samba.org \
--cc=penguin-kernel@i-love.sakura.ne.jp \
--cc=peterz@infradead.org \
--cc=ralf@linux-mips.org \
--cc=rppt@linux.vnet.ibm.com \
--cc=schowdary@nvidia.com \
--cc=schwidefsky@de.ibm.com \
--cc=sparclinux@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=vbabka@suse.cz \
--cc=vgupta@synopsys.com \
--cc=willy@infradead.org \
--cc=x86@kernel.org \
--cc=yamada.masahiro@socionext.com \
/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).