* [PATCH 09/12] powerpc/prom_init: Move a few remaining statics to appropriate sections
From: Benjamin Herrenschmidt @ 2018-10-15 2:49 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20181015025000.4522-1-benh@kernel.crashing.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/kernel/prom_init.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index cbd54fe30367..306562d4d818 100644
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -173,7 +173,7 @@ static unsigned long __prombss prom_tce_alloc_end;
#endif
#ifdef CONFIG_PPC_PSERIES
-static bool prom_radix_disable __prombss;
+static bool __prombss prom_radix_disable;
#endif
struct platform_support {
@@ -210,7 +210,7 @@ static int __prombss mem_reserve_cnt;
static cell_t __prombss regbuf[1024];
-static bool rtas_has_query_cpu_stopped;
+static bool __prombss rtas_has_query_cpu_stopped;
/*
@@ -525,8 +525,8 @@ static void add_string(char **str, const char *q)
static char *tohex(unsigned int x)
{
- static char digits[] = "0123456789abcdef";
- static char result[9];
+ static const char digits[] __initconst = "0123456789abcdef";
+ static char result[9] __prombss;
int i;
result[8] = 0;
@@ -2324,7 +2324,7 @@ static void __init scan_dt_build_struct(phandle node, unsigned long *mem_start,
char *namep, *prev_name, *sstart, *p, *ep, *lp, *path;
unsigned long soff;
unsigned char *valp;
- static char pname[MAX_PROPERTY_NAME];
+ static char pname[MAX_PROPERTY_NAME] __prombss;
int l, room, has_phandle = 0;
dt_push_token(OF_DT_BEGIN_NODE, mem_start, mem_end);
--
2.17.1
^ permalink raw reply related
* Re: powerpc/xmon: Show the stack protector canary in xmon
From: Michael Ellerman @ 2018-10-15 4:01 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev
In-Reply-To: <20181015022339.27140-1-mpe@ellerman.id.au>
On Mon, 2018-10-15 at 02:23:39 UTC, Michael Ellerman wrote:
> This is helpful for debugging stack protector crashes.
>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Applied to powerpc next.
https://git.kernel.org/powerpc/c/50530f5eac0c023cfc313d7ed342d4
cheers
^ permalink raw reply
* Re: [1/6] powerpc/64s/hash: Convert SLB miss handlers to C
From: Michael Ellerman @ 2018-10-15 4:01 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev; +Cc: aneesh.kumar, npiggin
In-Reply-To: <20181013131836.26764-1-mpe@ellerman.id.au>
On Sat, 2018-10-13 at 13:18:31 UTC, Michael Ellerman wrote:
> From: Nicholas Piggin <npiggin@gmail.com>
>
> This patch moves SLB miss handlers completely to C, using the standard
> exception handler macros to set up the stack and branch to C.
>
> This can be done because the segment containing the kernel stack is
> always bolted, so accessing it with relocation on will not cause an
> SLB exception.
>
> Arbitrary kernel memory must not be accessed when handling kernel
> space SLB misses, so care should be taken there. However user SLB
> misses can access any kernel memory, which can be used to move some
> fields out of the paca (in later patches).
>
> User SLB misses could quite easily reconcile IRQs and set up a first
> class kernel environment and exit via ret_from_except, however that
> doesn't seem to be necessary at the moment, so we only do that if a
> bad fault is encountered.
>
> [ Credit to Aneesh for bug fixes, error checks, and improvements to
> bad address handling, etc ]
>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
> [mpe: Disallow tracing for all of slb.c for now.]
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Series applied to powerpc next.
https://git.kernel.org/powerpc/c/48e7b76957457f9a6f086ca2bbe49e
cheers
^ permalink raw reply
* Re: [1/3] powerpc: Split user/kernel definitions of struct pt_regs
From: Michael Ellerman @ 2018-10-15 4:01 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev; +Cc: npiggin
In-Reply-To: <20181013105646.5147-1-mpe@ellerman.id.au>
On Sat, 2018-10-13 at 10:56:44 UTC, Michael Ellerman wrote:
> We use a shared definition for struct pt_regs in uapi/asm/ptrace.h.
> That means the layout of the structure is ABI, ie. we can't change it.
>
> That would be fine if it was only used to describe the user-visible
> register state of a process, but it's also the struct we use in the
> kernel to describe the registers saved in an interrupt frame.
>
> We'd like more flexibility in the content (and possibly layout) of the
> kernel version of the struct, but currently that's not possible.
>
> So split the definition into a user-visible definition which remains
> unchanged, and a kernel internal one.
>
> At the moment they're still identical, and we check that at build
> time. That's because we have code (in ptrace etc.) that assumes that
> they are the same. We will fix that code in future patches, and then
> we can break the strict symmetry between the two structs.
>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
> Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
Series applied to powerpc next.
https://git.kernel.org/powerpc/c/002af9391bfbe84f8e491bb10bd9c6
cheers
^ permalink raw reply
* Re: powerpc/64: properly initialise the stackprotector canary on SMP.
From: Michael Ellerman @ 2018-10-15 4:01 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras,
abdhalee
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <a2694b8ffeb6c52d1c755d8a7bfaac689c4e1c6d.1539423893.git.christophe.leroy@c-s.fr>
On Sat, 2018-10-13 at 09:45:12 UTC, Christophe Leroy wrote:
> commit 06ec27aea9fc ("powerpc/64: add stack protector support")
> doesn't initialise the stack canary on SMP secondary CPU's paca,
> leading to the following false positive report from the
> stack protector.
>
> smp: Bringing up secondary CPUs ...
> Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: __schedule+0x978/0xa80
> CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.19.0-rc7-next-20181010-autotest-autotest #1
> Call Trace:
> [c000001fed5b3bf0] [c000000000a0ef3c] dump_stack+0xb0/0xf4 (unreliable)
> [c000001fed5b3c30] [c0000000000f9d68] panic+0x140/0x308
> [c000001fed5b3cc0] [c0000000000f9844] __stack_chk_fail+0x24/0x30
> [c000001fed5b3d20] [c000000000a2c3a8] __schedule+0x978/0xa80
> [c000001fed5b3e00] [c000000000a2c9b4] schedule_idle+0x34/0x60
> [c000001fed5b3e30] [c00000000013d344] do_idle+0x224/0x3d0
> [c000001fed5b3ec0] [c00000000013d6e0] cpu_startup_entry+0x30/0x50
> [c000001fed5b3ef0] [c000000000047f34] start_secondary+0x4d4/0x520
> [c000001fed5b3f90] [c00000000000b370] start_secondary_prolog+0x10/0x14
>
> This patch properly initialises the stack_canary of the secondary
> idle tasks.
>
> Reported-by: Abdul Haleem <abdhalee@linux.vnet.ibm.com>
> Fixes: 06ec27aea9fc ("powerpc/64: add stack protector support")
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/7241d26e8175e95290a6549a470c33
cheers
^ permalink raw reply
* Re: powerpc: Fix stackprotector detection for non-glibc toolchains
From: Michael Ellerman @ 2018-10-15 4:01 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev
In-Reply-To: <20181012225832.13827-1-mpe@ellerman.id.au>
On Fri, 2018-10-12 at 22:58:32 UTC, Michael Ellerman wrote:
> If GCC is not built with glibc support then we must explicitly tell it
> which register to use for TLS mode stack protector, otherwise it will
> error out and the cc-option check will fail.
>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
> Reviewed-by: Christophe Leroy <christophe.leroy@c-s.fr>
Applied to powerpc next.
https://git.kernel.org/powerpc/c/bf6cbd0c87f30d0e4401be91a8161c
cheers
^ permalink raw reply
* Re: powerpc: Use SWITCH_FRAME_SIZE for prom and rtas entry
From: Michael Ellerman @ 2018-10-15 4:01 UTC (permalink / raw)
To: Joel Stanley, linuxppc-dev
In-Reply-To: <20181012024406.20658-1-joel@jms.id.au>
On Fri, 2018-10-12 at 02:44:06 UTC, Joel Stanley wrote:
> Commit 6c1719942e19 ("powerpc/of: Remove useless register save/restore
> when calling OF back") removed the saving of srr0 and srr1 when calling
> into OpenFirmware. Commit e31aa453bbc4 ("powerpc: Use LOAD_REG_IMMEDIATE
> only for constants on 64-bit") did the same for rtas.
>
> This means we don't need to save the extra stack space and can use
> the common SWITCH_FRAME_SIZE.
>
> There were already no users of _SRR0 and _SRR1 so we can remove them
> too.
>
> Link: https://github.com/linuxppc/linux/issues/83
> Signed-off-by: Joel Stanley <joel@jms.id.au>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/ed9e84a4d703243a232e6549a13ded
cheers
^ permalink raw reply
* Re: [v10, 1/3] powerpc: Detect the presence of big-cores via "ibm, thread-groups"
From: Michael Ellerman @ 2018-10-15 4:01 UTC (permalink / raw)
To: Gautham R. Shenoy, Dave Hansen, Aneesh Kumar K.V,
Srikar Dronamraju, Benjamin Herrenschmidt, Michael Neuling,
Vaidyanathan Srinivasan, Akshay Adiga, Shilpasri G Bhat,
Oliver O'Halloran, Nicholas Piggin, Murilo Opsfelder Araujo,
Anton Blanchard
Cc: Gautham R. Shenoy, linuxppc-dev, linux-kernel
In-Reply-To: <1539235983-25259-2-git-send-email-ego@linux.vnet.ibm.com>
On Thu, 2018-10-11 at 05:33:01 UTC, "Gautham R. Shenoy" wrote:
> From: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>
>
> On IBM POWER9, the device tree exposes a property array identifed by
> "ibm,thread-groups" which will indicate which groups of threads share
> a particular set of resources.
>
> As of today we only have one form of grouping identifying the group of
> threads in the core that share the L1 cache, translation cache and
> instruction data flow.
>
> This patch adds helper functions to parse the contents of
> "ibm,thread-groups" and populate a per-cpu variable to cache
> information about siblings of each CPU that share the L1, traslation
> cache and instruction data-flow.
>
> It also defines a new global variable named "has_big_cores" which
> indicates if the cores on this configuration have multiple groups of
> threads that share L1 cache.
>
> For each online CPU, it maintains a cpu_smallcore_mask, which
> indicates the online siblings which share the L1-cache with it.
>
> Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/425752c63b6f3fed7b5a9cba2b8101
cheers
^ permalink raw reply
* Re: [v3] powerpc/Makefile: Fix PPC_BOOK3S_64 ASFLAGS
From: Michael Ellerman @ 2018-10-15 4:01 UTC (permalink / raw)
To: Joel Stanley, linuxppc-dev; +Cc: Nick Desaulniers, Nicholas Piggin
In-Reply-To: <20181011024303.23921-1-joel@jms.id.au>
On Thu, 2018-10-11 at 02:43:03 UTC, Joel Stanley wrote:
> Ever since commit 15a3204d24a3 ("powerpc/64s: Set assembler machine type
> to POWER4") we force -mpower4 to be passed to the assembler irrespective
> of the CFLAGS used.
>
> When building a powerpc64 kernel with clang, clang will not add -many to
> the assembler flags, so any instructions that the compiler has generated
> that are not available on power4 will cause an error:
>
> /usr/bin/as -a64 -mppc64 -mlittle-endian -mpower8 \
> -I ./arch/powerpc/include -I ./arch/powerpc/include/generated \
> -I ./include -I ./arch/powerpc/include/uapi \
> -I ./arch/powerpc/include/generated/uapi -I ./include/uapi \
> -I ./include/generated/uapi -I arch/powerpc -I arch/powerpc \
> -maltivec -mpower4 -o init/do_mounts.o /tmp/do_mounts-3b0a3d.s
> /tmp/do_mounts-51ce54.s:748: Error: unrecognized opcode: `isel'
>
> GCC does include -many, so the GCC driven gas call will succeed:
>
> as -v -I ./arch/powerpc/include -I ./arch/powerpc/include/generated -I
> ./include -I ./arch/powerpc/include/uapi
> -I ./arch/powerpc/include/generated/uapi -I ./include/uapi
> -I ./include/generated/uapi -I arch/powerpc -I arch/powerpc
> -a64 -mpower8 -many -mlittle -maltivec -mpower4 -o init/do_mounts.o
>
> Note that isel is power7 and above for IBM CPUs. GCC only generates it
> for Power9 and above, but the above test was run against the clang
> generated assembly.
>
> Peter Bergner explains:
>
> > When using -many -mpower4, gas will first try and find a matching
> > power4 mnemonic and failing that, it will then allow any valid mnemonic
> > that gas knows about. GCC's use of -many predates me though.
> >
> > IIRC, Alan looked at trying to remove it, but I forget why he didn't.
> > Could be either a gcc or gas issue at the time. I'm not sure whether
> > issue still exists or not. He and I have modified how gas works
> > internally a fair amount since he tried removing gcc use of -many
> >
> > I will also note that when using -many, gas will choose the first
> > mnemonic that matches in the mnemonic table and we have (mostly) sorted
> > the table so that server mnemonics show up earlier in the table than
> > other mnemonics, so they'll be seen/chosen first
>
> By explicitly setting -many we can build with Clang and GCC while
> retaining the -mpower4 option.
>
> Signed-off-by: Joel Stanley <joel@jms.id.au>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/960e30029863db95ec79a71009272d
cheers
^ permalink raw reply
* Re: [1/2] powerpc/boot: Expose Kconfig symbols to wrapper
From: Michael Ellerman @ 2018-10-15 4:01 UTC (permalink / raw)
To: Joel Stanley, linuxppc-dev; +Cc: Oliver O'Halloran
In-Reply-To: <20181009232803.15072-2-joel@jms.id.au>
On Tue, 2018-10-09 at 23:28:02 UTC, Joel Stanley wrote:
> Currently the wrapper is built without including anything in
> $(src)/include/, which means there are no CONFIG_ symbols defined. This
> means the platform specific serial drivers were never enabled.
>
> We now copy the definitions into the boot directory, so any C file can
> now include autoconf.h to depend on configuration options.
>
> Fixes: 866bfc75f40e ("powerpc: conditionally compile platform-specific serial drivers")
> Signed-off-by: Joel Stanley <joel@jms.id.au>
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/5e9dcb6188a40e604e66dc30fab30c
cheers
^ permalink raw reply
* Re: powerpc/rtasd: Improve unknown error logging
From: Michael Ellerman @ 2018-10-15 4:01 UTC (permalink / raw)
To: Oliver O'Halloran, linuxppc-dev; +Cc: Oliver O'Halloran
In-Reply-To: <20181010052302.18094-1-oohall@gmail.com>
On Wed, 2018-10-10 at 05:23:02 UTC, Oliver O'Halloran wrote:
> Currently when we get an unknown RTAS event it prints the type as
> "Unknown" and no other useful information. Add the raw type code to the
> log message so that we have something to work off.
>
> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
> Reviewed-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/b27e5f939b6d50e1b83e9febfee1c3
cheers
^ permalink raw reply
* Re: [1/2] powerpc/boot: Disable vector instructions
From: Michael Ellerman @ 2018-10-15 4:01 UTC (permalink / raw)
To: Joel Stanley, linuxppc-dev; +Cc: Oliver O'Halloran
In-Reply-To: <20181010024523.4921-2-joel@jms.id.au>
On Wed, 2018-10-10 at 02:45:22 UTC, Joel Stanley wrote:
> This will avoid auto-vectorisation when building with higher
> optimisation levels.
>
> We don't know if the machine can support VSX and even if it's present
> it's probably not going to be enabled at this point in boot.
>
> Signed-off-by: Joel Stanley <joel@jms.id.au>
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/e8e132e6885962582784b6fa16a80d
cheers
^ permalink raw reply
* Re: powerpc: remove redundant 'default n' from Kconfig-s
From: Michael Ellerman @ 2018-10-15 4:01 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz, Benjamin Herrenschmidt, Paul Mackerras
Cc: Geoff Levand, Alistair Popple, linuxppc-dev, linux-kernel,
Arnd Bergmann
In-Reply-To: <20181009153948eucas1p14ad8b13d2482dbb9449888d544ddee15~b_uvNkTH03130331303eucas1p1E@eucas1p1.samsung.com>
On Tue, 2018-10-09 at 15:39:46 UTC, Bartlomiej Zolnierkiewicz wrote:
> 'default n' is the default value for any bool or tristate Kconfig
> setting so there is no need to write it explicitly.
>
> Also since commit f467c5640c29 ("kconfig: only write '# CONFIG_FOO
> is not set' for visible symbols") the Kconfig behavior is the same
> regardless of 'default n' being present or not:
>
> ...
> One side effect of (and the main motivation for) this change is making
> the following two definitions behave exactly the same:
>
> config FOO
> bool
>
> config FOO
> bool
> default n
>
> With this change, neither of these will generate a
> '# CONFIG_FOO is not set' line (assuming FOO isn't selected/implied).
> That might make it clearer to people that a bare 'default n' is
> redundant.
> ...
>
> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/719736e1cc12b2fc28eba2122893a4
cheers
^ permalink raw reply
* Re: [v02] powerpc/mobility: Extend start/stop topology update scope
From: Michael Ellerman @ 2018-10-15 4:01 UTC (permalink / raw)
To: Michael Bringmann, linuxppc-dev, mwb
Cc: Nathan Fontenot, Juliet Kim, Thomas Falcon, Tyrel Datwyler
In-Reply-To: <20181009195504.22636.20595.stgit@ltcalpine2-lp9.aus.stglabs.ibm.com>
On Tue, 2018-10-09 at 20:12:14 UTC, Michael Bringmann wrote:
> The PPC mobility code may receive RTAS requests to perform PRRN
> topology changes at any time, including during LPAR migration
> operations. In some configurations where the affinity of CPUs
> or memory is being changed on that platform, the PRRN requests
> may apply or refer to outdated information prior to the complete
> update of the device-tree. This patch changes the duration for
> which topology updates are suppressed during LPAR migrations from
> just the rtas_ibm_suspend_me / 'ibm,suspend-me' call(s) to cover
> the entire 'migration_store' operation to allow all changes to
> the device-tree to be applied prior to accepting and applying any
> PRRN requests.
>
> For tracking purposes, pr_info notices are added to the functions
> start_topology_update() and stop_topology_update() of 'numa.c'.
>
> Signed-off-by: Michael Bringmann <mwb@linux.vnet.ibm.com>
> Reviewed-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/65b9fdadfc4d87e2577b791fb3495c
cheers
^ permalink raw reply
* Re: [v3, -next] powerpc/pseries/memory-hotplug: Fix return value type of find_aa_index
From: Michael Ellerman @ 2018-10-15 4:01 UTC (permalink / raw)
To: YueHaibing, benh, paulus, nfont; +Cc: linuxppc-dev, YueHaibing, linux-kernel
In-Reply-To: <20181009135913.14616-1-yuehaibing@huawei.com>
On Tue, 2018-10-09 at 13:59:13 UTC, YueHaibing wrote:
> 'aa_index' is defined as an unsigned value, but find_aa_index
> may return -1 when dlpar_clone_property fails. So change
> find_aa_index return value type to bool, which indicate 'aa_index'
> whether found or not.
>
> Fixes: c05a5a40969e ("powerpc/pseries: Dynamic add entires to associativity lookup array")
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> Reviewed-by: Nathan Fontenot nfont@linux.vnet.ibm.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/b45e9d761ba2d60044b610297e3ef9
cheers
^ permalink raw reply
* Re: [v3,01/24] powerpc/32: Add ioremap_wt() and ioremap_coherent()
From: Michael Ellerman @ 2018-10-15 4:01 UTC (permalink / raw)
To: Christophe Leroy, Bartlomiej Zolnierkiewicz,
Benjamin Herrenschmidt, Dominik Brodowski, Geoff Levand,
Jens Axboe, Kumar Gala, Li Yang, Nicholas Piggin, Paul Mackerras,
Scott Wood, aneesh.kumar
Cc: linux-fbdev, linux-kernel, dri-devel, linux-block, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <c454a5dbb215719991e3b0e6470309101d870fbb.1539092111.git.christophe.leroy@c-s.fr>
On Tue, 2018-10-09 at 13:51:33 UTC, Christophe Leroy wrote:
> Other arches have ioremap_wt() to map IO areas write-through.
> Implement it on PPC as well in order to avoid drivers using
> __ioremap(_PAGE_WRITETHRU)
>
> Also implement ioremap_coherent() to avoid drivers using
> __ioremap(_PAGE_COHERENT)
>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/86c391bd5f47101acf1f3e0abd9fe0
cheers
^ permalink raw reply
* Re: [v2] powerpc/perf: Quiet IMC PMU registration message
From: Michael Ellerman @ 2018-10-15 4:01 UTC (permalink / raw)
To: Joel Stanley, Madhavan Srinivasan; +Cc: linuxppc-dev
In-Reply-To: <20181009062038.29695-1-joel@jms.id.au>
On Tue, 2018-10-09 at 06:20:38 UTC, Joel Stanley wrote:
> On a Power9 box we get a few screens full of these on boot. Drop
> them to pr_debug.
>
> [ 5.993645] nest_centaur6_imc performance monitor hardware support registered
> [ 5.993728] nest_centaur7_imc performance monitor hardware support registered
> [ 5.996510] core_imc performance monitor hardware support registered
> [ 5.996569] nest_mba0_imc performance monitor hardware support registered
> [ 5.996631] nest_mba1_imc performance monitor hardware support registered
> [ 5.996685] nest_mba2_imc performance monitor hardware support registered
>
> Signed-off-by: Joel Stanley <joel@jms.id.au>
> Reviewed-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/6233b6da0c00a9768bdab1c502115b
cheers
^ permalink raw reply
* Re: [v4,1/3] powerpc/process: fix casting and missing header
From: Michael Ellerman @ 2018-10-15 4:01 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras, muriloo
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <981244f0ffb38c1aa02c9eb831c7ebf479b8f564.1538789120.git.christophe.leroy@c-s.fr>
On Sat, 2018-10-06 at 16:51:12 UTC, Christophe Leroy wrote:
> This patch fixes the following warnings. The first ones are leftovers
> from when __get_user() was replaced by probe_kernel_address().
>
> The last one is from when show_user_instructions() was added.
>
> arch/powerpc/kernel/process.c:1287:22: warning: incorrect type in argument 2 (different address spaces)
> arch/powerpc/kernel/process.c:1287:22: expected void const *src
> arch/powerpc/kernel/process.c:1287:22: got unsigned int [noderef] <asn:1>*<noident>
> arch/powerpc/kernel/process.c:1319:21: warning: incorrect type in argument 2 (different address spaces)
> arch/powerpc/kernel/process.c:1319:21: expected void const *src
> arch/powerpc/kernel/process.c:1319:21: got unsigned int [noderef] <asn:1>*<noident>
> arch/powerpc/kernel/process.c:1302:6: warning: symbol 'show_user_instructions' was not declared. Should it be static?
>
> Fixes: 7b051f665c32d ("powerpc: Use probe_kernel_address in show_instructions")
> Fixes: 88b0fe1757359 ("powerpc: Add show_user_instructions()")
> Reviewed-by: Murilo Opsfelder Araujo <muriloo@linux.ibm.com>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/3b35bd48b8a06e02a25af84baba782
cheers
^ permalink raw reply
* Re: powerpc: signedness bug in update_flash_db()
From: Michael Ellerman @ 2018-10-15 4:01 UTC (permalink / raw)
To: Dan Carpenter, Geoff Levand, Geert Uytterhoeven
Cc: Paul Mackerras, kernel-janitors, linuxppc-dev
In-Reply-To: <20181001164458.GB29197@mwanda>
On Mon, 2018-10-01 at 16:44:58 UTC, Dan Carpenter wrote:
> The "count < sizeof(struct os_area_db)" comparison is type promoted to
> size_t so negative values of "count" are treated as very high values and
> we accidentally return success instead of a negative error code.
>
> This doesn't really change runtime much but it fixes a static checker
> warning.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> Acked-by: Geoff Levand <geoff@infradead.org>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/014704e6f54189a203cc14c7c0bb41
cheers
^ permalink raw reply
* Re: [v2] powerpc/rtas: Fix a potential race between CPU-Offline & Migration
From: Michael Ellerman @ 2018-10-15 4:01 UTC (permalink / raw)
To: Gautham R. Shenoy, Nathan Fontenot, Tyrel Datwyler
Cc: Gautham R. Shenoy, linuxppc-dev
In-Reply-To: <1538390439-17072-1-git-send-email-ego@linux.vnet.ibm.com>
On Mon, 2018-10-01 at 10:40:39 UTC, "Gautham R. Shenoy" wrote:
> From: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>
>
> Live Partition Migrations require all the present CPUs to execute the
> H_JOIN call, and hence rtas_ibm_suspend_me() onlines any offline CPUs
> before initiating the migration for this purpose.
>
> The commit 85a88cabad57
> ("powerpc/pseries: Disable CPU hotplug across migrations")
> disables any CPU-hotplug operations once all the offline CPUs are
> brought online to prevent any further state change. Once the
> CPU-Hotplug operation is disabled, the code assumes that all the CPUs
> are online.
>
> However, there is a minor window in rtas_ibm_suspend_me() between
> onlining the offline CPUs and disabling CPU-Hotplug when a concurrent
> CPU-offline operations initiated by the userspace can succeed thereby
> nullifying the the aformentioned assumption. In this unlikely case
> these offlined CPUs will not call H_JOIN, resulting in a system hang.
>
> Fix this by verifying that all the present CPUs are actually online
> after CPU-Hotplug has been disabled, failing which we restore the
> state of the offline CPUs in rtas_ibm_suspend_me() and return an
> -EBUSY.
>
> Cc: Nathan Fontenot <nfont@linux.vnet.ibm.com>
> Cc: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
> Suggested-by: Michael Ellerman <mpe@ellerman.id.au>
> Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
> Reviewed-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/dfd718a2ed1f678e66749ffe41bdea
cheers
^ permalink raw reply
* Re: [V2, 1/2] powerpc/mm/hash: Rename get_ea_context to get_user_context
From: Michael Ellerman @ 2018-10-15 4:01 UTC (permalink / raw)
To: Aneesh Kumar K.V, npiggin, benh, paulus; +Cc: Aneesh Kumar K.V, linuxppc-dev
In-Reply-To: <20180920083358.2359-1-aneesh.kumar@linux.ibm.com>
On Thu, 2018-09-20 at 08:33:57 UTC, "Aneesh Kumar K.V" wrote:
> We will be adding get_kernel_context later. Update function name to indicate
> this handle context allocation user space address.
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/c9f80734cd552ddba50567bc43b0ff
cheers
^ permalink raw reply
* Re: powerpc: Disable -Wbuiltin-requires-header when setjmp is used
From: Michael Ellerman @ 2018-10-15 4:01 UTC (permalink / raw)
To: Joel Stanley, linuxppc-dev; +Cc: Nick Desaulniers
In-Reply-To: <20180917074621.25066-1-joel@jms.id.au>
On Mon, 2018-09-17 at 07:46:21 UTC, Joel Stanley wrote:
> The powerpc kernel uses setjmp which causes a warning when building with
> clang:
>
> CC arch/powerpc/xmon/xmon.o
> In file included from arch/powerpc/xmon/xmon.c:51:
> ./arch/powerpc/include/asm/setjmp.h:15:13: error: declaration of
> built-in function 'setjmp' requires inclusion of the header <setjmp.h>
> [-Werror,-Wbuiltin-requires-header]
> extern long setjmp(long *);
> ^
> ./arch/powerpc/include/asm/setjmp.h:16:13: error: declaration of
> built-in function 'longjmp' requires inclusion of the header <setjmp.h>
> [-Werror,-Wbuiltin-requires-header]
> extern void longjmp(long *, long);
> ^
>
> This *is* the header and we're not using the built-in setjump but
> rather the one in arch/powerpc/kernel/misc.S. As the compiler warning
> does not make sense, it for the files where setjmp is used.
>
> Signed-off-by: Joel Stanley <joel@jms.id.au>
> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/aea447141c7e7824b81b49acd1bc78
cheers
^ permalink raw reply
* Re: [01/14] powerpc/eeh: Fix possible null deref in eeh_dump_dev_log()
From: Michael Ellerman @ 2018-10-15 4:00 UTC (permalink / raw)
To: Sam Bobroff, linuxppc-dev
In-Reply-To: <58b57fd67e045f7700b5a91b4f0f80089bca391e.1536715396.git.sbobroff@linux.ibm.com>
On Wed, 2018-09-12 at 01:23:20 UTC, Sam Bobroff wrote:
> If an error occurs during an unplug operation, it's possible for
> eeh_dump_dev_log() to be called when edev->pdn is null, which
> currently leads to dereferencing a null pointer.
>
> Handle this by skipping the error log for those devices.
>
> Signed-off-by: Sam Bobroff <sbobroff@linux.ibm.com>
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/f9bc28aedfb5bbd572d2d365f3095c
cheers
^ permalink raw reply
* Re: [1/7] macintosh: Use common code to access RTC
From: Michael Ellerman @ 2018-10-15 4:00 UTC (permalink / raw)
To: Finn Thain, Benjamin Herrenschmidt, Paul Mackerras
Cc: linuxppc-dev, linux-m68k, Geert Uytterhoeven, linux-kernel,
Arnd Bergmann
In-Reply-To: <7a0748d8cd97964a99879a0b9f1c0243c677c7c3.1536709753.git.fthain@telegraphics.com.au>
On Wed, 2018-09-12 at 00:18:44 UTC, Finn Thain wrote:
> Now that the 68k Mac port has adopted the via-pmu driver, the same RTC
> code can be shared between m68k and powerpc. Replace duplicated code in
> arch/powerpc and arch/m68k with common RTC accessors for Cuda and PMU.
>
> Drop the problematic WARN_ON which was introduced in commit 22db552b50fa
> ("powerpc/powermac: Fix rtc read/write functions").
>
> Tested-by: Stan Johnson <userm57@yahoo.com>
> Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
> Cc: Geert Uytterhoeven <geert@linux-m68k.org>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/0792a2c8e0bbda3605b8d42c6b9635
cheers
^ permalink raw reply
* Re: [1/2] powerpc/64s/hash: do not use PPC_INVALIDATE_ERAT on CPUs before POWER9
From: Michael Ellerman @ 2018-10-15 4:00 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev; +Cc: Nicholas Piggin
In-Reply-To: <20180827030302.17541-2-npiggin@gmail.com>
On Mon, 2018-08-27 at 03:03:01 UTC, Nicholas Piggin wrote:
> PPC_INVALIDATE_ERAT is slbia IH=7 which is a new variant introduced
> with POWER9, and the result is undefined on earlier CPUs.
>
> Commits 7b9f71f974 ("powerpc/64s: POWER9 machine check handler") and
> d4748276ae ("powerpc/64s: Improve local TLB flush for boot and MCE on
> POWER9") caused POWER7/8 code to use this instruction. Remove it. An
> ERAT flush can be made by invalidatig the SLB, but before POWER9 that
> requires a flush and rebolt.
>
> Fixes: 7b9f71f974 ("powerpc/64s: POWER9 machine check handler")
> Fixes: d4748276ae ("powerpc/64s: Improve local TLB flush for boot and
> MCE on POWER9")
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/bc276ecba132caccb1fda5863a652c
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