* Re: [PATCH 1/9] selftests/powerpc: Make using_hash_mmu() work on Cell & PowerMac
From: Michael Ellerman @ 2020-09-09 13:27 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev
In-Reply-To: <20200819015727.1977134-1-mpe@ellerman.id.au>
On Wed, 19 Aug 2020 11:57:19 +1000, Michael Ellerman wrote:
> These platforms don't show the MMU in /proc/cpuinfo, but they always
> use hash, so teach using_hash_mmu() that.
Applied to powerpc/next.
[1/9] selftests/powerpc: Make using_hash_mmu() work on Cell & PowerMac
https://git.kernel.org/powerpc/c/34c103342be3f9397e656da7c5cc86e97b91f514
[2/9] selftests/powerpc: Give the bad_accesses test longer to run
https://git.kernel.org/powerpc/c/17c98a541dc9bb1162877af41cddbdca043f9a59
[3/9] selftests/powerpc: Move set_dscr() into rfi_flush.c
https://git.kernel.org/powerpc/c/d89002397cfb2b65267d6688fe671ee1cf7c5f0d
[4/9] selftests/powerpc: Include asm/cputable.h from utils.h
https://git.kernel.org/powerpc/c/178282a054dced1a08a9683d41ac08cbace2b2fe
[5/9] selftests/powerpc: Don't run DSCR tests on old systems
https://git.kernel.org/powerpc/c/4c3c3c502575556c4bc1b401235e641863b1bce6
[6/9] selftests/powerpc: Skip security tests on older CPUs
https://git.kernel.org/powerpc/c/3a31518a242dcb262b008d3bb5d4b1cf50cf4026
[7/9] selftests/powerpc: Skip L3 bank test on older CPUs
https://git.kernel.org/powerpc/c/4871a10b7b5f6b0632bff229884dad1cb1e8dc37
[8/9] selftests/powerpc: Don't touch VMX/VSX on older CPUs
https://git.kernel.org/powerpc/c/09275d717d1b2d7d5ed91f2140bb34246514a1b4
[9/9] selftests/powerpc: Properly handle failure in switch_endian_test
https://git.kernel.org/powerpc/c/003d6f5fd2cc3b529f3e6c529bc4bb0792930212
cheers
^ permalink raw reply
* Re: [PATCH 1/3] selftests/powerpc: Fix TM tests when CPU 0 is offline
From: Michael Ellerman @ 2020-09-09 13:27 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev
In-Reply-To: <20200813013445.686464-1-mpe@ellerman.id.au>
On Thu, 13 Aug 2020 11:34:43 +1000, Michael Ellerman wrote:
> Several of the TM tests fail spuriously if CPU 0 is offline, because
> they blindly try to affinitise to CPU 0.
>
> Fix them by picking any online CPU and using that instead.
Applied to powerpc/next.
[1/3] selftests/powerpc: Fix TM tests when CPU 0 is offline
https://git.kernel.org/powerpc/c/c0176429b7b07893a5c1fd38baff055c919ba9e3
[2/3] selftests/powerpc: Don't use setaffinity in tm-tmspr
https://git.kernel.org/powerpc/c/769628710c33b18ede837bb488e1d24084b35592
[3/3] selftests/powerpc: Run tm-tmspr test for longer
https://git.kernel.org/powerpc/c/b5a646a681f5d67ea5190a71d6e84a91efe63b7a
cheers
^ permalink raw reply
* Re: [PATCH v5 0/4] Allow bigger 64bit window by removing default DMA window
From: Michael Ellerman @ 2020-09-09 13:27 UTC (permalink / raw)
To: Leonardo Bras, Murilo Fossa Vicentini, Michael Ellerman,
Alexey Kardashevskiy, David Dai, Ram Pai, Thiago Jung Bauermann,
Paul Mackerras, Benjamin Herrenschmidt, Brian King
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20200805030455.123024-1-leobras.c@gmail.com>
On Wed, 5 Aug 2020 00:04:51 -0300, Leonardo Bras wrote:
> There are some devices in which a hypervisor may only allow 1 DMA window
> to exist at a time, and in those cases, a DDW is never created to them,
> since the default DMA window keeps using this resource.
>
> LoPAR recommends this procedure:
> 1. Remove the default DMA window,
> 2. Query for which configs the DDW can be created,
> 3. Create a DDW.
>
> [...]
Applied to powerpc/next.
[1/4] powerpc/pseries/iommu: Create defines for operations in ibm, ddw-applicable
https://git.kernel.org/powerpc/c/cac3e629086f1b2e31c87a6c9b0130d29843ae86
[2/4] powerpc/pseries/iommu: Update call to ibm, query-pe-dma-windows
https://git.kernel.org/powerpc/c/80f0251231131d164eddab78d2b6c1b8e37d0093
[3/4] powerpc/pseries/iommu: Move window-removing part of remove_ddw into remove_dma_window
https://git.kernel.org/powerpc/c/74d0b3994e147a2b503170b5e02f1d07dc086586
[4/4] powerpc/pseries/iommu: Allow bigger 64bit window by removing default DMA window
https://git.kernel.org/powerpc/c/8c0d51592f6f0123953633d1ecf21e843fce0bfd
cheers
^ permalink raw reply
* Re: [PATCH v3] powerpc: Warn about use of smt_snooze_delay
From: Michael Ellerman @ 2020-09-09 13:27 UTC (permalink / raw)
To: linuxppc-dev, Joel Stanley; +Cc: Gautham R . Shenoy
In-Reply-To: <20200902000012.3440389-1-joel@jms.id.au>
On Wed, 2 Sep 2020 09:30:11 +0930, Joel Stanley wrote:
> It's not done anything for a long time. Save the percpu variable, and
> emit a warning to remind users to not expect it to do anything.
>
> This uses pr_warn_once instead of pr_warn_ratelimit as testing
> 'ppc64_cpu --smt=off' on a 24 core / 4 SMT system showed the warning to
> be noisy, as the online/offline loop is slow.
>
> [...]
Applied to powerpc/next.
[1/1] powerpc: Warn about use of smt_snooze_delay
https://git.kernel.org/powerpc/c/a02f6d42357acf6e5de6ffc728e6e77faf3ad217
cheers
^ permalink raw reply
* Re: [PATCH v2] powerpc: Warn about use of smt_snooze_delay
From: Michael Ellerman @ 2020-09-09 13:27 UTC (permalink / raw)
To: linuxppc-dev, Joel Stanley; +Cc: Gautham R Shenoy, Tyrel Datwyler
In-Reply-To: <20200630015935.2675676-1-joel@jms.id.au>
On Tue, 30 Jun 2020 11:29:35 +0930, Joel Stanley wrote:
> It's not done anything for a long time. Save the percpu variable, and
> emit a warning to remind users to not expect it to do anything.
>
> Fixes: 3fa8cad82b94 ("powerpc/pseries/cpuidle: smt-snooze-delay cleanup.")
> Cc: stable@vger.kernel.org # v3.14
> Signed-off-by: Joel Stanley <joel@jms.id.au>
> --
> v2:
> Use pr_warn instead of WARN
> Reword and print proccess name with pid in message
> Leave CPU_FTR_SMT test in
> Add Fixes line
>
> [...]
Applied to powerpc/next.
[1/1] powerpc: Warn about use of smt_snooze_delay
https://git.kernel.org/powerpc/c/a02f6d42357acf6e5de6ffc728e6e77faf3ad217
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/powernv: Print helpful message when cores guarded
From: Michael Ellerman @ 2020-09-09 13:27 UTC (permalink / raw)
To: linuxppc-dev, Michael Ellerman, Joel Stanley
In-Reply-To: <20190801051630.5804-1-joel@jms.id.au>
On Thu, 1 Aug 2019 14:46:30 +0930, Joel Stanley wrote:
> Often the firmware will guard out cores after a crash. This often
> undesirable, and is not immediately noticeable.
>
> This adds an informative message when a CPU device tree nodes are marked
> bad in the device tree.
Applied to powerpc/next.
[1/1] powerpc/powernv: Print helpful message when cores guarded
https://git.kernel.org/powerpc/c/8f55984f530d7275531e17f36ea29229c2c410dd
cheers
^ permalink raw reply
* Re: [PATCH v2] powerpc: Update documentation of ISA versions for Power10
From: Michael Ellerman @ 2020-09-09 13:27 UTC (permalink / raw)
To: linuxppc-dev, Jordan Niethe
In-Reply-To: <20200827040556.1783-1-jniethe5@gmail.com>
On Thu, 27 Aug 2020 14:05:56 +1000, Jordan Niethe wrote:
> Update the CPU to ISA Version Mapping document to include Power10 and
> ISA v3.1.
Applied to powerpc/next.
[1/1] powerpc: Update documentation of ISA versions for Power10
https://git.kernel.org/powerpc/c/51a1588154cb1ddc4fe8fa786324dca398f1a458
cheers
^ permalink raw reply
* Re: [PATCH] selftests/powerpc: Fix prefixes in alignment_handler signal handler
From: Michael Ellerman @ 2020-09-09 13:27 UTC (permalink / raw)
To: linuxppc-dev, Jordan Niethe
In-Reply-To: <20200824131231.14008-1-jniethe5@gmail.com>
On Mon, 24 Aug 2020 23:12:31 +1000, Jordan Niethe wrote:
> The signal handler in the alignment handler self test has the ability to
> jump over the instruction that triggered the signal. It does this by
> incrementing the PT_NIP in the user context by 4. If it were a prefixed
> instruction this will mean that the suffix is then executed which is
> incorrect. Instead check if the major opcode indicates a prefixed
> instruction (e.g. it is 1) and if so increment PT_NIP by 8.
>
> [...]
Applied to powerpc/next.
[1/1] selftests/powerpc: Fix prefixes in alignment_handler signal handler
https://git.kernel.org/powerpc/c/db96221a683342fd4775fd820a4d5376cd2f2ed0
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/boot: Update Makefile comment for 64bit wrapper
From: Michael Ellerman @ 2020-09-09 13:27 UTC (permalink / raw)
To: linuxppc-dev, Jordan Niethe
In-Reply-To: <20200825035147.3239-1-jniethe5@gmail.com>
On Tue, 25 Aug 2020 13:51:47 +1000, Jordan Niethe wrote:
> As of commit 147c05168fc8 ("powerpc/boot: Add support for 64bit little
> endian wrapper") the comment in the Makefile is misleading. The wrapper
> packaging 64bit kernel may built as a 32 or 64 bit elf. Update the
> comment to reflect this.
Applied to powerpc/next.
[1/1] powerpc/boot: Update Makefile comment for 64bit wrapper
https://git.kernel.org/powerpc/c/364b236a0b6e86439b9025d961da8602db23d5bf
cheers
^ permalink raw reply
* Re: [PATCH v2] powerpc: Remove flush_instruction_cache() on 8xx
From: Michael Ellerman @ 2020-09-09 13:27 UTC (permalink / raw)
To: hch, Michael Ellerman, Christophe Leroy, Paul Mackerras,
Benjamin Herrenschmidt
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <245cabd8f291facac8c8c5fd370e361a69e02860.1597384145.git.christophe.leroy@csgroup.eu>
On Fri, 14 Aug 2020 05:49:29 +0000 (UTC), Christophe Leroy wrote:
> flush_instruction_cache() is never used on 8xx, remove it.
Applied to powerpc/next.
[1/1] powerpc: Remove flush_instruction_cache() on 8xx
https://git.kernel.org/powerpc/c/76d46a1e2fe2c35f24c07b7cc8a41afbf98b349e
cheers
^ permalink raw reply
* Re: [PATCH][V2] macintosh: windfarm: remove detatch debug containing spelling mistakes
From: Michael Ellerman @ 2020-09-09 13:27 UTC (permalink / raw)
To: linuxppc-dev, Wolfram Sang, Colin King, Benjamin Herrenschmidt
Cc: kernel-janitors, linux-kernel
In-Reply-To: <20200806102901.44988-1-colin.king@canonical.com>
On Thu, 6 Aug 2020 11:29:01 +0100, Colin King wrote:
> There are spelling mistakes in two debug messages. As recommended
> by Wolfram Sang, these can be removed as there is plenty of debug
> in the driver core.
Applied to powerpc/next.
[1/1] macintosh: windfarm: remove detatch debug containing spelling mistakes
https://git.kernel.org/powerpc/c/7db0a07273e8f581d0b3e8a102d3d9dd99f43528
cheers
^ permalink raw reply
* Re: [PATCH v3 1/2] powerpc/uaccess: Use flexible addressing with __put_user()/__get_user()
From: Michael Ellerman @ 2020-09-09 13:27 UTC (permalink / raw)
To: Christophe Leroy, Michael Ellerman, Benjamin Herrenschmidt,
Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <c27bc4e598daf3bbb225de7a1f5c52121cf1e279.1597235091.git.christophe.leroy@csgroup.eu>
On Wed, 12 Aug 2020 12:25:16 +0000 (UTC), Christophe Leroy wrote:
> At the time being, __put_user()/__get_user() and friends only use
> D-form addressing, with 0 offset. Ex:
>
> lwz reg1, 0(reg2)
>
> Give the compiler the opportunity to use other adressing modes
> whenever possible, to get more optimised code.
>
> [...]
Applied to powerpc/next.
[1/2] powerpc/uaccess: Use flexible addressing with __put_user()/__get_user()
https://git.kernel.org/powerpc/c/c20beffeec3cb6f6f52d9aef27f91a3f453a91f4
[2/2] powerpc/uaccess: Add pre-update addressing to __get_user_asm() and __put_user_asm()
https://git.kernel.org/powerpc/c/2f279eeb68b8eda43a95255db701b4faaeedbe0f
cheers
^ permalink raw reply
* Re: [PATCH v2] powerpc: Drop _nmask_and_or_msr()
From: Michael Ellerman @ 2020-09-09 13:27 UTC (permalink / raw)
To: Christophe Leroy, Michael Ellerman, Benjamin Herrenschmidt,
Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <c2d2b8dfb8dd677026b26dffc8d31070c38a6b89.1597388079.git.christophe.leroy@csgroup.eu>
On Fri, 14 Aug 2020 06:54:49 +0000 (UTC), Christophe Leroy wrote:
> _nmask_and_or_msr() is only used at two places to set MSR_IP.
>
> The SYNC is unnecessary as the users are not PowerPC 601.
>
> Can be easily writen in C.
>
> Do it, and drop _nmask_and_or_msr()
Applied to powerpc/next.
[1/1] powerpc: Drop _nmask_and_or_msr()
https://git.kernel.org/powerpc/c/e53281bc21f061f96c9004f534bc3e807d70cb73
cheers
^ permalink raw reply
* Re: [PATCH v2 1/4] powerpc: Remove flush_instruction_cache for book3s/32
From: Michael Ellerman @ 2020-09-09 13:27 UTC (permalink / raw)
To: hch, Michael Ellerman, Christophe Leroy, Paul Mackerras,
Benjamin Herrenschmidt
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <50098f49877cea0f46730a9df82dcabf84160e4b.1597384512.git.christophe.leroy@csgroup.eu>
On Fri, 14 Aug 2020 05:56:24 +0000 (UTC), Christophe Leroy wrote:
> The only callers of flush_instruction_cache() are:
>
> arch/powerpc/kernel/swsusp_booke.S: bl flush_instruction_cache
> arch/powerpc/mm/nohash/40x.c: flush_instruction_cache();
> arch/powerpc/mm/nohash/44x.c: flush_instruction_cache();
> arch/powerpc/mm/nohash/fsl_booke.c: flush_instruction_cache();
> arch/powerpc/platforms/44x/machine_check.c: flush_instruction_cache();
> arch/powerpc/platforms/44x/machine_check.c: flush_instruction_cache();
>
> [...]
Applied to powerpc/next.
[1/4] powerpc: Remove flush_instruction_cache for book3s/32
https://git.kernel.org/powerpc/c/e426ab39f41045a4c163031272b2f48d944b69c0
[2/4] powerpc: Move flush_instruction_cache() prototype in asm/cacheflush.h
https://git.kernel.org/powerpc/c/f663f3312051402d32952c44d156a20c0b854753
[3/4] powerpc: Rewrite 4xx flush_cache_instruction() in C
https://git.kernel.org/powerpc/c/de39b19452e784de5f90ae899851ab29a29bb42c
[4/4] powerpc: Rewrite FSL_BOOKE flush_cache_instruction() in C
https://git.kernel.org/powerpc/c/704dfe931df951895dea98bd1d9cacbb601b6451
cheers
^ permalink raw reply
* Re: [PATCH v1] powerpc/process: Remove unnecessary #ifdef CONFIG_FUNCTION_GRAPH_TRACER
From: Michael Ellerman @ 2020-09-09 13:27 UTC (permalink / raw)
To: Christophe Leroy, Paul Mackerras, Michael Ellerman,
Benjamin Herrenschmidt
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <9d11143d4e27ba8274369a926968756917584868.1597643153.git.christophe.leroy@csgroup.eu>
On Mon, 17 Aug 2020 05:46:39 +0000 (UTC), Christophe Leroy wrote:
> ftrace_graph_ret_addr() is always defined and returns 'ip' when
> CONFIG_FUNCTION GRAPH_TRACER is not set.
>
> So the #ifdef is not needed, remove it.
Applied to powerpc/next.
[1/1] powerpc/process: Remove unnecessary #ifdef CONFIG_FUNCTION_GRAPH_TRACER
https://git.kernel.org/powerpc/c/353bce211e00d183344f464ba1ee0e1ffb0e2a6c
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/irq: Drop forward declaration of struct irqaction
From: Michael Ellerman @ 2020-09-09 13:27 UTC (permalink / raw)
To: Christophe Leroy, Michael Ellerman, Benjamin Herrenschmidt,
Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <e0bcdabac45fcd26c02d7df273bd4a5827c6033d.1596716375.git.christophe.leroy@csgroup.eu>
On Thu, 6 Aug 2020 12:19:46 +0000 (UTC), Christophe Leroy wrote:
> Since the commit identified below, the forward declaration of
> struct irqaction is useless. Drop it.
Applied to powerpc/next.
[1/1] powerpc/irq: Drop forward declaration of struct irqaction
https://git.kernel.org/powerpc/c/b134cfc3e3276ccd5d29e39de5c848a45b08e410
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/32s: Fix assembler warning about r0
From: Michael Ellerman @ 2020-09-09 13:27 UTC (permalink / raw)
To: Christophe Leroy, Michael Ellerman, Benjamin Herrenschmidt,
Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <2b69ac8e1cddff6f808fc7415907179eab4aae9e.1596693679.git.christophe.leroy@csgroup.eu>
On Thu, 6 Aug 2020 06:01:42 +0000 (UTC), Christophe Leroy wrote:
> The assembler says:
> arch/powerpc/kernel/head_32.S:1095: Warning: invalid register expression
>
> It's objecting to the use of r0 as the RA argument. That's because
> when RA = 0 the literal value 0 is used, rather than the content of
> r0, making the use of r0 in the source potentially confusing.
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/32s: Fix assembler warning about r0
https://git.kernel.org/powerpc/c/b51ba4fe2e134b631f9c8f45423707aab71449b5
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/hwirq: Remove stale forward irq_chip declaration
From: Michael Ellerman @ 2020-09-09 13:27 UTC (permalink / raw)
To: Christophe Leroy, Paul Mackerras, Michael Ellerman,
Benjamin Herrenschmidt
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <fbe58d27cf128d5fe581e4510ded8701858f268e.1596716328.git.christophe.leroy@csgroup.eu>
On Thu, 6 Aug 2020 12:19:06 +0000 (UTC), Christophe Leroy wrote:
> Since commit identified below, the forward declaration of
> struct irq_chip is useless (was struct hw_interrupt_type at that time)
>
> Remove it, together with the associated comment.
Applied to powerpc/next.
[1/1] powerpc/hwirq: Remove stale forward irq_chip declaration
https://git.kernel.org/powerpc/c/169b9afee572853522901b7cbf34842c0494a887
cheers
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/fpu: Drop cvt_fd() and cvt_df()
From: Michael Ellerman @ 2020-09-09 13:27 UTC (permalink / raw)
To: Christophe Leroy, Paul Mackerras, Michael Ellerman,
Benjamin Herrenschmidt
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <d5641ada199b8dd2af16ad00a66084cf974f2704.1596716418.git.christophe.leroy@csgroup.eu>
On Thu, 6 Aug 2020 12:20:34 +0000 (UTC), Christophe Leroy wrote:
> Those two functions have been unused since commit identified below.
> Drop them.
Applied to powerpc/next.
[1/2] powerpc/fpu: Drop cvt_fd() and cvt_df()
https://git.kernel.org/powerpc/c/63442de4301188129e1fcff144fbfb966ad5eb19
[2/2] powerpc: drop hard_reset_now() and poweroff_now() declaration
https://git.kernel.org/powerpc/c/82eb1792426f8a171cdaa6cfccb63c39f55bc9bd
cheers
^ permalink raw reply
* Re: [PATCH v2 1/2] powerpc/perf: consolidate GPCI hcall structs into asm/hvcall.h
From: Michael Ellerman @ 2020-09-09 13:27 UTC (permalink / raw)
To: Scott Cheloha, linuxppc-dev; +Cc: Nathan Lynch, Tyrel Datwylder
In-Reply-To: <20200727184605.2945095-1-cheloha@linux.ibm.com>
On Mon, 27 Jul 2020 13:46:04 -0500, Scott Cheloha wrote:
> The H_GetPerformanceCounterInfo (GPCI) hypercall input/output structs are
> useful to modules outside of perf/, so move them into asm/hvcall.h to live
> alongside the other powerpc hypercall structs.
>
> Leave the perf-specific GPCI stuff in perf/hv-gpci.h.
Applied to powerpc/next.
[1/2] powerpc/perf: consolidate GPCI hcall structs into asm/hvcall.h
https://git.kernel.org/powerpc/c/59562b5c33d6ff3685509ed58b2ed3c5b5712704
[2/2] powerpc/pseries: new lparcfg key/value pair: partition_affinity_score
https://git.kernel.org/powerpc/c/5d1bc776428f34941a6237afb9454061b5b5e1e1
cheers
^ permalink raw reply
* Re: [PATCH v3] pseries/drmem: don't cache node id in drmem_lmb struct
From: Michael Ellerman @ 2020-09-09 13:27 UTC (permalink / raw)
To: Scott Cheloha, linuxppc-dev
Cc: Nathan Lynch, Laurent Dufour, Michal Suchanek, Rick Lindsley,
David Hildenbrand
In-Reply-To: <20200811015115.63677-1-cheloha@linux.ibm.com>
On Mon, 10 Aug 2020 20:51:15 -0500, Scott Cheloha wrote:
> 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 find_memory_block() runs in sub-linear
> time this approach is negligibly slower than what we do at present.
>
> [...]
Applied to powerpc/next.
[1/1] pseries/drmem: don't cache node id in drmem_lmb struct
https://git.kernel.org/powerpc/c/e5e179aa3a39c818db8fbc2dce8d2cd24adaf657
cheers
^ permalink raw reply
* Re: [RFC PATCH v2 1/3] mm/gup: fix gup_fast with dynamic page table folding
From: Gerald Schaefer @ 2020-09-09 12:29 UTC (permalink / raw)
To: Dave Hansen
Cc: Peter Zijlstra, Dave Hansen, linux-mm, Paul Mackerras,
linux-sparc, Alexander Gordeev, Claudio Imbrenda, Will Deacon,
linux-arch, linux-s390, Vasily Gorbik, Christian Borntraeger,
Richard Weinberger, linux-x86, Russell King, Jason Gunthorpe,
Ingo Molnar, Catalin Marinas, Andrey Ryabinin, Heiko Carstens,
Arnd Bergmann, John Hubbard, Jeff Dike, linux-um, Borislav Petkov,
Andy Lutomirski, Thomas Gleixner, linux-arm, linux-power, LKML,
Andrew Morton, Linus Torvalds, Mike Rapoport
In-Reply-To: <0dbc6ec8-45ea-0853-4856-2bc1e661a5a5@intel.com>
On Tue, 8 Sep 2020 07:30:50 -0700
Dave Hansen <dave.hansen@intel.com> wrote:
> On 9/7/20 11:00 AM, Gerald Schaefer wrote:
> > Commit 1a42010cdc26 ("s390/mm: convert to the generic get_user_pages_fast
> > code") introduced a subtle but severe bug on s390 with gup_fast, due to
> > dynamic page table folding.
>
> Would it be fair to say that the "fake" page table entries s390
> allocates on the stack are what's causing the trouble here? That might
> be a nice thing to open up with here. "Dynamic page table folding"
> really means nothing to me.
Sorry, I guess my previous reply does not really explain "what the heck
is dynamic page table folding?".
On s390, we can have different number of page table levels for different
processes / mms. We always start with 3 levels, and update dynamically
on process demand to 4 or 5 levels, hence the dynamic folding. Still,
the PxD_SIZE/SHIFT is defined statically, so that e.g. pXd_addr_end() will
not reflect this dynamic behavior.
For the various pagetable walkers using pXd_addr_end() (w/o READ_ONCE
logic) this is no problem. With static folding, iteration over the folded
levels will always happen at pgd level (top-level folding). For s390,
we stay at the respective level and iterate there (dynamic middle-level
folding), only return to pgd level if there really were 5 levels.
This only works well as long there are real pagetable pointers involved,
that can also be used for iteration. For gup_fast, or any other future
pagetable walkers using the READ_ONCE logic w/o lock, that is not true.
There are pointers involved to local pXd values on the stack, because of
the READ_ONCE logic, and our middle-level iteration will suddenly iterate
over such stack pointers instead of pagetable pointers.
This will be addressed by making the pXd_addr_end() dynamic, for which
we need to see the pXd value in order to determine its level / type.
^ permalink raw reply
* Re: [PATCH v2 3/7] mm/memory_hotplug: prepare passing flags to add_memory() and friends
From: David Hildenbrand @ 2020-09-09 11:51 UTC (permalink / raw)
To: Michael Ellerman, Greg Kroah-Hartman
Cc: linux-hyperv, Michal Hocko, Michael S. Tsirkin, Jason Wang,
Pingfan Liu, virtualization, linux-mm, Paul Mackerras,
K. Y. Srinivasan, Boris Ostrovsky, linux-s390, Wei Liu,
Stefano Stabellini, Dave Jiang, Baoquan He, Jason Gunthorpe,
Vishal Verma, linux-acpi, xen-devel, Heiko Carstens, Len Brown,
Nathan Lynch, Vasily Gorbik, Leonardo Bras, Haiyang Zhang,
Stephen Hemminger, Dan Williams, Christian Borntraeger,
Juergen Gross, Pankaj Gupta, Libor Pechacek, linux-nvdimm,
Rafael J. Wysocki, linux-kernel, Wei Yang, Oliver O'Halloran,
Andrew Morton, linuxppc-dev
In-Reply-To: <5145c5c4-d9c0-85a8-7e0b-ccfa03eb0427@redhat.com>
On 09.09.20 13:37, David Hildenbrand wrote:
> On 09.09.20 13:24, Michael Ellerman wrote:
>> David Hildenbrand <david@redhat.com> writes:
>>> On 09.09.20 09:17, Greg Kroah-Hartman wrote:
>>>> On Tue, Sep 08, 2020 at 10:10:08PM +0200, David Hildenbrand wrote:
>>>>> We soon want to pass flags, e.g., to mark added System RAM resources.
>>>>> mergeable. Prepare for that.
>>>>
>>>> What are these random "flags", and how do we know what should be passed
>>>> to them?
>>>>
>>>> Why not make this an enumerated type so that we know it all works
>>>> properly, like the GPF_* flags are? Passing around a random unsigned
>>>> long feels very odd/broken...
>>>
>>> Agreed, an enum (mhp_flags) seems to give a better hint what can
>>> actually be passed. Thanks!
>>
>> You probably know this but ...
>>
>> Just using a C enum doesn't get you any type safety.
>>
>> You can get some checking via sparse by using __bitwise, which is what
>> gfp_t does. You don't actually have to use an enum for that, it works
>> with #defines also.
>
> Yeah, we seem to be using different approaches. And there is always a
> way to mess things up :)
>
> gfp_t is one (extreme) example, enum memblock_flags is another example.
> I tend to prefer an enum in this particular case, because it's simple
> and at least tells the user which values are expected.
>
Gave it another try, looks like mhp_t (like gfp_t) is actually nicer.
--
Thanks,
David / dhildenb
^ permalink raw reply
* Re: [PATCH v2 3/7] mm/memory_hotplug: prepare passing flags to add_memory() and friends
From: David Hildenbrand @ 2020-09-09 11:37 UTC (permalink / raw)
To: Michael Ellerman, Greg Kroah-Hartman
Cc: linux-hyperv, Michal Hocko, Michael S. Tsirkin, Jason Wang,
Pingfan Liu, virtualization, linux-mm, Paul Mackerras,
K. Y. Srinivasan, Boris Ostrovsky, linux-s390, Wei Liu,
Stefano Stabellini, Dave Jiang, Baoquan He, Jason Gunthorpe,
Vishal Verma, linux-acpi, xen-devel, Heiko Carstens, Len Brown,
Nathan Lynch, Vasily Gorbik, Leonardo Bras, Haiyang Zhang,
Stephen Hemminger, Dan Williams, Christian Borntraeger,
Juergen Gross, Pankaj Gupta, Libor Pechacek, linux-nvdimm,
Rafael J. Wysocki, linux-kernel, Wei Yang, Oliver O'Halloran,
Andrew Morton, linuxppc-dev
In-Reply-To: <87eenbry5p.fsf@mpe.ellerman.id.au>
On 09.09.20 13:24, Michael Ellerman wrote:
> David Hildenbrand <david@redhat.com> writes:
>> On 09.09.20 09:17, Greg Kroah-Hartman wrote:
>>> On Tue, Sep 08, 2020 at 10:10:08PM +0200, David Hildenbrand wrote:
>>>> We soon want to pass flags, e.g., to mark added System RAM resources.
>>>> mergeable. Prepare for that.
>>>
>>> What are these random "flags", and how do we know what should be passed
>>> to them?
>>>
>>> Why not make this an enumerated type so that we know it all works
>>> properly, like the GPF_* flags are? Passing around a random unsigned
>>> long feels very odd/broken...
>>
>> Agreed, an enum (mhp_flags) seems to give a better hint what can
>> actually be passed. Thanks!
>
> You probably know this but ...
>
> Just using a C enum doesn't get you any type safety.
>
> You can get some checking via sparse by using __bitwise, which is what
> gfp_t does. You don't actually have to use an enum for that, it works
> with #defines also.
Yeah, we seem to be using different approaches. And there is always a
way to mess things up :)
gfp_t is one (extreme) example, enum memblock_flags is another example.
I tend to prefer an enum in this particular case, because it's simple
and at least tells the user which values are expected.
Thoughts?
>
> Or you can wrap the flag in a struct, the way atomic_t does, and then
> the compiler will prevent passing plain integers in place of your custom
> type.
--
Thanks,
David / dhildenb
^ permalink raw reply
* Re: [PATCH v4 00/13] mm/debug_vm_pgtable fixes
From: Gerald Schaefer @ 2020-09-09 11:36 UTC (permalink / raw)
To: Anshuman Khandual
Cc: linux-s390@vger.kernel.org, Aneesh Kumar K.V, linux-mm,
Vineet Gupta, akpm, linux-snps-arc@lists.infradead.org,
linuxppc-dev, linux-riscv, Gerald Schaefer
In-Reply-To: <d4199cd4-e042-7a05-8a78-703eae958589@arm.com>
On Wed, 9 Sep 2020 13:38:25 +0530
Anshuman Khandual <anshuman.khandual@arm.com> wrote:
>
>
> On 09/04/2020 08:56 PM, Gerald Schaefer wrote:
> > On Fri, 4 Sep 2020 12:18:05 +0530
> > Anshuman Khandual <anshuman.khandual@arm.com> wrote:
> >
> >>
> >>
> >> On 09/02/2020 05:12 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 can
> >>> merge them via ppc64 tree if required.
> >>>
> >>> Hugetlb test is disabled on ppc64 because that needs larger change to satisfy
> >>> page table update rules.
> >>>
> >>> These tests are broken w.r.t page table update rules and results in kernel
> >>> crash as below.
> >>>
> >>> [ 21.083519] kernel BUG at arch/powerpc/mm/pgtable.c:304!
> >>> cpu 0x0: Vector: 700 (Program Check) at [c000000c6d1e76c0]
> >>> pc: c00000000009a5ec: assert_pte_locked+0x14c/0x380
> >>> lr: c0000000005eeeec: pte_update+0x11c/0x190
> >>> sp: c000000c6d1e7950
> >>> msr: 8000000002029033
> >>> current = 0xc000000c6d172c80
> >>> paca = 0xc000000003ba0000 irqmask: 0x03 irq_happened: 0x01
> >>> pid = 1, comm = swapper/0
> >>> kernel BUG at arch/powerpc/mm/pgtable.c:304!
> >>> [link register ] c0000000005eeeec pte_update+0x11c/0x190
> >>> [c000000c6d1e7950] 0000000000000001 (unreliable)
> >>> [c000000c6d1e79b0] c0000000005eee14 pte_update+0x44/0x190
> >>> [c000000c6d1e7a10] c000000001a2ca9c pte_advanced_tests+0x160/0x3d8
> >>> [c000000c6d1e7ab0] c000000001a2d4fc debug_vm_pgtable+0x7e8/0x1338
> >>> [c000000c6d1e7ba0] c0000000000116ec do_one_initcall+0xac/0x5f0
> >>> [c000000c6d1e7c80] c0000000019e4fac kernel_init_freeable+0x4dc/0x5a4
> >>> [c000000c6d1e7db0] c000000000012474 kernel_init+0x24/0x160
> >>> [c000000c6d1e7e20] c00000000000cbd0 ret_from_kernel_thread+0x5c/0x6c
> >>>
> >>> With DEBUG_VM disabled
> >>>
> >>> [ 20.530152] BUG: Kernel NULL pointer dereference on read at 0x00000000
> >>> [ 20.530183] Faulting instruction address: 0xc0000000000df330
> >>> cpu 0x33: Vector: 380 (Data SLB Access) at [c000000c6d19f700]
> >>> pc: c0000000000df330: memset+0x68/0x104
> >>> lr: c00000000009f6d8: hash__pmdp_huge_get_and_clear+0xe8/0x1b0
> >>> sp: c000000c6d19f990
> >>> msr: 8000000002009033
> >>> dar: 0
> >>> current = 0xc000000c6d177480
> >>> paca = 0xc00000001ec4f400 irqmask: 0x03 irq_happened: 0x01
> >>> pid = 1, comm = swapper/0
> >>> [link register ] c00000000009f6d8 hash__pmdp_huge_get_and_clear+0xe8/0x1b0
> >>> [c000000c6d19f990] c00000000009f748 hash__pmdp_huge_get_and_clear+0x158/0x1b0 (unreliable)
> >>> [c000000c6d19fa10] c0000000019ebf30 pmd_advanced_tests+0x1f0/0x378
> >>> [c000000c6d19fab0] c0000000019ed088 debug_vm_pgtable+0x79c/0x1244
> >>> [c000000c6d19fba0] c0000000000116ec do_one_initcall+0xac/0x5f0
> >>> [c000000c6d19fc80] c0000000019a4fac kernel_init_freeable+0x4dc/0x5a4
> >>> [c000000c6d19fdb0] c000000000012474 kernel_init+0x24/0x160
> >>> [c000000c6d19fe20] c00000000000cbd0 ret_from_kernel_thread+0x5c/0x6c
> >>>
> >>> Changes from v3:
> >>> * Address review feedback
> >>> * Move page table depost and withdraw patch after adding pmdlock to avoid bisect failure.
> >>
> >> This version
> >>
> >> - Builds on x86, arm64, s390, arc, powerpc and riscv (defconfig with DEBUG_VM_PGTABLE)
> >> - Runs on arm64 and x86 without any regression, atleast nothing that I have noticed
> >> - Will be great if this could get tested on s390, arc, riscv, ppc32 platforms as well
> >
> > When I quickly tested v3, it worked fine, but now it turned out to
> > only work fine "sometimes", both v3 and v4. I need to look into it
> > further, but so far it seems related to the hugetlb_advanced_tests().
> >
> > I guess there was already some discussion on this test, but we did
> > not receive all of the thread(s). Please always add at least
> > linux-s390@vger.kernel.org and maybe myself and Vasily Gorbik <gor@linux.ibm.com>
> > for further discussions.
>
> IIRC, the V3 series previously had all these addresses copied properly
> but this version once again missed copying all required addresses.
I also had issues with the de.ibm.com address, which might also have
made some mails disappear, and others might simply have been overlooked
be me. Don't bother, my bad.
>
> >
> > That being said, sorry for duplications, this might already have been
> > discussed. Preliminary analysis showed that it only seems to go wrong
> > for certain random vaddr values. I cannot make any sense of that yet,
> > but what seems strange to me is that the hugetlb_advanced_tests()
> > take a (real) pte_t pointer as input, and also use that for all
> > kinds of operations (set_huge_pte_at, huge_ptep_get_and_clear, etc.).
> >
> > Although all the hugetlb code in the kernel is (mis)using pte_t
> > pointers instead of the correct pmd/pud_t pointers like THP, that
> > is just for historic reasons. The pointers will actually never point
> > to a real pte_t (i.e. page table entry), but of course to a pmd
> > or pud entry, depending on hugepage size.
>
> HugeTLB logically operates on a PTE entry irrespective of it's real
> page table level position. Nonetheless, IIUC, vaddr here should have
> been aligned to real page table level in which the entry is being
> mapped currently.
That goes back to the time where only x86 had hugepages, and they
have the same layout for pte/pmd/etc entries, so it simply didn't
matter that the code (mis)used pte pointers / entries. But even for
x86, the hugetlb pte pointers would never have pointed to real ptes,
but pmds instead. That's why I call it misuse.
s390 is very sensitive to page table level, and we can also determine
the level from the entry value, which is used for some primitives.
Others have implicit assumptions and calculations, which go wrong
if a wrong level is passed in, like in this case for
huge_ptep_get_and_clear(). Simply aligning vaddr / pfn will not
be enough to fix this for s390, it has to be a pmd/pud pointer.
Or, as you already mentioned, the result of huge_pte_alloc().
Furthermore, the pmd and pte layout are different, so we simply cannot
use any pte_xxx primitives for hugepages. That was the reason for
introducing huge_ptep_get(), which will do an implicit conversion
from the real pmd/pud entry to a "fake" pte entry, which can then
be used with such pte_xxx primitives. Before writing it back in
set_huge_pte_at() we then do the reverse conversion to a proper
pmd/pud again.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox