All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anshuman Khandual <anshuman.khandual@arm.com>
To: Christophe Leroy <christophe.leroy@c-s.fr>, linux-mm@kvack.org
Cc: Mark Rutland <mark.rutland@arm.com>,
	linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>,
	James Hogan <jhogan@kernel.org>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	Michal Hocko <mhocko@kernel.org>,
	Dave Hansen <dave.hansen@intel.com>,
	Paul Mackerras <paulus@samba.org>,
	sparclinux@vger.kernel.org, Thomas Gleixner <tglx@linutronix.de>,
	linux-s390@vger.kernel.org, Jason Gunthorpe <jgg@ziepe.ca>,
	x86@kernel.org, Russell King - ARM Linux <linux@armlinux.org.uk>,
	Matthew Wilcox <willy@infradead.org>,
	Steven Price <Steven.Price@arm.com>,
	Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
	Gerald Schaefer <gerald.schaefer@de.ibm.com>,
	linux-snps-arc@lists.infradead.org,
	Kees Cook <keescook@chromium.org>,
	Mark Brown <broonie@kernel.org>,
	"Kirill A . Shutemov" <kirill@shutemov.name>,
	Dan Williams <dan.j.williams@intel.com>,
	Vlastimil Babka <vbabka@suse.cz>,
	linux-arm-kernel@lists.infradead.org,
	Sri Krishna chowdary <schowdary@nvidia.com>,
	Masahiro Yamada <yamada.masahiro@socionext.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	linux-mips@vger.kernel.org, Ralf Baechle <ralf@linux-mips.org>,
	linux-kernel@vger.kernel.org, Paul Burton <paul.burton@mips.com>,
	Mike Rapoport <rppt@linux.vnet.ibm.com>,
	Vineet Gupta <vgupta@synopsys.com>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linuxppc-dev@lists.ozlabs.org,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH] mm/pgtable/debug: Fix test validating architecture page table helpers
Date: Fri, 13 Sep 2019 08:54:45 +0000	[thread overview]
Message-ID: <bdf7f152-d093-1691-4e96-77da7eb9e20a@arm.com> (raw)
In-Reply-To: <cb226b56-ff20-3136-7ffb-890657e56870@c-s.fr>



On 09/13/2019 12:41 PM, Christophe Leroy wrote:
> 
> 
> Le 13/09/2019 à 09:03, Christophe Leroy a écrit :
>>
>>
>> Le 13/09/2019 à 08:58, Anshuman Khandual a écrit :
>>> On 09/13/2019 11:53 AM, Christophe Leroy wrote:
>>>> Fix build failure on powerpc.
>>>>
>>>> Fix preemption imbalance.
>>>>
>>>> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
>>>> ---
>>>>   mm/arch_pgtable_test.c | 3 +++
>>>>   1 file changed, 3 insertions(+)
>>>>
>>>> diff --git a/mm/arch_pgtable_test.c b/mm/arch_pgtable_test.c
>>>> index 8b4a92756ad8..f2b3c9ec35fa 100644
>>>> --- a/mm/arch_pgtable_test.c
>>>> +++ b/mm/arch_pgtable_test.c
>>>> @@ -24,6 +24,7 @@
>>>>   #include <linux/swap.h>
>>>>   #include <linux/swapops.h>
>>>>   #include <linux/sched/mm.h>
>>>> +#include <linux/highmem.h>
>>>
>>> This is okay.
>>>
>>>>   #include <asm/pgalloc.h>
>>>>   #include <asm/pgtable.h>
>>>> @@ -400,6 +401,8 @@ static int __init arch_pgtable_tests_init(void)
>>>>       p4d_clear_tests(p4dp);
>>>>       pgd_clear_tests(mm, pgdp);
>>>> +    pte_unmap(ptep);
>>>> +
>>>
>>> Now the preemption imbalance via pte_alloc_map() path i.e
>>>
>>> pte_alloc_map() -> pte_offset_map() -> kmap_atomic()
>>>
>>> Is not this very much powerpc 32 specific or this will be applicable
>>> for all platform which uses kmap_XXX() to map high memory ?
>>>
>>
>> See https://elixir.bootlin.com/linux/v5.3-rc8/source/include/linux/highmem.h#L91
>>
>> I think it applies at least to all arches using the generic implementation.
>>
>> Applies also to arm:
>> https://elixir.bootlin.com/linux/v5.3-rc8/source/arch/arm/mm/highmem.c#L52
>>
>> Applies also to mips:
>> https://elixir.bootlin.com/linux/v5.3-rc8/source/arch/mips/mm/highmem.c#L47
>>
>> Same on sparc:
>> https://elixir.bootlin.com/linux/v5.3-rc8/source/arch/sparc/mm/highmem.c#L52
>>
>> Same on x86:
>> https://elixir.bootlin.com/linux/v5.3-rc8/source/arch/x86/mm/highmem_32.c#L34
>>
>> I have not checked others, but I guess it is like that for all.
>>
> 
> 
> Seems like I answered too quickly. All kmap_atomic() do preempt_disable(), but not all pte_alloc_map() call kmap_atomic().
> 
> However, for instance ARM does:
> 
> https://elixir.bootlin.com/linux/v5.3-rc8/source/arch/arm/include/asm/pgtable.h#L200
> 
> And X86 as well:
> 
> https://elixir.bootlin.com/linux/v5.3-rc8/source/arch/x86/include/asm/pgtable_32.h#L51
> 
> Microblaze also:
> 
> https://elixir.bootlin.com/linux/v5.3-rc8/source/arch/microblaze/include/asm/pgtable.h#L495

