This allows unsupported levels to be constant folded away, and so
p4d_free_pud_page can be removed because it's no longer linked to.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: x...@kernel.org
Cc: "H. Peter Anvin"
Signed-off-by: Nicholas Piggin
---
From: "Desnes A. Nunes do Rosario"
[ Upstream commit 3337bf41e0dd70b4064cdf60acdfcdc2d050066c ]
An extra count on ebb_state.stats.pmc_count[PMC_INDEX(pmc)] is being per-
formed when count_pmc() is used to reset PMCs on a few selftests. This
extra pmc_count can occasionally invalidate results,
From: "Desnes A. Nunes do Rosario"
[ Upstream commit 3337bf41e0dd70b4064cdf60acdfcdc2d050066c ]
An extra count on ebb_state.stats.pmc_count[PMC_INDEX(pmc)] is being per-
formed when count_pmc() is used to reset PMCs on a few selftests. This
extra pmc_count can occasionally invalidate results,
This will be used as a generic kernel virtual mapping function, so
re-name it in preparation.
Signed-off-by: Nicholas Piggin
---
mm/ioremap.c | 64 +++-
1 file changed, 33 insertions(+), 31 deletions(-)
diff --git a/mm/ioremap.c b/mm/ioremap.c
This allows unsupported levels to be constant folded away, and so
p4d_free_pud_page can be removed because it's no longer linked to.
Cc: Catalin Marinas
Cc: Will Deacon
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Nicholas Piggin
---
arch/arm64/include/asm/vmalloc.h | 23
Hello,
Il giorno ven, 21/08/2020 alle 16.03 +0200, Christophe Leroy ha
scritto:
[...]
> Thanks.
>
> The Oops in the video shows that the issue is at 0x1bcac and msr
> value
> shows that Instruction MMU is disabled. So this corresponds to
> address
> 0xc001bcac. In the vmlinux you sent me this
From: Alexey Kardashevskiy
[ Upstream commit f0993c839e95dd6c7f054a1015e693c87e33e4fb ]
xive_native_provision_pages() allocates memory and passes the pointer to
OPAL so kmemleak cannot find the pointer usage in the kernel memory and
produces a false positive report (below) (even if the kernel
The vmalloc mapper operates on a struct page * array rather than a
linear physical address, re-name it to make this distinction clear.
Signed-off-by: Nicholas Piggin
---
mm/vmalloc.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
This changes the awkward approach where architectures provide init
functions to determine which levels they can provide large mappings for,
to one where the arch is queried for each call.
This removes code and indirection, and allows constant-folding of dead
code for unsupported levels.
This
From: Alexey Kardashevskiy
[ Upstream commit f0993c839e95dd6c7f054a1015e693c87e33e4fb ]
xive_native_provision_pages() allocates memory and passes the pointer to
OPAL so kmemleak cannot find the pointer usage in the kernel memory and
produces a false positive report (below) (even if the kernel
From: Alexey Kardashevskiy
[ Upstream commit f0993c839e95dd6c7f054a1015e693c87e33e4fb ]
xive_native_provision_pages() allocates memory and passes the pointer to
OPAL so kmemleak cannot find the pointer usage in the kernel memory and
produces a false positive report (below) (even if the kernel
From: "Desnes A. Nunes do Rosario"
[ Upstream commit 3337bf41e0dd70b4064cdf60acdfcdc2d050066c ]
An extra count on ebb_state.stats.pmc_count[PMC_INDEX(pmc)] is being per-
formed when count_pmc() is used to reset PMCs on a few selftests. This
extra pmc_count can occasionally invalidate results,
From: "Desnes A. Nunes do Rosario"
[ Upstream commit 3337bf41e0dd70b4064cdf60acdfcdc2d050066c ]
An extra count on ebb_state.stats.pmc_count[PMC_INDEX(pmc)] is being per-
formed when count_pmc() is used to reset PMCs on a few selftests. This
extra pmc_count can occasionally invalidate results,
On 8/21/20 8:12 AM, Nicholas Piggin wrote:
> Support huge page vmalloc mappings. Config option HAVE_ARCH_HUGE_VMALLOC
> enables support on architectures that define HAVE_ARCH_HUGE_VMAP and
> supports PMD sized vmap mappings.
>
> vmalloc will attempt to allocate PMD-sized pages if allocating PMD
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Nicholas Piggin
---
Documentation/admin-guide/kernel-parameters.txt | 2 ++
arch/powerpc/Kconfig| 1 +
2 files changed, 3 insertions(+)
diff --git a/Documentation/admin-guide/kernel-parameters.txt
Excerpts from Eric Dumazet's message of August 22, 2020 1:38 am:
>
> On 8/21/20 8:12 AM, Nicholas Piggin wrote:
>> Support huge page vmalloc mappings. Config option HAVE_ARCH_HUGE_VMALLOC
>> enables support on architectures that define HAVE_ARCH_HUGE_VMAP and
>> supports PMD sized vmap mappings.
From: Alexey Kardashevskiy
[ Upstream commit f0993c839e95dd6c7f054a1015e693c87e33e4fb ]
xive_native_provision_pages() allocates memory and passes the pointer to
OPAL so kmemleak cannot find the pointer usage in the kernel memory and
produces a false positive report (below) (even if the kernel
It's possible to enable CONFIG_PPC_EARLY_DEBUG_BOOTX for a pseries
kernel (maybe it shouldn't be), which is then booted with qemu/slof.
But if you do that the kernel crashes in draw_byte(), with a DAR
pointing somewhere near INT_MAX.
Adding some debug to prom_init we see that we're not able to
Excerpts from Christophe Leroy's message of August 21, 2020 3:47 pm:
>
>
> Le 21/08/2020 à 06:44, Nicholas Piggin a écrit :
>> I made this powerpc-only for the time being. It shouldn't be too hard to
>> add support for other archs that define HUGE_VMAP. I have booted x86
>> with it enabled, just
Thanks Christophe and Christoph for reviews.
Thanks,
Nick
Since v5:
- Split arch changes out better and make the constant folding work
- Avoid most of the 80 column wrap, fix a reference to lib/ioremap.c
- Fix compile error on some archs
Since v4:
- Fixed an off-by-page-order bug in v4
-
Currently this might mistake a large pte for bad, or treat it as a
page table, resulting in a crash or corruption.
Signed-off-by: Nicholas Piggin
---
mm/memory.c | 60 +++--
1 file changed, 44 insertions(+), 16 deletions(-)
diff --git
This allows unsupported levels to be constant folded away, and so
p4d_free_pud_page can be removed because it's no longer linked to.
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Nicholas Piggin
---
arch/powerpc/include/asm/vmalloc.h | 19 ---
Support huge page vmalloc mappings. Config option HAVE_ARCH_HUGE_VMALLOC
enables support on architectures that define HAVE_ARCH_HUGE_VMAP and
supports PMD sized vmap mappings.
vmalloc will attempt to allocate PMD-sized pages if allocating PMD size or
larger, and fall back to small pages if that
As a side-effect, the order of flush_cache_vmap() and
arch_sync_kernel_mappings() calls are switched, but that now matches
the other callers in this file.
Signed-off-by: Nicholas Piggin
---
mm/vmalloc.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git
From: "Desnes A. Nunes do Rosario"
[ Upstream commit 3337bf41e0dd70b4064cdf60acdfcdc2d050066c ]
An extra count on ebb_state.stats.pmc_count[PMC_INDEX(pmc)] is being per-
formed when count_pmc() is used to reset PMCs on a few selftests. This
extra pmc_count can occasionally invalidate results,
This is a generic kernel virtual memory mapper, not specific to ioremap.
Signed-off-by: Nicholas Piggin
---
include/linux/vmalloc.h | 3 +
mm/ioremap.c| 197
mm/vmalloc.c| 196 +++
3 files
From: Alexey Kardashevskiy
[ Upstream commit f0993c839e95dd6c7f054a1015e693c87e33e4fb ]
xive_native_provision_pages() allocates memory and passes the pointer to
OPAL so kmemleak cannot find the pointer usage in the kernel memory and
produces a false positive report (below) (even if the kernel
From: "Desnes A. Nunes do Rosario"
[ Upstream commit 3337bf41e0dd70b4064cdf60acdfcdc2d050066c ]
An extra count on ebb_state.stats.pmc_count[PMC_INDEX(pmc)] is being per-
formed when count_pmc() is used to reset PMCs on a few selftests. This
extra pmc_count can occasionally invalidate results,
vmalloc_to_page returns NULL for addresses mapped by larger pages[*].
Whether or not a vmap is huge depends on the architecture details,
alignments, boot options, etc., which the caller can not be expected
to know. Therefore HUGE_VMAP is a regression for vmalloc_to_page.
This change teaches
From: "Desnes A. Nunes do Rosario"
[ Upstream commit 3337bf41e0dd70b4064cdf60acdfcdc2d050066c ]
An extra count on ebb_state.stats.pmc_count[PMC_INDEX(pmc)] is being per-
formed when count_pmc() is used to reset PMCs on a few selftests. This
extra pmc_count can occasionally invalidate results,
On Aug 21 2020, Christophe Leroy wrote:
> In is_module_segment(), when VMALLOC_END is over 0xf000,
> ALIGN(VMALLOC_END, SZ_256M) has value 0.
>
> In that case, addr >= ALIGN(VMALLOC_END, SZ_256M) is always
> true then is_module_segment() always returns false.
>
> Use (ALIGN(VMALLOC_END,
Excerpts from Christophe Leroy's message of August 21, 2020 3:40 pm:
>
>
> Le 21/08/2020 à 06:44, Nicholas Piggin a écrit :
>> This changes the awkward approach where architectures provide init
>> functions to determine which levels they can provide large mappings for,
>> to one where the arch
The build is currently broken, if COMPILE_TEST=y and PPC_PMAC=n:
linux/drivers/video/fbdev/controlfb.c: In function ‘control_set_hardware’:
linux/drivers/video/fbdev/controlfb.c:276:2: error: implicit declaration of
function ‘btext_update_display’
276 |
Hi again,
Le 21/08/2020 à 10:22, Giuseppe Sacco a écrit :
Hello Cristophe,
Il giorno ven, 21/08/2020 alle 08.55 +0200, Christophe Leroy ha
scritto:
Hi Giuseppe,
Le 08/07/2020 à 20:44, Christophe Leroy a écrit :
Le 08/07/2020 à 19:36, Giuseppe Sacco a écrit :
Hi Cristophe,
Il giorno mer,
On 8/21/20 12:49 PM, Michael Ellerman wrote:
> The build is currently broken, if COMPILE_TEST=y and PPC_PMAC=n:
>
> linux/drivers/video/fbdev/controlfb.c: In function ‘control_set_hardware’:
> linux/drivers/video/fbdev/controlfb.c:276:2: error: implicit declaration of
> function
Le 21/08/2020 à 12:39, Nicholas Piggin a écrit :
Excerpts from Christophe Leroy's message of August 21, 2020 3:40 pm:
Le 21/08/2020 à 06:44, Nicholas Piggin a écrit :
This changes the awkward approach where architectures provide init
functions to determine which levels they can provide
Hello Cristophe,
Il giorno ven, 21/08/2020 alle 08.55 +0200, Christophe Leroy ha
scritto:
> Hi Giuseppe,
>
> Le 08/07/2020 à 20:44, Christophe Leroy a écrit :
> >
> > Le 08/07/2020 à 19:36, Giuseppe Sacco a écrit :
> > > Hi Cristophe,
> > >
> > > Il giorno mer, 08/07/2020 alle 19.09 +0200,
Excerpts from Shawn Anastasio's message of August 21, 2020 11:08 am:
> Since migration of guests using SAO to ISA 3.1 hosts may cause issues,
> disable PROT_SAO in LPARs by default and introduce a new Kconfig option
> PPC_PROT_SAO_LPAR to allow users to enable it if desired.
I think this should
Le 21/08/2020 à 15:50, Giuseppe Sacco a écrit :
Il giorno ven, 21/08/2020 alle 15.29 +0200, Christophe Leroy ha
scritto:
[...]
Maybe the easiest would be first to locate this issue. Can you send me
the vmlinux and the .config matching the Oops in the video ?
And also the output of git
Hi Nicholas,
I love your patch! Yet something to improve:
[auto build test ERROR on powerpc/next]
[also build test ERROR on linus/master v5.9-rc1 next-20200821]
[cannot apply to hnaz-linux-mm/master]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting
Excerpts from Andrew Morton's message of August 22, 2020 6:14 am:
> On Sat, 22 Aug 2020 01:12:09 +1000 Nicholas Piggin wrote:
>
>> This changes the awkward approach where architectures provide init
>> functions to determine which levels they can provide large mappings for,
>> to one where the
On Sat, 22 Aug 2020 01:12:10 +1000 Nicholas Piggin wrote:
> #ifdef CONFIG_HAVE_ARCH_HUGE_VMAP
> -bool arch_vmap_p4d_supported(pgprot_t prot);
> -bool arch_vmap_pud_supported(pgprot_t prot);
> -bool arch_vmap_pmd_supported(pgprot_t prot);
> +static inline bool arch_vmap_p4d_supported(pgprot_t
On 8/20/20 4:46 PM, Tyrel Datwyler wrote:
> The code currently NULLs tty->driver_data in hvcs_close() with the
> intent of informing the next call to hvcs_open() that device needs to be
> reconfigured. However, when hvcs_cleanup() is called we copy hvcsd from
> tty->driver_data which was
Excerpts from Andrew Morton's message of August 22, 2020 6:07 am:
> On Sat, 22 Aug 2020 01:12:05 +1000 Nicholas Piggin wrote:
>
>> vmalloc_to_page returns NULL for addresses mapped by larger pages[*].
>> Whether or not a vmap is huge depends on the architecture details,
>> alignments, boot
On Sat, 22 Aug 2020 01:12:09 +1000 Nicholas Piggin wrote:
> This changes the awkward approach where architectures provide init
> functions to determine which levels they can provide large mappings for,
> to one where the arch is queried for each call.
>
> This removes code and indirection, and
This reverts commit 5c9fa16e8abd342ce04dc830c1ebb2a03abf6c05.
Since PROT_SAO can still be useful for certain classes of software,
reintroduce it. Concerns about guest migration for LPARs using SAO
will be addressed next.
Signed-off-by: Shawn Anastasio
---
On Sat, 22 Aug 2020 01:12:05 +1000 Nicholas Piggin wrote:
> vmalloc_to_page returns NULL for addresses mapped by larger pages[*].
> Whether or not a vmap is huge depends on the architecture details,
> alignments, boot options, etc., which the caller can not be expected
> to know. Therefore
Since migration of guests using SAO to ISA 3.1 hosts may cause issues,
disable PROT_SAO in LPARs by default and introduce a new Kconfig option
PPC_PROT_SAO_LPAR to allow users to enable it if desired.
Signed-off-by: Shawn Anastasio
---
arch/powerpc/Kconfig| 12
Since SAO support was removed from ISA 3.1, skip the
prot_sao test if PPC_FEATURE2_ARCH_3_1 is set.
Signed-off-by: Shawn Anastasio
---
tools/testing/selftests/powerpc/mm/prot_sao.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git
Changes in v2:
- Update prot_sao selftest to skip ISA 3.1
This set re-introduces the PROT_SAO prot flag removed in
Commit 5c9fa16e8abd ("powerpc/64s: Remove PROT_SAO support").
To address concerns regarding live migration of guests using SAO
to P10 hosts without SAO support, the flag is
On 8/21/20 5:37 AM, Nicholas Piggin wrote:> I think this should be okay.
Could you also update the selftest to skip
if we have PPC_FEATURE2_ARCH_3_1 set?
Sure. I'll send out a v2 shortly with another patch for this.
Thanks,
Nick
Thanks,
Shawn
Implement pcibios_default_alignment for pseries so that
resources are page-aligned. The main benefit of this is being
able to map any resource from userspace via mechanisms like VFIO.
This is identical to powernv's implementation.
Signed-off-by: Shawn Anastasio
---
On 08/21/2020 12:44 PM, Aneesh Kumar K.V wrote:
> On 8/20/20 8:02 PM, Christophe Leroy wrote:
>>
>>
>> Le 19/08/2020 à 15:01, Aneesh Kumar K.V a écrit :
>>> set_pte_at() should not be used to set a pte entry at locations that
>>> already holds a valid pte entry. Architectures like ppc64 don't
Le 11/08/2020 à 03:51, Scott Cheloha a écrit :
At memory hot-remove time we can retrieve an LMB's nid from its
corresponding memory_block. There is no need to store the nid
in multiple locations.
Note that lmb_to_memblock() uses find_memory_block() to get the
corresponding memory_block. As
On 08/19/2020 06:30 PM, Aneesh Kumar K.V wrote:
> ppc64 supports huge vmap only with radix translation. Hence use arch helper
> to determine the huge vmap support.
>
> Signed-off-by: Aneesh Kumar K.V
> ---
> include/linux/io.h| 12
> mm/debug_vm_pgtable.c | 4 ++--
> 2
Sure. I am hoping kernel test robot will pick this up. I did an x86 and
about 19 different ppc config build with the series. The git tree above
was pushed with that. Considering you authored the change i am wondering
if you could help with checking other architecture (may be atleast arm
On 08/19/2020 06:30 PM, Aneesh Kumar K.V wrote:
> This patch series includes fixes for debug_vm_pgtable test code so that
> they follow page table updates rules correctly. The first two patches
> introduce
> changes w.r.t ppc64. The patches are included in this series for
> completeness. We
On 08/21/2020 02:20 PM, Aneesh Kumar K.V wrote:
>
>> Sure. I am hoping kernel test robot will pick this up. I did an x86 and
>> about 19 different ppc config build with the series. The git tree above was
>> pushed with that. Considering you authored the change i am wondering if you
>> could
On 08/21/2020 05:11 AM, Christophe Leroy wrote:
Le 21/08/2020 à 00:00, Andreas Schwab a écrit :
On Jun 29 2020, Christophe Leroy wrote:
Instead of leaving NX unset on all segments above the start
of vmalloc space, only leave NX unset on segments used for
modules.
I'm getting this
In is_module_segment(), when VMALLOC_END is over 0xf000,
ALIGN(VMALLOC_END, SZ_256M) has value 0.
In that case, addr >= ALIGN(VMALLOC_END, SZ_256M) is always
true then is_module_segment() always returns false.
Use (ALIGN(VMALLOC_END, SZ_256M) - 1) which will have
value 0x and will be
.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Nicholas-Piggin/huge-vmalloc-mappings/20200821-124543
base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
config
On 08/21/2020 12:23 PM, Aneesh Kumar K.V wrote:
> On 8/21/20 9:03 AM, Anshuman Khandual wrote:
>>
>>
>> On 08/19/2020 07:15 PM, Aneesh Kumar K.V wrote:
>>> "Aneesh Kumar K.V" writes:
>>>
This patch series includes fixes for debug_vm_pgtable test code so that
they follow page table
On 08/19/2020 06:31 PM, Aneesh Kumar K.V wrote:
> Make sure we call pte accessors with correct lock held.
>
> Signed-off-by: Aneesh Kumar K.V
> ---
> mm/debug_vm_pgtable.c | 34 --
> 1 file changed, 20 insertions(+), 14 deletions(-)
>
> diff --git
Commit 792f73f747b8 ("powerpc/hv-24x7: Add sysfs files inside hv-24x7
device to show cpumask") added cpumask file as part of hv-24x7 driver
inside the interface folder. Cpumask file suppose to be in the top
folder of the pmu driver inorder to make hotplug works.
This patch fix that issue and
On 8/21/20 1:33 PM, Anshuman Khandual wrote:
On 08/19/2020 06:31 PM, Aneesh Kumar K.V wrote:
Make sure we call pte accessors with correct lock held.
Signed-off-by: Aneesh Kumar K.V
---
mm/debug_vm_pgtable.c | 34 --
1 file changed, 20 insertions(+), 14
On 8/21/20 1:31 PM, Anshuman Khandual wrote:
On 08/21/2020 12:23 PM, Aneesh Kumar K.V wrote:
On 8/21/20 9:03 AM, Anshuman Khandual wrote:
On 08/19/2020 07:15 PM, Aneesh Kumar K.V wrote:
"Aneesh Kumar K.V" writes:
This patch series includes fixes for debug_vm_pgtable test code so that
On 8/21/20 9:03 AM, Anshuman Khandual wrote:
On 08/19/2020 07:15 PM, Aneesh Kumar K.V wrote:
"Aneesh Kumar K.V" writes:
This patch series includes fixes for debug_vm_pgtable test code so that
they follow page table updates rules correctly. The first two patches introduce
changes w.r.t
Hi Giuseppe,
Le 08/07/2020 à 20:44, Christophe Leroy a écrit :
Le 08/07/2020 à 19:36, Giuseppe Sacco a écrit :
Hi Cristophe,
Il giorno mer, 08/07/2020 alle 19.09 +0200, Christophe Leroy ha
scritto:
Hi
Le 08/07/2020 à 19:00, Giuseppe Sacco a écrit :
Hello,
while trying to debug a problem
On 8/20/20 8:02 PM, Christophe Leroy wrote:
Le 19/08/2020 à 15:01, Aneesh Kumar K.V a écrit :
set_pte_at() should not be used to set a pte entry at locations that
already holds a valid pte entry. Architectures like ppc64 don't do TLB
invalidate in set_pte_at() and hence expect it to be used
69 matches
Mail list logo
