* Re: powerpc/pseries: hwpoison the pages upon hitting UE
From: Michael Ellerman @ 2019-04-21 14:19 UTC (permalink / raw)
To: Ganesh Goudar, linuxppc-dev; +Cc: mahesh
In-Reply-To: <20190415100544.28459-1-ganeshgr@linux.ibm.com>
On Mon, 2019-04-15 at 10:05:44 UTC, Ganesh Goudar wrote:
> Add support to hwpoison the pages upon hitting machine check
> exception.
>
> This patch queues the address where UE is hit to percpu array
> and schedules work to plumb it into memory poison infrastructure.
>
> Reviewed-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
> Signed-off-by: Ganesh Goudar <ganeshgr@linux.ibm.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/7f177f9810ada8ec2e8b378eddbe2d91
cheers
^ permalink raw reply
* Re: MAINTAINERS: Update remaining @linux.vnet.ibm.com addresses
From: Michael Ellerman @ 2019-04-21 14:19 UTC (permalink / raw)
To: Lukas Bulwahn, Tyrel Datwyler
Cc: linux-pci, Paul E . McKenney, linuxppc-dev, linux-kernel,
Lukas Bulwahn
In-Reply-To: <20190411042752.22039-1-lukas.bulwahn@gmail.com>
On Thu, 2019-04-11 at 04:27:52 UTC, Lukas Bulwahn wrote:
> Paul McKenney attempted to update all email addresses @linux.vnet.ibm.com
> to @linux.ibm.com in commit 1dfddcdb95c4
> ("MAINTAINERS: Update from @linux.vnet.ibm.com to @linux.ibm.com"), but
> some still remained.
>
> We update the remaining email addresses in MAINTAINERS, hopefully finally
> catching all cases for good.
>
> Fixes: 1dfddcdb95c4 ("MAINTAINERS: Update from @linux.vnet.ibm.com to @linux.ibm.com")
> Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
> Acked-by: Paul E. McKenney <paulmck@linux.ibm.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/0235854e1c25069d14512a35ea5cd053
cheers
^ permalink raw reply
* Re: MAINTAINERS: Remove non-existent VAS file
From: Michael Ellerman @ 2019-04-21 14:19 UTC (permalink / raw)
To: Sukadev Bhattiprolu; +Cc: Joe Perches, linuxppc-dev, linux-kernel
In-Reply-To: <20190411013846.GA5628@us.ibm.com>
On Thu, 2019-04-11 at 01:38:46 UTC, Sukadev Bhattiprolu wrote:
> The file arch/powerpc/include/uapi/asm/vas.h was considered but
> never merged and should be removed from the MAINTAINERS file.
>
> While here, add missing email address.
>
> Reported-by: Joe Perches <joe@perches.com>
> Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.ibm.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/679d03f26a686dd609afd94fd7caad7d
cheers
^ permalink raw reply
* Re: powerpc/mm/radix: Do slb preload only with hash translation mode
From: Michael Ellerman @ 2019-04-21 14:19 UTC (permalink / raw)
To: Aneesh Kumar K.V, npiggin, benh, paulus; +Cc: Aneesh Kumar K.V, linuxppc-dev
In-Reply-To: <20190409040328.6038-1-aneesh.kumar@linux.ibm.com>
On Tue, 2019-04-09 at 04:03:28 UTC, "Aneesh Kumar K.V" wrote:
> Add radix_enabled check to avoid slb preload with radix translation.
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
> Acked-by: Nicholas Piggin <npiggin@gmail.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/f89bd8ba834e392ff614a7be9ee68c56
cheers
^ permalink raw reply
* Re: powerpc/pseries/iommu: fix set but not used values
From: Michael Ellerman @ 2019-04-21 14:19 UTC (permalink / raw)
To: Qian Cai, benh, paulus; +Cc: aik, linuxppc-dev, Qian Cai, linux-kernel
In-Reply-To: <20190407024808.39821-1-cai@lca.pw>
On Sun, 2019-04-07 at 02:48:08 UTC, Qian Cai wrote:
> The commit b7d6bf4fdd47 ("powerpc/pseries/pci: Remove obsolete SW
> invalidate") left 2 variables unused.
>
> arch/powerpc/platforms/pseries/iommu.c: In function 'tce_build_pSeries':
> arch/powerpc/platforms/pseries/iommu.c:108:17: warning: variable 'tces'
> set but not used [-Wunused-but-set-variable]
> __be64 *tcep, *tces;
> ^~~~
> arch/powerpc/platforms/pseries/iommu.c: In function 'tce_free_pSeries':
> arch/powerpc/platforms/pseries/iommu.c:132:17: warning: variable 'tces'
> set but not used [-Wunused-but-set-variable]
> __be64 *tcep, *tces;
> ^~~~
>
> Also, the commit 68c0449ea16d ("powerpc/pseries/iommu: Use memory@ nodes
> in max RAM address calculation") set "ranges" in
> ddw_memory_hotplug_max() but never use it.
>
> arch/powerpc/platforms/pseries/iommu.c: In function
> 'ddw_memory_hotplug_max':
> arch/powerpc/platforms/pseries/iommu.c:948:7: warning: variable 'ranges'
> set but not used [-Wunused-but-set-variable]
> int ranges, n_mem_addr_cells, n_mem_size_cells, len;
> ^~~~~~
>
> Signed-off-by: Qian Cai <cai@lca.pw>
> Reviewed-by: Mukesh Ojha <mojha@codeaurora.org>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/c05f57fdc34a3d00c9ee28a35772e9d1
cheers
^ permalink raw reply
* Re: powerpc/pseries/pmem: fix a set but not used value
From: Michael Ellerman @ 2019-04-21 14:19 UTC (permalink / raw)
To: Qian Cai, benh, paulus; +Cc: linuxppc-dev, oohall, Qian Cai, linux-kernel
In-Reply-To: <20190407015447.39292-1-cai@lca.pw>
On Sun, 2019-04-07 at 01:54:47 UTC, Qian Cai wrote:
> The commit 4c5d87db4978 ("powerpc/pseries: PAPR persistent memory
> support") set a local variable "count" in dlpar_hp_pmem() but never
> use it.
>
> arch/powerpc/platforms/pseries/pmem.c: In function 'dlpar_hp_pmem':
> arch/powerpc/platforms/pseries/pmem.c:109:6: warning: variable 'count'
> set but not used [-Wunused-but-set-variable]
>
> Signed-off-by: Qian Cai <cai@lca.pw>
> Reviewed-by: Mukesh Ojha <mojha@codeaurora.org>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/e663e1e06089773cdab03023563aead6
cheers
^ permalink raw reply
* Re: powerpc/mm: Fix build error with FLATMEM book3s64 config
From: Michael Ellerman @ 2019-04-21 14:19 UTC (permalink / raw)
To: Aneesh Kumar K.V, npiggin, benh, paulus, Christophe Leroy
Cc: Aneesh Kumar K.V, linuxppc-dev
In-Reply-To: <20190403060514.26119-1-aneesh.kumar@linux.ibm.com>
On Wed, 2019-04-03 at 06:05:14 UTC, "Aneesh Kumar K.V" wrote:
> The current value of MAX_PHYSMEM_BITS cannot work with 32 bit configs.
> We used to have MAX_PHYSMEM_BITS not defined without SPARSEMEM and 32
> bit configs never expected a value to be set for MAX_PHYSMEM_BITS.
>
> Dependent code such as zsmalloc derived the right values based on other
> fields. Instead of finding a value that works with different configs,
> use new values only for book3s_64. For 64 bit booke, use the definition
> of MAX_PHYSMEM_BITS as per commit a7df61a0e2b6 ("[PATCH] ppc64: Increase sparsemem defaults")
> That change was done in 2005 and hopefully will work with book3e 64.
>
> Fixes: 8bc086899816 ("powerpc/mm: Only define MAX_PHYSMEM_BITS in SPARSEMEM configurations")
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/6161a37307f3320808b5a7549593b991
cheers
^ permalink raw reply
* Re: powerpc/pseries/mce: Improve array initialization.
From: Michael Ellerman @ 2019-04-21 14:19 UTC (permalink / raw)
To: Mahesh J Salgaonkar, linuxppc-dev; +Cc: Nicholas Piggin
In-Reply-To: <155377322203.28683.445138408998573736.stgit@jupiter>
On Thu, 2019-03-28 at 11:40:33 UTC, Mahesh J Salgaonkar wrote:
> From: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
>
> This is a follow up to the patch that fixed misleading print for TLB
> mutlihit due to wrongly populated mc_err_types[] array. Convert all the
> static array initialization to '[x] = val' style for better
> readability of array indexing and avoid any further confusion.
>
> Suggested-by: Michael Ellerman <mpe@ellerman.id.au>
> Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/c9d8dda42372dce00ac3a1c653bef7b8
cheers
^ permalink raw reply
* Re: powerpc/mm: Fix section mismatch warning
From: Michael Ellerman @ 2019-04-21 14:19 UTC (permalink / raw)
To: Aneesh Kumar K.V, npiggin, benh, paulus; +Cc: Aneesh Kumar K.V, linuxppc-dev
In-Reply-To: <20190330054345.28771-1-aneesh.kumar@linux.ibm.com>
On Sat, 2019-03-30 at 05:43:45 UTC, "Aneesh Kumar K.V" wrote:
> This patch fix the below section mismatch warnings.
>
> WARNING: vmlinux.o(.text+0x2d1f44): Section mismatch in reference from the function devm_memremap_pages_release() to the function .meminit.text:arch_remove_memory()
> WARNING: vmlinux.o(.text+0x2d265c): Section mismatch in reference from the function devm_memremap_pages() to the function .meminit.text:arch_add_memory()
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/26ad26718dfaa7cf49d106d212ebf237
cheers
^ permalink raw reply
* Re: powerpc/64: Fix booting large kernels with STRICT_KERNEL_RWX
From: Michael Ellerman @ 2019-04-21 14:18 UTC (permalink / raw)
To: Russell Currey, linuxppc-dev
In-Reply-To: <20190327033554.4926-1-ruscur@russell.cc>
On Wed, 2019-03-27 at 03:35:54 UTC, Russell Currey wrote:
> With STRICT_KERNEL_RWX enabled anything marked __init is placed at a 16M
> boundary. This is necessary so that it can be repurposed later with
> different permissions. However, in kernels with text larger than 16M,
> this pushes early_setup past 32M, incapable of being reached by the
> branch instruction.
>
> Fix this by setting the CTR and branching there instead.
>
> Fixes: 1e0fc9d1eb2b ("powerpc/Kconfig: Enable STRICT_KERNEL_RWX for some configs")
> Signed-off-by: Russell Currey <ruscur@russell.cc>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/56c46bba9bbfe229b4472a5be313c44c
cheers
^ permalink raw reply
* Re: [v2,1/2] powerpc: Make some functions static
From: Michael Ellerman @ 2019-04-21 14:18 UTC (permalink / raw)
To: Mathieu Malaterre
Cc: Mathieu Malaterre, linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <20190326204720.18882-1-malat@debian.org>
On Tue, 2019-03-26 at 20:47:18 UTC, Mathieu Malaterre wrote:
> In commit cb9e4d10c448 ("[POWERPC] Add support for 750CL Holly board")
> new functions were added. Since most of these functions can be made static,
> make it so.
>
> Both holly_power_off and holly_halt functions were not changed since they
> are unused, making them static would have triggered the following warning
> (treated as error):
>
> arch/powerpc/platforms/embedded6xx/holly.c:244:13: error: 'holly_halt' defined but not used [-Werror=unused-function]
>
> Silence the following warnings triggered using W=1:
>
> arch/powerpc/platforms/embedded6xx/holly.c:47:5: error: no previous prototype for 'holly_exclude_device' [-Werror=missing-prototypes]
> arch/powerpc/platforms/embedded6xx/holly.c:190:6: error: no previous prototype for 'holly_show_cpuinfo' [-Werror=missing-prototypes]
> arch/powerpc/platforms/embedded6xx/holly.c:196:17: error: no previous prototype for 'holly_restart' [-Werror=missing-prototypes]
>
> Signed-off-by: Mathieu Malaterre <malat@debian.org>
> Reviewed-by: Mukesh Ojha <mojha@codeaurora.org>
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/308be6c7817c850b55c3b6ff4bf53c24
cheers
^ permalink raw reply
* Re: [v3] powerpc/8xx: fix possible object reference leak
From: Michael Ellerman @ 2019-04-21 14:18 UTC (permalink / raw)
To: Peng Hao, vitb, benh, paulus, christophe.leroy
Cc: linuxppc-dev, Wen Yang, linux-kernel
In-Reply-To: <1553596191-78889-1-git-send-email-peng.hao2@zte.com.cn>
On Tue, 2019-03-26 at 10:29:51 UTC, Peng Hao wrote:
> From: Wen Yang <wen.yang99@zte.com.cn>
>
> The call to of_find_compatible_node returns a node pointer with refcount
> incremented thus it must be explicitly decremented after the last
> usage.
> irq_domain_add_linear also calls of_node_get to increase refcount,
> so irq_domain will not be affected when it is released.
>
> Detected by coccinelle with the following warnings:
> ./arch/powerpc/platforms/8xx/pic.c:158:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 136, but without a corresponding object release within this function.
>
> Fixes: a8db8cf0d894 ("irq_domain: Replace irq_alloc_host() with
> revmap-specific initializers")
> Signed-off-by: Wen Yang <wen.yang99@zte.com.cn>
> Suggested-by: Christophe Leroy <christophe.leroy@c-s.fr>
> Suggested-by: Michael Ellerman <mpe@ellerman.id.au>
> Reviewed-by: Peng Hao <peng.hao2@zte.com.cn>
> Reviewed-by: Christophe Leroy <christophe.leroy@c-s.fr>
> Cc: Vitaly Bordug <vitb@kernel.crashing.org>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux-kernel@vger.kernel.org
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/cc76404feaed597bb4f5234d34d3f49e
cheers
^ permalink raw reply
* Re: arch/powerpc: Remove duplicate headers
From: Michael Ellerman @ 2019-04-21 14:18 UTC (permalink / raw)
To: jagdsh.linux, benh, paulus, npiggin, hristophe.leroy, arnd, anton,
paul.burton, mikey, akpm, mwb
Cc: Jagadeesh Pagadala, linuxppc-dev, linux-kernel
In-Reply-To: <1553345455-32085-1-git-send-email-jagdsh.linux@gmail.com>
On Sat, 2019-03-23 at 12:50:55 UTC, jagdsh.linux@gmail.com wrote:
> From: Jagadeesh Pagadala <jagdsh.linux@gmail.com>
>
> Remove duplicate headers which are included twice.
>
> Signed-off-by: Jagadeesh Pagadala <jagdsh.linux@gmail.com>
> Reviewed-by: Mukesh Ojha <mojha@codeaurora.org>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/6917735e8f905da1f62ccdf62830b185
cheers
^ permalink raw reply
* Re: powerpc: vdso: Make vdso32 installation conditional in vdso_install
From: Michael Ellerman @ 2019-04-21 14:18 UTC (permalink / raw)
To: Ben Hutchings, Benjamin Herrenschmidt, Paul Mackerras
Cc: linuxppc-dev, 785065
In-Reply-To: <20190322042436.nttfgsdpdshco27y@decadent.org.uk>
On Fri, 2019-03-22 at 04:24:37 UTC, Ben Hutchings wrote:
> The 32-bit vDSO is not needed and not normally built for 64-bit
> little-endian configurations. However, the vdso_install target still
> builds and installs it. Add the same config condition as is normally
> used for the build.
>
> Fixes: e0d005916994 ("powerpc/vdso: Disable building the 32-bit VDSO ...")
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/ff6d27823f619892ab96f7461764840e
cheers
^ permalink raw reply
* Re: powerpc/mm/64: Document the sizes of/sizes mapped by Pxx_INDEX_SIZE
From: Michael Ellerman @ 2019-04-21 14:18 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev; +Cc: aneesh.kumar
In-Reply-To: <20190314125453.4956-1-mpe@ellerman.id.au>
On Thu, 2019-03-14 at 12:54:53 UTC, Michael Ellerman wrote:
> Add comments describing the size in bytes of the various levels of the
> page table tree, and the size of the virtual address space mapped by
> each level, to make it clear what the sizes are without having to also
> look up other definitions.
>
> The code that calculates the sizes actually uses sizeof(pgd_t) etc.,
> so in theory these comments could skew vs the code, but the size of
> pgd_t etc. is unlikely to change very often.
>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
> Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Applied to powerpc next.
https://git.kernel.org/powerpc/c/eea86aa4171d4960f0fcdc99dab358c2
cheers
^ permalink raw reply
* Re: arch/powerpc/crypto/crc-vpmsum_test: Use cheaper random numbers for self-test
From: Michael Ellerman @ 2019-04-21 14:18 UTC (permalink / raw)
To: George Spelvin, Daniel Axtens, linuxppc-dev
Cc: George Spelvin, Paul Mackerras, Herbert Xu
In-Reply-To: <201903211042.x2LAgMp3003053@sdf.org>
On Thu, 2019-03-21 at 10:42:22 UTC, George Spelvin wrote:
> This code was filling a 64K buffer from /dev/urandom in order to
> compute a CRC over (on average half of) it by two different methods,
> comparing the CRCs, and repeating.
>
> This is not a remotely security-critical application, so use the far
> faster and cheaper prandom_u32() generator.
>
> And, while we're at it, only fill as much of the buffer as we plan to use.
>
> Signed-off-by: George Spelvin <lkml@sdf.org>
> Cc: Daniel Axtens <dja@axtens.net>
> Cc: Herbert Xu <herbert@gondor.apana.org.au>
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Acked-by: Daniel Axtens <dja@axtens.net>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/80d04b7fabe161a23d143b3bfcfca1b0
cheers
^ permalink raw reply
* Re: powerpc/powernv: Squash sparse warnings in opal-call.c
From: Michael Ellerman @ 2019-04-21 14:18 UTC (permalink / raw)
To: Andrew Donnellan, linuxppc-dev, npiggin
In-Reply-To: <20190314042727.3404-1-andrew.donnellan@au1.ibm.com>
On Thu, 2019-03-14 at 04:27:27 UTC, Andrew Donnellan wrote:
> sparse complains a lot about opal-call.c:
>
> arch/powerpc/platforms/powernv/opal-call.c:128:1: warning: symbol 'opal_invalid_call' was not declared. Should it be static?
> arch/powerpc/platforms/powernv/opal-call.c:129:1: warning: symbol 'opal_console_write' was not declared. Should it be static?
> arch/powerpc/platforms/powernv/opal-call.c:130:1: warning: symbol 'opal_console_read' was not declared. Should it be static?
>
> Those symbols are forward declared in opal.h, but we can't include that
> because the function signatures in opal.h are different. So instead, just
> add an extra forward declaration to the OPAL_CALL macro to shut sparse up.
>
> Signed-off-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/2f9196b67237f1e59f2753b2968f8ad6
cheers
^ permalink raw reply
* Re: [v3] powerpc/mm: move warning from resize_hpt_for_hotplug()
From: Michael Ellerman @ 2019-04-21 14:18 UTC (permalink / raw)
To: Laurent Vivier, linux-kernel; +Cc: Laurent Vivier, linuxppc-dev, David Gibson
In-Reply-To: <20190313102528.4632-1-lvivier@redhat.com>
On Wed, 2019-03-13 at 10:25:28 UTC, Laurent Vivier wrote:
> resize_hpt_for_hotplug() reports a warning when it cannot
> resize the hash page table ("Unable to resize hash page
> table to target order") but in some cases it's not a problem
> and can make user thinks something has not worked properly.
>
> This patch moves the warning to arch_remove_memory() to
> only report the problem when it is needed.
>
> Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
> Signed-off-by: Laurent Vivier <lvivier@redhat.com>
> Reviewed-by: Christophe Leroy <christophe.leroy@c-s.fr>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/f172acbfae1a78b1a3c775f78e8d0dcd
cheers
^ permalink raw reply
* Re: [v2, 03/10] powerpc/32: Remove MSR_PR test when returning from syscall
From: Michael Ellerman @ 2019-04-21 14:18 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras, ruscur
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <17f151878f35fd449b9375308dd096f0d922746b.1552292207.git.christophe.leroy@c-s.fr>
On Mon, 2019-03-11 at 08:30:30 UTC, Christophe Leroy wrote:
> syscalls are from user only, so we can account time without checking
> whether returning to kernel or user as it will only be user.
>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Patches 3-10 applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/e291b6d575bc6e4d1d36961b081be521
cheers
^ permalink raw reply
* Re: [v2] powerpc: silence unused-but-set-variable warnings
From: Michael Ellerman @ 2019-04-21 14:18 UTC (permalink / raw)
To: Qian Cai, benh, paulus; +Cc: linuxppc-dev, Qian Cai, linux-kernel
In-Reply-To: <20190307144031.52494-1-cai@lca.pw>
On Thu, 2019-03-07 at 14:40:31 UTC, Qian Cai wrote:
> pte_unmap() compiles away on some powerpc platforms, so silence the
> warnings below by making it a static inline function.
>
> mm/memory.c: In function 'copy_pte_range':
> mm/memory.c:820:24: warning: variable 'orig_dst_pte' set but not used
> [-Wunused-but-set-variable]
> mm/memory.c:820:9: warning: variable 'orig_src_pte' set but not used
> [-Wunused-but-set-variable]
> mm/madvise.c: In function 'madvise_free_pte_range':
> mm/madvise.c:318:9: warning: variable 'orig_pte' set but not used
> [-Wunused-but-set-variable]
> mm/swap_state.c: In function 'swap_ra_info':
> mm/swap_state.c:634:15: warning: variable 'orig_pte' set but not used
> [-Wunused-but-set-variable]
>
> Suggested-by: Christophe Leroy <christophe.leroy@c-s.fr>
> Signed-off-by: Qian Cai <cai@lca.pw>
> Reviewed-by: Christophe Leroy <christophe.leroy@c-s.fr>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/bff25143da0d623a1765bf78dbc82044
cheers
^ permalink raw reply
* Re: powerpc/highmem: change BUG_ON() to WARN_ON()
From: Michael Ellerman @ 2019-04-21 14:18 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <0365f99ce2b9273e269a241394957cba924f995e.1551951985.git.christophe.leroy@c-s.fr>
On Thu, 2019-03-07 at 09:47:50 UTC, Christophe Leroy wrote:
> In arch/powerpc/mm/highmem.c, BUG_ON() is called only when
> CONFIG_DEBUG_HIGHMEM is selected, this means the BUG_ON() is
> not vital and can be replaced by a a WARN_ON
>
> At the sametime, use IS_ENABLED() instead of #ifdef to clean a bit.
>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/6c84f8c5cbfb4bf728f88296bc035c4a
cheers
^ permalink raw reply
* Re: powerpc/configs: Enable CONFIG_USB_XHCI_HCD by default
From: Michael Ellerman @ 2019-04-21 14:18 UTC (permalink / raw)
To: Thomas Huth, linuxppc-dev; +Cc: Laurent Vivier, David Gibson, Paul Mackerras
In-Reply-To: <1549885032-15702-1-git-send-email-thuth@redhat.com>
On Mon, 2019-02-11 at 11:37:12 UTC, Thomas Huth wrote:
> Recent versions of QEMU provide a XHCI device by default these
> days instead of an old-fashioned OHCI device:
>
> https://git.qemu.org/?p=qemu.git;a=commitdiff;h=57040d451315320b7d27
>
> So to get the keyboard working in the graphical console there again,
> we should now include XHCI support in the kernel by default, too.
>
> Signed-off-by: Thomas Huth <thuth@redhat.com>
> Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
> Acked-by: Joel Stanley <joel@jms.id.au>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/24c174bb23ebcbe4c3979855b220513f
cheers
^ permalink raw reply
* Re: [1/2] powerpc/32: Add ppc_defconfig
From: Michael Ellerman @ 2019-04-21 14:18 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev
In-Reply-To: <20190207051652.11380-1-mpe@ellerman.id.au>
On Thu, 2019-02-07 at 05:16:51 UTC, Michael Ellerman wrote:
> Add a generic 32-bit defconfig called ppc_defconfig. This means we'll
> have a defconfig matching "uname -m" for all cases.
>
> This config is mostly intended for build testing but if someone wants
> to tweak it to get it booting on something that would be fine too.
>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
> Tested-by: Mathieu Malaterre <malat@debian.org>
Series applied to powerpc next.
https://git.kernel.org/powerpc/c/a273fa386a947612a23b0d56dcfb8823
cheers
^ permalink raw reply
* Re: powerpc/mm/radix: Make Radix require HUGETLB_PAGE
From: Michael Ellerman @ 2019-04-21 14:07 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev; +Cc: stewart, aneesh.kumar, joel
In-Reply-To: <20190417074140.25130-1-mpe@ellerman.id.au>
On Wed, 2019-04-17 at 07:41:40 UTC, Michael Ellerman wrote:
> Joel reported weird crashes using skiroot_defconfig, in his case we
> jumped into an NX page:
>
> kernel tried to execute exec-protected page (c000000002bff4f0) - exploit attempt? (uid: 0)
> BUG: Unable to handle kernel instruction fetch
> Faulting instruction address: 0xc000000002bff4f0
>
> Looking at the disassembly, we had simply branched to that address:
>
> c000000000c001bc 49fff335 bl c000000002bff4f0
>
> But that didn't match the original kernel image:
>
> c000000000c001bc 4bfff335 bl c000000000bff4f0 <kobject_get+0x8>
>
> When STRICT_KERNEL_RWX is enabled, and we're using the radix MMU, we
> call radix__change_memory_range() late in boot to change page
> protections. We do that both to mark rodata read only and also to mark
> init text no-execute. That involves walking the kernel page tables,
> and clearing _PAGE_WRITE or _PAGE_EXEC respectively.
>
> With radix we may use hugepages for the linear mapping, so the code in
> radix__change_memory_range() uses eg. pmd_huge() to test if it has
> found a huge mapping, and if so it stops the page table walk and
> changes the PMD permissions.
>
> However if the kernel is built without HUGETLBFS support, pmd_huge()
> is just a #define that always returns 0. That causes the code in
> radix__change_memory_range() to incorrectly interpret the PMD value as
> a pointer to a PTE page rather than as a PTE at the PMD level.
>
> Unfortunately the combination of _PAGE_PTE and _PAGE_PRESENT in the
> high bits of the PMD entry give us 0xc in the top nibble which means
> the PMD entry happens to look like a valid pointer into the linear
> mapping.
>
> We can see this using `dv` in xmon:
>
> 0:mon> dv c000000000000000
> pgd @ 0xc000000001740000
> pgdp @ 0xc000000001740000 = 0x80000000ffffb009
> pudp @ 0xc0000000ffffb000 = 0x80000000ffffa009
> pmdp @ 0xc0000000ffffa000 = 0xc00000000000018f <- not a pointer
> ptep @ 0xc000000000000100 = 0xa64bb17da64ab07d <- kernel text
>
> The end result is we treat the value at 0xc000000000000100 as a PTE
> and clear _PAGE_WRITE or _PAGE_EXEC, potentially corrupting the code
> at that address.
>
> In Joel's specific case we cleared the sign bit in the offset of the
> branch, causing a backward branch to turn into a forward branch which
> caused us to branch into a non-executable page. However the exact
> nature of the crash depends on kernel version, compiler version, and
> other factors.
>
> We need to fix radix__change_memory_range() to not use accessors that
> depend on HUGETLBFS, but we also have radix memory hotplug code that
> uses pmd_huge() etc that will also need fixing. So for now just
> disallow the broken combination of Radix with HUGETLBFS disabled.
>
> The only defconfig we have that is affected is skiroot_defconfig, so
> turn on HUGETLBFS there so that it still gets Radix.
>
> Fixes: 566ca99af026 ("powerpc/mm/radix: Add dummy radix_enabled()")
> Cc: stable@vger.kernel.org # v4.7+
> Reported-by: Joel Stanley <joel@jms.id.au>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Applied to powerpc fixes.
https://git.kernel.org/powerpc/c/8adddf349fda0d3de2f6bb41ddf838cb
cheers
^ permalink raw reply
* Re: [kernel,v2,1/2] powerpc/mm_iommu: Fix potential deadlock
From: Michael Ellerman @ 2019-04-21 14:07 UTC (permalink / raw)
To: Alexey Kardashevskiy, linuxppc-dev
Cc: Alexey Kardashevskiy, Aneesh Kumar K.V, kvm-ppc, David Gibson
In-Reply-To: <20190403041233.57619-2-aik@ozlabs.ru>
On Wed, 2019-04-03 at 04:12:32 UTC, Alexey Kardashevskiy wrote:
> Currently mm_iommu_do_alloc() is called in 2 cases:
> - VFIO_IOMMU_SPAPR_REGISTER_MEMORY ioctl() for normal memory:
> this locks &mem_list_mutex and then locks mm::mmap_sem
> several times when adjusting locked_vm or pinning pages;
> - vfio_pci_nvgpu_regops::mmap() for GPU memory:
> this is called with mm::mmap_sem held already and it locks
> &mem_list_mutex.
>
> So one can craft a userspace program to do special ioctl and mmap in
> 2 threads concurrently and cause a deadlock which lockdep warns about
> (below).
>
> We did not hit this yet because QEMU constructs the machine in a single
> thread.
>
> This moves the overlap check next to where the new entry is added and
> reduces the amount of time spent with &mem_list_mutex held.
>
> This moves locked_vm adjustment from under &mem_list_mutex.
>
> This relies on mm_iommu_adjust_locked_vm() doing nothing when entries==0.
>
> This is one of the lockdep warnings:
>
> ======================================================
> WARNING: possible circular locking dependency detected
> 5.1.0-rc2-le_nv2_aikATfstn1-p1 #363 Not tainted
> ------------------------------------------------------
> qemu-system-ppc/8038 is trying to acquire lock:
> 000000002ec6c453 (mem_list_mutex){+.+.}, at: mm_iommu_do_alloc+0x70/0x490
>
> but task is already holding lock:
> 00000000fd7da97f (&mm->mmap_sem){++++}, at: vm_mmap_pgoff+0xf0/0x160
>
> which lock already depends on the new lock.
>
> the existing dependency chain (in reverse order) is:
>
> -> #1 (&mm->mmap_sem){++++}:
> lock_acquire+0xf8/0x260
> down_write+0x44/0xa0
> mm_iommu_adjust_locked_vm.part.1+0x4c/0x190
> mm_iommu_do_alloc+0x310/0x490
> tce_iommu_ioctl.part.9+0xb84/0x1150 [vfio_iommu_spapr_tce]
> vfio_fops_unl_ioctl+0x94/0x430 [vfio]
> do_vfs_ioctl+0xe4/0x930
> ksys_ioctl+0xc4/0x110
> sys_ioctl+0x28/0x80
> system_call+0x5c/0x70
>
> -> #0 (mem_list_mutex){+.+.}:
> __lock_acquire+0x1484/0x1900
> lock_acquire+0xf8/0x260
> __mutex_lock+0x88/0xa70
> mm_iommu_do_alloc+0x70/0x490
> vfio_pci_nvgpu_mmap+0xc0/0x130 [vfio_pci]
> vfio_pci_mmap+0x198/0x2a0 [vfio_pci]
> vfio_device_fops_mmap+0x44/0x70 [vfio]
> mmap_region+0x5d4/0x770
> do_mmap+0x42c/0x650
> vm_mmap_pgoff+0x124/0x160
> ksys_mmap_pgoff+0xdc/0x2f0
> sys_mmap+0x40/0x80
> system_call+0x5c/0x70
>
> other info that might help us debug this:
>
> Possible unsafe locking scenario:
>
> CPU0 CPU1
> ---- ----
> lock(&mm->mmap_sem);
> lock(mem_list_mutex);
> lock(&mm->mmap_sem);
> lock(mem_list_mutex);
>
> *** DEADLOCK ***
>
> 1 lock held by qemu-system-ppc/8038:
> #0: 00000000fd7da97f (&mm->mmap_sem){++++}, at: vm_mmap_pgoff+0xf0/0x160
>
> Fixes: c10c21efa4bc ("powerpc/vfio/iommu/kvm: Do not pin device memory", 2018-12-19)
> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Applied to powerpc fixes, thanks.
https://git.kernel.org/powerpc/c/eb9d7a62c38628ab0ba6e59d22d7cb79
cheers
^ 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