All the above platforms checks out to be using k[un]map_atomic(). I am wondering whether
any of the intermediate levels will have similar problems on any these 32 bit platforms
or any other platforms which might be using generic k[un]map_atomic(). There can be many
permutations here.

	p4dp = p4d_alloc(mm, pgdp, vaddr);
	pudp = pud_alloc(mm, p4dp, vaddr);
	pmdp = pmd_alloc(mm, pudp, vaddr);

Otherwise pte_alloc_map()/pte_unmap() looks good enough which will atleast take care of
a known failure.

WARNING: multiple messages have this Message-ID (diff)
From: Anshuman Khandual <anshuman.khandual@arm.com>
To: Christophe Leroy <christophe.leroy@c-s.fr>, linux-mm@kvack.org
Cc: Mark Rutland <mark.rutland@arm.com>,
	linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>,
	James Hogan <jhogan@kernel.org>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	Michal Hocko <mhocko@kernel.org>,
	Dave Hansen <dave.hansen@intel.com>,
	Paul Mackerras <paulus@samba.org>,
	sparclinux@vger.kernel.org,
	Dan Williams <dan.j.williams@intel.com>,
	linux-s390@vger.kernel.org, Jason Gunthorpe <jgg@ziepe.ca>,
	x86@kernel.org, Russell King - ARM Linux <linux@armlinux.org.uk>,
	Matthew Wilcox <willy@infradead.org>,
	Steven Price <Steven.Price@arm.com>,
	Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
	Vlastimil Babka <vbabka@suse.cz>,
	linux-snps-arc@lists.infradead.org,
	Kees Cook <keescook@chromium.org>,
	Mark Brown <broonie@kernel.org>,
	"Kirill A . Shutemov" <kirill@shutemov.name>,
	Thomas Gleixner <tglx@linutronix.de>,
	Gerald Schaefer <gerald.schaefer@de.ibm.com>,
	linux-arm-kernel@lists.infradead.org,
	Sri Krishna chowdary <schowdary@nvidia.com>,
	Masahiro Yamada <yamada.masahiro@socionext.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	linux-mips@vger.kernel.org, Ralf Baechle <ralf@linux-mips.org>,
	linux-kernel@vger.kernel.org, Paul Burton <paul.burton@mips.com>,
	Mike Rapoport <rppt@linux.vnet.ibm.com>,
	Vineet Gupta <vgupta@synopsys.com>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linuxppc-dev@lists.ozlabs.org,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH] mm/pgtable/debug: Fix test validating architecture page table helpers
Date: Fri, 13 Sep 2019 14:12:45 +0530	[thread overview]
Message-ID: <bdf7f152-d093-1691-4e96-77da7eb9e20a@arm.com> (raw)
In-Reply-To: <cb226b56-ff20-3136-7ffb-890657e56870@c-s.fr>



On 09/13/2019 12:41 PM, Christophe Leroy wrote:
> 
> 
> Le 13/09/2019 à 09:03, Christophe Leroy a écrit :
>>
>>
>> Le 13/09/2019 à 08:58, Anshuman Khandual a écrit :
>>> On 09/13/2019 11:53 AM, Christophe Leroy wrote:
>>>> Fix build failure on powerpc.
>>>>
>>>> Fix preemption imbalance.
>>>>
>>>> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
>>>> ---
>>>>   mm/arch_pgtable_test.c | 3 +++
>>>>   1 file changed, 3 insertions(+)
>>>>
>>>> diff --git a/mm/arch_pgtable_test.c b/mm/arch_pgtable_test.c
>>>> index 8b4a92756ad8..f2b3c9ec35fa 100644
>>>> --- a/mm/arch_pgtable_test.c
>>>> +++ b/mm/arch_pgtable_test.c
>>>> @@ -24,6 +24,7 @@
>>>>   #include <linux/swap.h>
>>>>   #include <linux/swapops.h>
>>>>   #include <linux/sched/mm.h>
>>>> +#include <linux/highmem.h>
>>>
>>> This is okay.
>>>
>>>>   #include <asm/pgalloc.h>
>>>>   #include <asm/pgtable.h>
>>>> @@ -400,6 +401,8 @@ static int __init arch_pgtable_tests_init(void)
>>>>       p4d_clear_tests(p4dp);
>>>>       pgd_clear_tests(mm, pgdp);
>>>> +    pte_unmap(ptep);
>>>> +
>>>
>>> Now the preemption imbalance via pte_alloc_map() path i.e
>>>
>>> pte_alloc_map() -> pte_offset_map() -> kmap_atomic()
>>>
>>> Is not this very much powerpc 32 specific or this will be applicable
>>> for all platform which uses kmap_XXX() to map high memory ?
>>>
>>
>> See https://elixir.bootlin.com/linux/v5.3-rc8/source/include/linux/highmem.h#L91
>>
>> I think it applies at least to all arches using the generic implementation.
>>
>> Applies also to arm:
>> https://elixir.bootlin.com/linux/v5.3-rc8/source/arch/arm/mm/highmem.c#L52
>>
>> Applies also to mips:
>> https://elixir.bootlin.com/linux/v5.3-rc8/source/arch/mips/mm/highmem.c#L47
>>
>> Same on sparc:
>> https://elixir.bootlin.com/linux/v5.3-rc8/source/arch/sparc/mm/highmem.c#L52
>>
>> Same on x86:
>> https://elixir.bootlin.com/linux/v5.3-rc8/source/arch/x86/mm/highmem_32.c#L34
>>
>> I have not checked others, but I guess it is like that for all.
>>
> 
> 
> Seems like I answered too quickly. All kmap_atomic() do preempt_disable(), but not all pte_alloc_map() call kmap_atomic().
> 
> However, for instance ARM does:
> 
> https://elixir.bootlin.com/linux/v5.3-rc8/source/arch/arm/include/asm/pgtable.h#L200
> 
> And X86 as well:
> 
> https://elixir.bootlin.com/linux/v5.3-rc8/source/arch/x86/include/asm/pgtable_32.h#L51
> 
> Microblaze also:
> 
> https://elixir.bootlin.com/linux/v5.3-rc8/source/arch/microblaze/include/asm/pgtable.h#L495

All the above platforms checks out to be using k[un]map_atomic(). I am wondering whether
any of the intermediate levels will have similar problems on any these 32 bit platforms
or any other platforms which might be using generic k[un]map_atomic(). There can be many
permutations here.

	p4dp = p4d_alloc(mm, pgdp, vaddr);
	pudp = pud_alloc(mm, p4dp, vaddr);
	pmdp = pmd_alloc(mm, pudp, vaddr);

Otherwise pte_alloc_map()/pte_unmap() looks good enough which will atleast take care of
a known failure.

WARNING: multiple messages have this Message-ID (diff)
From: Anshuman Khandual <anshuman.khandual@arm.com>
To: Christophe Leroy <christophe.leroy@c-s.fr>, linux-mm@kvack.org
Cc: Mark Rutland <mark.rutland@arm.com>,
	linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>,
	James Hogan <jhogan@kernel.org>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	Michal Hocko <mhocko@kernel.org>,
	Dave Hansen <dave.hansen@intel.com>,
	Paul Mackerras <paulus@samba.org>,
	sparclinux@vger.kernel.org, Thomas Gleixner <tglx@linutronix.de>,
	linux-s390@vger.kernel.org, Jason Gunthorpe <jgg@ziepe.ca>,
	x86@kernel.org, Russell King - ARM Linux <linux@armlinux.org.uk>,
	Matthew Wilcox <willy@infradead.org>,
	Steven Price <Steven.Price@arm.com>,
	Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
	Gerald Schaefer <gerald.schaefer@de.ibm.com>,
	linux-snps-arc@lists.infradead.org,
	Kees Cook <keescook@chromium.org>,
	Mark Brown <broonie@kernel.org>,
	"Kirill A . Shutemov" <kirill@shutemov.name>,
	Dan Williams <dan.j.williams@intel.com>,
	Vlastimil Babka <vbabka@suse.cz>,
	linux-arm-kernel@lists.infradead.org,
	Sri Krishna chowdary <schowdary@nvidia.com>,
	Masahiro Yamada <yamada.masahiro@socionext.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	linux-mips@vger.kernel.org, Ralf Baechle <ralf@linux-mips.org>,
	linux-kernel@vger.kernel.org, Paul Burton <paul.burton@mips.com>,
	Mike Rapoport <rppt@linux.vnet.ibm.com>,
	Vineet Gupta <vgupta@synopsys.com>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linuxppc-dev@lists.ozlabs.org,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH] mm/pgtable/debug: Fix test validating architecture page table helpers
Date: Fri, 13 Sep 2019 14:12:45 +0530	[thread overview]
Message-ID: <bdf7f152-d093-1691-4e96-77da7eb9e20a@arm.com> (raw)
In-Reply-To: <cb226b56-ff20-3136-7ffb-890657e56870@c-s.fr>



On 09/13/2019 12:41 PM, Christophe Leroy wrote:
> 
> 
> Le 13/09/2019 à 09:03, Christophe Leroy a écrit :
>>
>>
>> Le 13/09/2019 à 08:58, Anshuman Khandual a écrit :
>>> On 09/13/2019 11:53 AM, Christophe Leroy wrote:
>>>> Fix build failure on powerpc.
>>>>
>>>> Fix preemption imbalance.
>>>>
>>>> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
>>>> ---
>>>>   mm/arch_pgtable_test.c | 3 +++
>>>>   1 file changed, 3 insertions(+)
>>>>
>>>> diff --git a/mm/arch_pgtable_test.c b/mm/arch_pgtable_test.c
>>>> index 8b4a92756ad8..f2b3c9ec35fa 100644
>>>> --- a/mm/arch_pgtable_test.c
>>>> +++ b/mm/arch_pgtable_test.c
>>>> @@ -24,6 +24,7 @@
>>>>   #include <linux/swap.h>
>>>>   #include <linux/swapops.h>
>>>>   #include <linux/sched/mm.h>
>>>> +#include <linux/highmem.h>
>>>
>>> This is okay.
>>>
>>>>   #include <asm/pgalloc.h>
>>>>   #include <asm/pgtable.h>
>>>> @@ -400,6 +401,8 @@ static int __init arch_pgtable_tests_init(void)
>>>>       p4d_clear_tests(p4dp);
>>>>       pgd_clear_tests(mm, pgdp);
>>>> +    pte_unmap(ptep);
>>>> +
>>>
>>> Now the preemption imbalance via pte_alloc_map() path i.e
>>>
>>> pte_alloc_map() -> pte_offset_map() -> kmap_atomic()
>>>
>>> Is not this very much powerpc 32 specific or this will be applicable
>>> for all platform which uses kmap_XXX() to map high memory ?
>>>
>>
>> See https://elixir.bootlin.com/linux/v5.3-rc8/source/include/linux/highmem.h#L91
>>
>> I think it applies at least to all arches using the generic implementation.
>>
>> Applies also to arm:
>> https://elixir.bootlin.com/linux/v5.3-rc8/source/arch/arm/mm/highmem.c#L52
>>
>> Applies also to mips:
>> https://elixir.bootlin.com/linux/v5.3-rc8/source/arch/mips/mm/highmem.c#L47
>>
>> Same on sparc:
>> https://elixir.bootlin.com/linux/v5.3-rc8/source/arch/sparc/mm/highmem.c#L52
>>
>> Same on x86:
>> https://elixir.bootlin.com/linux/v5.3-rc8/source/arch/x86/mm/highmem_32.c#L34
>>
>> I have not checked others, but I guess it is like that for all.
>>
> 
> 
> Seems like I answered too quickly. All kmap_atomic() do preempt_disable(), but not all pte_alloc_map() call kmap_atomic().
> 
> However, for instance ARM does:
> 
> https://elixir.bootlin.com/linux/v5.3-rc8/source/arch/arm/include/asm/pgtable.h#L200
> 
> And X86 as well:
> 
> https://elixir.bootlin.com/linux/v5.3-rc8/source/arch/x86/include/asm/pgtable_32.h#L51
> 
> Microblaze also:
> 
> https://elixir.bootlin.com/linux/v5.3-rc8/source/arch/microblaze/include/asm/pgtable.h#L495

All the above platforms checks out to be using k[un]map_atomic(). I am wondering whether
any of the intermediate levels will have similar problems on any these 32 bit platforms
or any other platforms which might be using generic k[un]map_atomic(). There can be many
permutations here.

	p4dp = p4d_alloc(mm, pgdp, vaddr);
	pudp = pud_alloc(mm, p4dp, vaddr);
	pmdp = pmd_alloc(mm, pudp, vaddr);

Otherwise pte_alloc_map()/pte_unmap() looks good enough which will atleast take care of
a known failure.

WARNING: multiple messages have this Message-ID (diff)
From: anshuman.khandual@arm.com (Anshuman Khandual)
To: linux-snps-arc@lists.infradead.org
Subject: [PATCH] mm/pgtable/debug: Fix test validating architecture page table helpers
Date: Fri, 13 Sep 2019 14:12:45 +0530	[thread overview]
Message-ID: <bdf7f152-d093-1691-4e96-77da7eb9e20a@arm.com> (raw)
In-Reply-To: <cb226b56-ff20-3136-7ffb-890657e56870@c-s.fr>



On 09/13/2019 12:41 PM, Christophe Leroy wrote:
> 
> 
> Le 13/09/2019 ? 09:03, Christophe Leroy a ?crit?:
>>
>>
>> Le 13/09/2019 ? 08:58, Anshuman Khandual a ?crit?:
>>> On 09/13/2019 11:53 AM, Christophe Leroy wrote:
>>>> Fix build failure on powerpc.
>>>>
>>>> Fix preemption imbalance.
>>>>
>>>> Signed-off-by: Christophe Leroy <christophe.leroy at c-s.fr>
>>>> ---
>>>> ? mm/arch_pgtable_test.c | 3 +++
>>>> ? 1 file changed, 3 insertions(+)
>>>>
>>>> diff --git a/mm/arch_pgtable_test.c b/mm/arch_pgtable_test.c
>>>> index 8b4a92756ad8..f2b3c9ec35fa 100644
>>>> --- a/mm/arch_pgtable_test.c
>>>> +++ b/mm/arch_pgtable_test.c
>>>> @@ -24,6 +24,7 @@
>>>> ? #include <linux/swap.h>
>>>> ? #include <linux/swapops.h>
>>>> ? #include <linux/sched/mm.h>
>>>> +#include <linux/highmem.h>
>>>
>>> This is okay.
>>>
>>>> ? #include <asm/pgalloc.h>
>>>> ? #include <asm/pgtable.h>
>>>> @@ -400,6 +401,8 @@ static int __init arch_pgtable_tests_init(void)
>>>> ????? p4d_clear_tests(p4dp);
>>>> ????? pgd_clear_tests(mm, pgdp);
>>>> +??? pte_unmap(ptep);
>>>> +
>>>
>>> Now the preemption imbalance via pte_alloc_map() path i.e
>>>
>>> pte_alloc_map() -> pte_offset_map() -> kmap_atomic()
>>>
>>> Is not this very much powerpc 32 specific or this will be applicable
>>> for all platform which uses kmap_XXX() to map high memory ?
>>>
>>
>> See https://elixir.bootlin.com/linux/v5.3-rc8/source/include/linux/highmem.h#L91
>>
>> I think it applies at least to all arches using the generic implementation.
>>
>> Applies also to arm:
>> https://elixir.bootlin.com/linux/v5.3-rc8/source/arch/arm/mm/highmem.c#L52
>>
>> Applies also to mips:
>> https://elixir.bootlin.com/linux/v5.3-rc8/source/arch/mips/mm/highmem.c#L47
>>
>> Same on sparc:
>> https://elixir.bootlin.com/linux/v5.3-rc8/source/arch/sparc/mm/highmem.c#L52
>>
>> Same on x86:
>> https://elixir.bootlin.com/linux/v5.3-rc8/source/arch/x86/mm/highmem_32.c#L34
>>
>> I have not checked others, but I guess it is like that for all.
>>
> 
> 
> Seems like I answered too quickly. All kmap_atomic() do preempt_disable(), but not all pte_alloc_map() call kmap_atomic().
> 
> However, for instance ARM does:
> 
> https://elixir.bootlin.com/linux/v5.3-rc8/source/arch/arm/include/asm/pgtable.h#L200
> 
> And X86 as well:
> 
> https://elixir.bootlin.com/linux/v5.3-rc8/source/arch/x86/include/asm/pgtable_32.h#L51
> 
> Microblaze also:
> 
> https://elixir.bootlin.com/linux/v5.3-rc8/source/arch/microblaze/include/asm/pgtable.h#L495

All the above platforms checks out to be using k[un]map_atomic(). I am wondering whether
any of the intermediate levels will have similar problems on any these 32 bit platforms
or any other platforms which might be using generic k[un]map_atomic(). There can be many
permutations here.

	p4dp = p4d_alloc(mm, pgdp, vaddr);
	pudp = pud_alloc(mm, p4dp, vaddr);
	pmdp = pmd_alloc(mm, pudp, vaddr);

Otherwise pte_alloc_map()/pte_unmap() looks good enough which will atleast take care of
a known failure.

WARNING: multiple messages have this Message-ID (diff)
From: Anshuman Khandual <anshuman.khandual@arm.com>
To: Christophe Leroy <christophe.leroy@c-s.fr>, linux-mm@kvack.org
Cc: Mark Rutland <mark.rutland@arm.com>,
	linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>,
	James Hogan <jhogan@kernel.org>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	Michal Hocko <mhocko@kernel.org>,
	Dave Hansen <dave.hansen@intel.com>,
	Paul Mackerras <paulus@samba.org>,
	sparclinux@vger.kernel.org, Thomas Gleixner <tglx@linutronix.de>,
	linux-s390@vger.kernel.org, Jason Gunthorpe <jgg@ziepe.ca>,
	x86@kernel.org, Russell King - ARM Linux <linux@armlinux.org.uk>,
	Matthew Wilcox <willy@infradead.org>,
	Steven Price <Steven.Price@arm.com>,
	Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
	Gerald Schaefer <gerald.schaefer@de.ibm.com>,
	linux-snps-arc@lists.infradead.org,
	Kees Cook <keescook@chromium.org>,
	Mark Brown <broonie@kernel.org>,
	"Kirill A . Shutemov" <kirill@shutemov.name>,
	Dan Williams <dan.j.williams@intel.com>,
	Vlastimil Babka <vbabka@suse.cz>,
	linux-arm-kernel@lists.infradead.org,
	Sri Krishna chowdary <schowdary@nvidia.com>,
	Masahiro Yamada <yamada.masahiro@socionext.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	linux-mips@vger.kernel.org, Ralf Baechle <ralf@linux-mips.org>,
	linux-kernel@vger.kernel.org, Paul Burton <paul.burton@mips.com>,
	Mike Rapoport <rppt@linux.vnet.ibm.com>,
	Vineet Gupta <vgupta@synopsys.com>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linuxppc-dev@lists.ozlabs.org,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH] mm/pgtable/debug: Fix test validating architecture page table helpers
Date: Fri, 13 Sep 2019 14:12:45 +0530	[thread overview]
Message-ID: <bdf7f152-d093-1691-4e96-77da7eb9e20a@arm.com> (raw)
In-Reply-To: <cb226b56-ff20-3136-7ffb-890657e56870@c-s.fr>



On 09/13/2019 12:41 PM, Christophe Leroy wrote:
> 
> 
> Le 13/09/2019 à 09:03, Christophe Leroy a écrit :
>>
>>
>> Le 13/09/2019 à 08:58, Anshuman Khandual a écrit :
>>> On 09/13/2019 11:53 AM, Christophe Leroy wrote:
>>>> Fix build failure on powerpc.
>>>>
>>>> Fix preemption imbalance.
>>>>
>>>> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
>>>> ---
>>>>   mm/arch_pgtable_test.c | 3 +++
>>>>   1 file changed, 3 insertions(+)
>>>>
>>>> diff --git a/mm/arch_pgtable_test.c b/mm/arch_pgtable_test.c
>>>> index 8b4a92756ad8..f2b3c9ec35fa 100644
>>>> --- a/mm/arch_pgtable_test.c
>>>> +++ b/mm/arch_pgtable_test.c
>>>> @@ -24,6 +24,7 @@
>>>>   #include <linux/swap.h>
>>>>   #include <linux/swapops.h>
>>>>   #include <linux/sched/mm.h>
>>>> +#include <linux/highmem.h>
>>>
>>> This is okay.
>>>
>>>>   #include <asm/pgalloc.h>
>>>>   #include <asm/pgtable.h>
>>>> @@ -400,6 +401,8 @@ static int __init arch_pgtable_tests_init(void)
>>>>       p4d_clear_tests(p4dp);
>>>>       pgd_clear_tests(mm, pgdp);
>>>> +    pte_unmap(ptep);
>>>> +
>>>
>>> Now the preemption imbalance via pte_alloc_map() path i.e
>>>
>>> pte_alloc_map() -> pte_offset_map() -> kmap_atomic()
>>>
>>> Is not this very much powerpc 32 specific or this will be applicable
>>> for all platform which uses kmap_XXX() to map high memory ?
>>>
>>
>> See https://elixir.bootlin.com/linux/v5.3-rc8/source/include/linux/highmem.h#L91
>>
>> I think it applies at least to all arches using the generic implementation.
>>
>> Applies also to arm:
>> https://elixir.bootlin.com/linux/v5.3-rc8/source/arch/arm/mm/highmem.c#L52
>>
>> Applies also to mips:
>> https://elixir.bootlin.com/linux/v5.3-rc8/source/arch/mips/mm/highmem.c#L47
>>
>> Same on sparc:
>> https://elixir.bootlin.com/linux/v5.3-rc8/source/arch/sparc/mm/highmem.c#L52
>>
>> Same on x86:
>> https://elixir.bootlin.com/linux/v5.3-rc8/source/arch/x86/mm/highmem_32.c#L34
>>
>> I have not checked others, but I guess it is like that for all.
>>
> 
> 
> Seems like I answered too quickly. All kmap_atomic() do preempt_disable(), but not all pte_alloc_map() call kmap_atomic().
> 
> However, for instance ARM does:
> 
> https://elixir.bootlin.com/linux/v5.3-rc8/source/arch/arm/include/asm/pgtable.h#L200
> 
> And X86 as well:
> 
> https://elixir.bootlin.com/linux/v5.3-rc8/source/arch/x86/include/asm/pgtable_32.h#L51
> 
> Microblaze also:
> 
> https://elixir.bootlin.com/linux/v5.3-rc8/source/arch/microblaze/include/asm/pgtable.h#L495

All the above platforms checks out to be using k[un]map_atomic(). I am wondering whether
any of the intermediate levels will have similar problems on any these 32 bit platforms
or any other platforms which might be using generic k[un]map_atomic(). There can be many
permutations here.

	p4dp = p4d_alloc(mm, pgdp, vaddr);
	pudp = pud_alloc(mm, p4dp, vaddr);
	pmdp = pmd_alloc(mm, pudp, vaddr);

Otherwise pte_alloc_map()/pte_unmap() looks good enough which will atleast take care of
a known failure.

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

  reply	other threads:[~2019-09-13  8:54 UTC|newest]

Thread overview: 151+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-12  6:02 [PATCH V2 0/2] mm/debug: Add tests for architecture exported page table helpers Anshuman Khandual
2019-09-12  6:14 ` Anshuman Khandual
2019-09-12  6:02 ` Anshuman Khandual
2019-09-12  6:02 ` Anshuman Khandual
2019-09-12  6:02 ` Anshuman Khandual
2019-09-12  6:02 ` [PATCH V2 1/2] mm/hugetlb: Make alloc_gigantic_page() available for general use Anshuman Khandual
2019-09-12  6:02 ` [PATCH V2 2/2] mm/pgtable/debug: Add test validating architecture page table helpers Anshuman Khandual
2019-09-12  6:14   ` Anshuman Khandual
2019-09-12  6:02   ` Anshuman Khandual
2019-09-12  6:02   ` Anshuman Khandual
2019-09-12  6:02   ` Anshuman Khandual
2019-09-12 11:00   ` Kirill A. Shutemov
2019-09-12 11:00     ` Kirill A. Shutemov
2019-09-12 11:00     ` Kirill A. Shutemov
2019-09-12 11:00     ` Kirill A. Shutemov
2019-09-12 11:00     ` Kirill A. Shutemov
2019-09-12 12:09     ` Anshuman Khandual
2019-09-12 12:21       ` Anshuman Khandual
2019-09-12 12:09       ` Anshuman Khandual
2019-09-12 12:09       ` Anshuman Khandual
2019-09-12 12:09       ` Anshuman Khandual
2019-09-12 15:00   ` Christophe Leroy
2019-09-12 15:00     ` Christophe Leroy
2019-09-12 15:00     ` Christophe Leroy
2019-09-12 15:00     ` Christophe Leroy
2019-09-12 15:00     ` Christophe Leroy
2019-09-12 15:36     ` Christophe Leroy
2019-09-12 15:36       ` Christophe Leroy
2019-09-12 15:36       ` Christophe Leroy
2019-09-12 15:36       ` Christophe Leroy
2019-09-12 15:36       ` Christophe Leroy
2019-09-12 15:52       ` Christophe Leroy
2019-09-12 15:52         ` Christophe Leroy
2019-09-12 15:52         ` Christophe Leroy
2019-09-12 15:52         ` Christophe Leroy
2019-09-12 15:52         ` Christophe Leroy
2019-09-13  6:30         ` Christophe Leroy
2019-09-13  6:30           ` Christophe Leroy
2019-09-13  6:30           ` Christophe Leroy
2019-09-13  6:30           ` Christophe Leroy
2019-09-13  6:30           ` Christophe Leroy
2019-09-12 17:14   ` Christophe Leroy
2019-09-12 17:14     ` Christophe Leroy
2019-09-12 17:14     ` Christophe Leroy
2019-09-12 17:14     ` Christophe Leroy
2019-09-12 17:14     ` Christophe Leroy
2019-09-13  6:23     ` [PATCH] mm/pgtable/debug: Fix " Christophe Leroy
2019-09-13  6:23       ` Christophe Leroy
2019-09-13  6:23       ` Christophe Leroy
2019-09-13  6:23       ` Christophe Leroy
2019-09-13  6:23       ` Christophe Leroy
2019-09-13  6:58       ` Anshuman Khandual
2019-09-13  6:58         ` Anshuman Khandual
2019-09-13  6:58         ` Anshuman Khandual
2019-09-13  6:58         ` Anshuman Khandual
2019-09-13  6:58         ` Anshuman Khandual
2019-09-13  6:58         ` Anshuman Khandual
2019-09-13  7:03         ` Christophe Leroy
2019-09-13  7:03           ` Christophe Leroy
2019-09-13  7:03           ` Christophe Leroy
2019-09-13  7:03           ` Christophe Leroy
2019-09-13  7:03           ` Christophe Leroy
2019-09-13  7:11           ` Christophe Leroy
2019-09-13  7:11             ` Christophe Leroy
2019-09-13  7:11             ` Christophe Leroy
2019-09-13  7:11             ` Christophe Leroy
2019-09-13  7:11             ` Christophe Leroy
2019-09-13  8:42             ` Anshuman Khandual [this message]
2019-09-13  8:54               ` Anshuman Khandual
2019-09-13  8:42               ` Anshuman Khandual
2019-09-13  8:42               ` Anshuman Khandual
2019-09-13  8:42               ` Anshuman Khandual
2019-09-13  8:51               ` Kirill A. Shutemov
2019-09-13  8:51                 ` Kirill A. Shutemov
2019-09-13  8:51                 ` Kirill A. Shutemov
2019-09-13  8:51                 ` Kirill A. Shutemov
2019-09-13  8:51                 ` Kirill A. Shutemov
2019-09-13  8:51                 ` Kirill A. Shutemov
2019-09-18  7:32       ` Anshuman Khandual
2019-09-18  7:44         ` Anshuman Khandual
2019-09-18  7:32         ` Anshuman Khandual
2019-09-18  7:32         ` Anshuman Khandual
2019-09-18  7:32         ` Anshuman Khandual
2019-09-19  5:44         ` Christophe Leroy
2019-09-19  5:44           ` Christophe Leroy
2019-09-19  5:44           ` Christophe Leroy
2019-09-19  5:44           ` Christophe Leroy
2019-09-19  5:44           ` Christophe Leroy
2019-09-13  9:02     ` [PATCH V2 2/2] mm/pgtable/debug: Add " Anshuman Khandual
2019-09-13  9:14       ` Anshuman Khandual
2019-09-13  9:02       ` Anshuman Khandual
2019-09-13  9:02       ` Anshuman Khandual
2019-09-13  9:02       ` Anshuman Khandual
2019-09-13  9:13       ` Kirill A. Shutemov
2019-09-13  9:13         ` Kirill A. Shutemov
2019-09-13  9:13         ` Kirill A. Shutemov
2019-09-13  9:13         ` Kirill A. Shutemov
2019-09-13  9:13         ` Kirill A. Shutemov
2019-09-13  9:13         ` Kirill A. Shutemov
2019-09-13 10:01       ` Christophe Leroy
2019-09-13 10:01         ` Christophe Leroy
2019-09-13 10:01         ` Christophe Leroy
2019-09-13 10:01         ` Christophe Leroy
2019-09-13 10:01         ` Christophe Leroy
2019-09-18  5:04         ` Anshuman Khandual
2019-09-18  5:16           ` Anshuman Khandual
2019-09-18  5:04           ` Anshuman Khandual
2019-09-18  5:04           ` Anshuman Khandual
2019-09-18  5:04           ` Anshuman Khandual
2019-09-18 16:26           ` Christophe Leroy
2019-09-18 16:26             ` Christophe Leroy
2019-09-18 16:26             ` Christophe Leroy
2019-09-18 16:26             ` Christophe Leroy
2019-09-18 16:26             ` Christophe Leroy
2019-09-18 18:22             ` Gerald Schaefer
2019-09-18 18:22               ` Gerald Schaefer
2019-09-18 18:22               ` Gerald Schaefer
2019-09-18 18:22               ` Gerald Schaefer
2019-09-18 18:22               ` Gerald Schaefer
2019-09-20  4:06               ` Anshuman Khandual
2019-09-20  4:18                 ` Anshuman Khandual
2019-09-20  4:06                 ` Anshuman Khandual
2019-09-20  4:06                 ` Anshuman Khandual
2019-09-20  4:06                 ` Anshuman Khandual
2019-09-19  4:56             ` Anshuman Khandual
2019-09-19  4:56               ` Anshuman Khandual
2019-09-19  4:56               ` Anshuman Khandual
2019-09-19  4:56               ` Anshuman Khandual
2019-09-19  4:56               ` Anshuman Khandual
2019-09-19  4:56               ` Anshuman Khandual
2019-09-19  4:56               ` Anshuman Khandual
2019-09-19  5:41               ` Christophe Leroy
2019-09-19  5:41                 ` Christophe Leroy
2019-09-19  5:41                 ` Christophe Leroy
2019-09-19  5:41                 ` Christophe Leroy
2019-09-19  5:41                 ` Christophe Leroy
2019-09-12 14:42 ` [PATCH V2 0/2] mm/debug: Add tests for architecture exported " Christophe Leroy
2019-09-12 14:42   ` Christophe Leroy
2019-09-12 14:42   ` Christophe Leroy
2019-09-12 14:42   ` Christophe Leroy
2019-09-12 14:42   ` Christophe Leroy
2019-09-13  6:24   ` Anshuman Khandual
2019-09-13  6:36     ` Anshuman Khandual
2019-09-13  6:24     ` Anshuman Khandual
2019-09-13  6:24     ` Anshuman Khandual
2019-09-13  6:24     ` Anshuman Khandual
2019-09-13  6:32     ` Christophe Leroy
2019-09-13  6:32       ` Christophe Leroy
2019-09-13  6:32       ` Christophe Leroy
2019-09-13  6:32       ` Christophe Leroy
2019-09-13  6:32       ` Christophe Leroy

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=bdf7f152-d093-1691-4e96-77da7eb9e20a@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=christophe.leroy@c-s.fr \
    --cc=dan.j.williams@intel.com \
    --cc=dave.hansen@intel.com \
    --cc=davem@davemloft.net \
    --cc=gerald.schaefer@de.ibm.com \
    --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=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 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.