* Re: [11/21] powerpc: Add missing prototype for hdec_interrupt
From: Michael Ellerman @ 2018-03-14 9:27 UTC (permalink / raw)
To: Mathieu Malaterre
Cc: Mathieu Malaterre, linux-kernel, Paul Mackerras, Jiri Slaby,
linuxppc-dev
In-Reply-To: <20180225172236.29650-12-malat@debian.org>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 701 bytes --]
On Sun, 2018-02-25 at 17:22:26 UTC, Mathieu Malaterre wrote:
> In commit dabe859ec636 ("powerpc: Give hypervisor decrementer interrupts
> their own handler") an empty body function was added, but no prototype was
> declared. Fix warning (treated as error in W=1):
>
> CC arch/powerpc/kernel/time.o
> arch/powerpc/kernel/time.c:629:6: error: no previous prototype for ‘hdec_interrupt’ [-Werror=missing-prototypes]
> void hdec_interrupt(struct pt_regs *regs)
> ^~~~~~~~~~~~~~
> cc1: all warnings being treated as errors
>
> Signed-off-by: Mathieu Malaterre <malat@debian.org>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/8b604faff7d421904ebd1fa65d642f
cheers
^ permalink raw reply
* Re: [10/21] powerpc: Add missing prototype for slb_miss_bad_addr
From: Michael Ellerman @ 2018-03-14 9:27 UTC (permalink / raw)
To: Mathieu Malaterre
Cc: Mathieu Malaterre, linux-kernel, Paul Mackerras, Jiri Slaby,
linuxppc-dev
In-Reply-To: <20180225172236.29650-11-malat@debian.org>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 751 bytes --]
On Sun, 2018-02-25 at 17:22:25 UTC, Mathieu Malaterre wrote:
> In commit f0f558b131db ("powerpc/mm: Preserve CFAR value on SLB miss caused
> by access to bogus address"), the function slb_miss_bad_addr was added
> without a prototype. This commit adds it.
>
> Fix a warning (treated as error in W=1):
>
> CC arch/powerpc/kernel/traps.o
> arch/powerpc/kernel/traps.c:1498:6: error: no previous prototype for ‘slb_miss_bad_addr’ [-Werror=missing-prototypes]
> void slb_miss_bad_addr(struct pt_regs *regs)
> ^~~~~~~~~~~~~~~~~
> cc1: all warnings being treated as errors
>
> Signed-off-by: Mathieu Malaterre <malat@debian.org>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/45b4d27a3897d6094bcf84bc877439
cheers
^ permalink raw reply
* Re: [07/21] powerpc: Make functions flipper_pic_init & ug_udbg_putc static
From: Michael Ellerman @ 2018-03-14 9:27 UTC (permalink / raw)
To: Mathieu Malaterre
Cc: Mathieu Malaterre, linux-kernel, Paul Mackerras, Jiri Slaby,
linuxppc-dev
In-Reply-To: <20180225172236.29650-8-malat@debian.org>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 997 bytes --]
On Sun, 2018-02-25 at 17:22:22 UTC, Mathieu Malaterre wrote:
> Change signature of two functions, adding static keyword to prevent the
> following two warnings (treated as errors on W=1):
>
> CC kernel/sys.o
> arch/powerpc/platforms/embedded6xx/flipper-pic.c:135:28: error: no previous prototype for ‘flipper_pic_init’ [-Werror=missing-prototypes]
> struct irq_domain * __init flipper_pic_init(struct device_node *np)
> ^~~~~~~~~~~~~~~~
> cc1: all warnings being treated as errors
>
> and
>
> CC arch/powerpc/platforms/embedded6xx/usbgecko_udbg.o
> arch/powerpc/platforms/embedded6xx/usbgecko_udbg.c:172:6: error: no previous prototype for ‘ug_udbg_putc’ [-Werror=missing-prototypes]
> void ug_udbg_putc(char ch)
> ^~~~~~~~~~~~
> cc1: all warnings being treated as errors
>
> Signed-off-by: Mathieu Malaterre <malat@debian.org>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/8b51e679a54e808bdf1f2cc6552cf2
cheers
^ permalink raw reply
* Re: [04/21] powerpc: Mark both tmp variables as unused
From: Michael Ellerman @ 2018-03-14 9:27 UTC (permalink / raw)
To: Mathieu Malaterre
Cc: Mathieu Malaterre, linux-kernel, Paul Mackerras, Jiri Slaby,
linuxppc-dev
In-Reply-To: <20180225172236.29650-5-malat@debian.org>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 929 bytes --]
On Sun, 2018-02-25 at 17:22:19 UTC, Mathieu Malaterre wrote:
> Since the value of `tmp` is never intended to be read, declare both `tmp`
> variables as unused. Fix warning (treated as error in W=1):
>
> CC arch/powerpc/kernel/signal_32.o
> arch/powerpc/kernel/signal_32.c: In function ‘sys_swapcontext’:
> arch/powerpc/kernel/signal_32.c:1048:16: error: variable ‘tmp’ set but not used [-Werror=unused-but-set-variable]
> unsigned char tmp;
> ^~~
> arch/powerpc/kernel/signal_32.c: In function ‘sys_debug_setcontext’:
> arch/powerpc/kernel/signal_32.c:1234:16: error: variable ‘tmp’ set but not used [-Werror=unused-but-set-variable]
> unsigned char tmp;
> ^~~
> cc1: all warnings being treated as errors
>
> Signed-off-by: Mathieu Malaterre <malat@debian.org>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/67b464a89c21c9edd45ad15c457bb5
cheers
^ permalink raw reply
* Re: [02/21] powerpc: Move the inline keyword at the beginning of function declaration
From: Michael Ellerman @ 2018-03-14 9:27 UTC (permalink / raw)
To: Mathieu Malaterre
Cc: Mathieu Malaterre, linux-kernel, Paul Mackerras, Jiri Slaby,
linuxppc-dev
In-Reply-To: <20180225172236.29650-3-malat@debian.org>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 844 bytes --]
On Sun, 2018-02-25 at 17:22:17 UTC, Mathieu Malaterre wrote:
> The inline keyword was not at the beginning of the function declaration.
> Fix the following warning (treated as error in W=1)
>
> CC kernel/sys.o
> arch/powerpc/lib/sstep.c:283:1: error: ‘inline’ is not at beginning of declaration [-Werror=old-style-declaration]
> static int nokprobe_inline copy_mem_in(u8 *dest, unsigned long ea, int nb,
> ^~~~~~
> arch/powerpc/lib/sstep.c:388:1: error: ‘inline’ is not at beginning of declaration [-Werror=old-style-declaration]
> static int nokprobe_inline copy_mem_out(u8 *dest, unsigned long ea, int nb,
> ^~~~~~
> CC arch/powerpc/kernel/setup_32.o
>
> Signed-off-by: Mathieu Malaterre <malat@debian.org>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/174b701d3dcd14514f869e2bc08ac4
cheers
^ permalink raw reply
* Re: [v2] cxl: Check if PSL data-cache is available before issue flush request
From: Michael Ellerman @ 2018-03-14 9:27 UTC (permalink / raw)
To: Vaibhav Jain, linuxppc-dev, Frederic Barrat
Cc: Philippe Bergheaud, Alastair D'Silva, Vaibhav Jain,
Andrew Donnellan, Christophe Lombard
In-Reply-To: <20180215154924.22005-1-vaibhav@linux.vnet.ibm.com>
On Thu, 2018-02-15 at 15:49:24 UTC, Vaibhav Jain wrote:
> PSL9D doesn't have a data-cache that needs to be flushed before
> resetting the card. However when cxl tries to flush data-cache on such
> a card, it times-out as PSL_Control register never indicates flush
> operation complete due to missing data-cache. This is usually
> indicated in the kernel logs with this message:
>
> "WARNING: cache flush timed out"
>
> To fix this the patch checks PSL_Debug register CDC-Field(BIT:27)
> which indicates the absence of a data-cache and sets a flag
> 'no_data_cache' in 'struct cxl_native' to indicate this. When
> cxl_data_cache_flush() is called it checks the flag and if set bails
> out early without requesting a data-cache flush operation to the PSL.
>
> Signed-off-by: Vaibhav Jain <vaibhav@linux.vnet.ibm.com>
> Acked-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
> Acked-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/94322ed8e857e3b2a33cf75118051a
cheers
^ permalink raw reply
* Re: [v2] cxl: Remove function write_timebase_ctrl_psl9() for PSL9
From: Michael Ellerman @ 2018-03-14 9:27 UTC (permalink / raw)
To: Vaibhav Jain, Frederic Barrat, Andrew Donnellan,
Christophe Lombard
Cc: Philippe Bergheaud, Alastair D'Silva, linuxppc-dev,
Vaibhav Jain
In-Reply-To: <20180215061936.27131-1-vaibhav@linux.vnet.ibm.com>
On Thu, 2018-02-15 at 06:19:36 UTC, Vaibhav Jain wrote:
> For PSL9 the contents of PSL_TB_CTLSTAT register have changed in PSL9
> and all of the register is now readonly. Hence we don't need an sl_ops
> implementation for 'write_timebase_ctrl' for to populate this register
> for PSL9.
>
> Hence this patch removes function write_timebase_ctrl_psl9() and its
> references from the code.
>
> Signed-off-by: Vaibhav Jain <vaibhav@linux.vnet.ibm.com>
> Acked-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
> Acked-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/02b63b420223db3e33e19cc0aaf346
cheers
^ permalink raw reply
* Re: [v2] powerpc/via-pmu: Fix section mismatch warning
From: Michael Ellerman @ 2018-03-14 9:27 UTC (permalink / raw)
To: Mathieu Malaterre
Cc: Laurent Vivier, Mathieu Malaterre, linuxppc-dev, linux-kernel
In-Reply-To: <20180214211519.15683-1-malat@debian.org>
On Wed, 2018-02-14 at 21:15:18 UTC, Mathieu Malaterre wrote:
> Make the struct via_pmu_driver const to avoid following warning:
>
> WARNING: vmlinux.o(.data+0x4739c): Section mismatch in reference from the variable via_pmu_driver to the function .init.text:pmu_init()
> The variable via_pmu_driver references
> the function __init pmu_init()
> If the reference is valid then annotate the
> variable with __init* or __refdata (see linux/init.h) or name the variable:
> *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console
>
> Signed-off-by: Mathieu Malaterre <malat@debian.org>
> Suggested-by: Laurent Vivier <lvivier@redhat.com>
> Reviewed-by: Laurent Vivier <lvivier@redhat.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/58935176ad17976b7a7f6ea25c0ceb
cheers
^ permalink raw reply
* Re: cxl: Enable NORST bit in PSL_DEBUG register for PSL9
From: Michael Ellerman @ 2018-03-14 9:27 UTC (permalink / raw)
To: Vaibhav Jain, linuxppc-dev, Frederic Barrat
Cc: Philippe Bergheaud, Alastair D'Silva, Vaibhav Jain,
Andrew Donnellan, Christophe Lombard
In-Reply-To: <20180209040916.14250-1-vaibhav@linux.vnet.ibm.com>
On Fri, 2018-02-09 at 04:09:16 UTC, Vaibhav Jain wrote:
> We enable the NORST bit by default for debug afu images to prevent
> reset of AFU trace-data on a PCI link drop. For production AFU images
> this bit is always ignored and PSL gets reconfigured anyways thereby
> resetting the trace data. So setting this bit for non-debug images
> doesn't have any impact.
>
> Signed-off-by: Vaibhav Jain <vaibhav@linux.vnet.ibm.com>
> Reviewed-by: Christophe Lombard <clombard@linux.vnet.ibm.com>
> Acked-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
> Acked-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/03ebb419b896e0fb2da3f34b57d45e
cheers
^ permalink raw reply
* Re: powerpc/epapr: Move register keyword at the beginning of declaration
From: Michael Ellerman @ 2018-03-14 9:27 UTC (permalink / raw)
To: Mathieu Malaterre
Cc: Mathieu Malaterre, linux-kernel, Seth Forshee, Paul Mackerras,
linuxppc-dev
In-Reply-To: <20180131075445.9292-1-malat@debian.org>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 503 bytes --]
On Wed, 2018-01-31 at 07:54:43 UTC, Mathieu Malaterre wrote:
> Fix warning for all register unsigned long (0,3-12) that appear during W=1
> compilation:
>
> ./arch/powerpc/include/asm/epapr_hcalls.h:479:2: warning: ‘register’ is not at beginning of declaration [-Wold-style-declaration]
> unsigned long register r[\d] asm("r[\d]");
>
> Signed-off-by: Mathieu Malaterre <malat@debian.org>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/65e13c202d7826dc3497c32961008d
cheers
^ permalink raw reply
* Re: [v2] macintosh: Add module license to ans-lcd
From: Michael Ellerman @ 2018-03-14 9:27 UTC (permalink / raw)
To: Larry Finger, Benjamin Herrenschmidt
Cc: linuxppc-dev, linux-kernel, Larry Finger
In-Reply-To: <20180130142351.23511-1-Larry.Finger@lwfinger.net>
On Tue, 2018-01-30 at 14:23:51 UTC, Larry Finger wrote:
> In kernel 4.15, the modprobe step on my PowerBook G4 started complaining that
> there was no module license for ans-lcd.
>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/47d703e1d55f068c737c0c9f0c18f0
cheers
^ permalink raw reply
* Re: [1/5] powerpc/vas: Remove a stray line in Makefile
From: Michael Ellerman @ 2018-03-14 9:27 UTC (permalink / raw)
To: Sukadev Bhattiprolu; +Cc: linuxppc-dev, mikey, linux-kernel
In-Reply-To: <1516157443-17716-2-git-send-email-sukadev@linux.vnet.ibm.com>
On Wed, 2018-01-17 at 02:50:39 UTC, Sukadev Bhattiprolu wrote:
> Remove a bogus line from arch/powerpc/platforms/powernv/Makefile that
> was added by commit ece4e51 ("powerpc/vas: Export HVWC to debugfs").
>
> Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/2f65272a2a304ec6aa32ad9a45b150
cheers
^ permalink raw reply
* Re: [1/1] vas: vas_window_init_dbgdir: fix order of cleanup.
From: Michael Ellerman @ 2018-03-14 9:27 UTC (permalink / raw)
To: Sukadev Bhattiprolu; +Cc: mikey, linux-kernel, linuxppc-dev, aneesh.kumar
In-Reply-To: <1513732229-10066-2-git-send-email-sukadev@linux.vnet.ibm.com>
On Wed, 2017-12-20 at 01:10:29 UTC, Sukadev Bhattiprolu wrote:
> Fix the order of cleanup to ensure we free the name buffer in case
> of an error creating 'hvwc' or 'info' files.
>
> Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/1373cc31074dff09419d616c2ce911
cheers
^ permalink raw reply
* Re: selftest/powerpc: Add test for sigreturn in transaction
From: Michael Ellerman @ 2018-03-14 9:27 UTC (permalink / raw)
To: Laurent Dufour, linuxppc-dev; +Cc: wei.guo.simon, cyrilbur
In-Reply-To: <1471884782-20403-1-git-send-email-ldufour@linux.vnet.ibm.com>
On Mon, 2016-08-22 at 16:53:02 UTC, Laurent Dufour wrote:
> Ensure that kernel is throwing away the suspended transaction when
> sigreturn() is called otherwise it if fails to restore the signal
> frame's TM SPRS.
>
> Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
> Reviewed-by: Cyril Bur <cyrilbur@gmail.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/9c96c932871efeabe82fcfdc952f35
cheers
^ permalink raw reply
* Re: powerpc/64s: Fix NULL AT_BASE_PLATFORM when using DT CPU features
From: Michael Ellerman @ 2018-03-14 9:24 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev; +Cc: sukadev, npiggin
In-Reply-To: <20180313231411.9537-1-mpe@ellerman.id.au>
On Tue, 2018-03-13 at 23:14:11 UTC, Michael Ellerman wrote:
> When running virtualised the powerpc kernel is able to run the system
> in "compat mode" - which means the kernel and hardware are pretending
> to userspace that the CPU is an older version than it actually is.
>
> AT_BASE_PLATFORM is an AUXV entry that we export to userspace for use
> when we're running in that mode, which tells userspace the "platform"
> string for the real CPU version, as opposed to the faked version.
>
> Although we don't support compat mode when using DT CPU features, and
> arguably don't need to set AT_BASE_PLATFORM, the existing cputable
> based code always sets it even when we're running bare metal. That
> means the lack of AT_BASE_PLATFORM is a user-visible artifact of the
> fact that the kernel is using DT CPU features, which we don't want.
>
> So set it in the DT CPU features code also.
>
> This results in eg:
> $ LD_SHOW_AUXV=1 /bin/true | grep "AT_.*PLATFORM"
> AT_PLATFORM: power9
> AT_BASE_PLATFORM:power9
>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
> Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
Applied to powerpc fixes.
https://git.kernel.org/powerpc/c/e4b79900222b8cccd4da4a7a89581f
cheers
^ permalink raw reply
* Re: [PATCH v9 17/24] mm: Protect mm_rb tree with a rwlock
From: Peter Zijlstra @ 2018-03-14 8:48 UTC (permalink / raw)
To: Laurent Dufour
Cc: paulmck, akpm, kirill, ak, mhocko, dave, jack, Matthew Wilcox,
benh, mpe, paulus, Thomas Gleixner, Ingo Molnar, hpa, Will Deacon,
Sergey Senozhatsky, Andrea Arcangeli, Alexei Starovoitov,
kemi.wang, sergey.senozhatsky.work, Daniel Jordan, linux-kernel,
linux-mm, haren, khandual, npiggin, bsingharora, Tim Chen,
linuxppc-dev, x86
In-Reply-To: <1520963994-28477-18-git-send-email-ldufour@linux.vnet.ibm.com>
On Tue, Mar 13, 2018 at 06:59:47PM +0100, Laurent Dufour wrote:
> This change is inspired by the Peter's proposal patch [1] which was
> protecting the VMA using SRCU. Unfortunately, SRCU is not scaling well in
> that particular case, and it is introducing major performance degradation
> due to excessive scheduling operations.
Do you happen to have a little more detail on that?
> diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> index 34fde7111e88..28c763ea1036 100644
> --- a/include/linux/mm_types.h
> +++ b/include/linux/mm_types.h
> @@ -335,6 +335,7 @@ struct vm_area_struct {
> struct vm_userfaultfd_ctx vm_userfaultfd_ctx;
> #ifdef CONFIG_SPECULATIVE_PAGE_FAULT
> seqcount_t vm_sequence;
> + atomic_t vm_ref_count; /* see vma_get(), vma_put() */
> #endif
> } __randomize_layout;
>
> @@ -353,6 +354,9 @@ struct kioctx_table;
> struct mm_struct {
> struct vm_area_struct *mmap; /* list of VMAs */
> struct rb_root mm_rb;
> +#ifdef CONFIG_SPECULATIVE_PAGE_FAULT
> + rwlock_t mm_rb_lock;
> +#endif
> u32 vmacache_seqnum; /* per-thread vmacache */
> #ifdef CONFIG_MMU
> unsigned long (*get_unmapped_area) (struct file *filp,
When I tried this, it simply traded contention on mmap_sem for
contention on these two cachelines.
This was for the concurrent fault benchmark, where mmap_sem is only ever
acquired for reading (so no blocking ever happens) and the bottle-neck
was really pure cacheline access.
Only by using RCU can you avoid that thrashing.
Also note that if your database allocates the one giant mapping, it'll
be _one_ VMA and that vm_ref_count gets _very_ hot indeed.
^ permalink raw reply
* Re: [linux-next][bisected c7c133f3][gcc 4.8.5] build fail with error: first argument to ‘__builtin_choose_expr’ not a constant
From: Stephen Rothwell @ 2018-03-14 8:39 UTC (permalink / raw)
To: Abdul Haleem
Cc: linuxppc-dev, linux-next, linux-kernel, Kees Cook, mpe, sachinp
In-Reply-To: <1521016194.31953.9.camel@abdul.in.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 961 bytes --]
Hi Abdul,
On Wed, 14 Mar 2018 13:59:54 +0530 Abdul Haleem <abdhalee@linux.vnet.ibm.com> wrote:
>
> Today's next kernel fails to build with gcc 4.8.5 on powerpc machine.
Thanks for the report. Just for the future, please include the
next-XXXXXXXX tag when making reports about linux-next.
> ./include/linux/jiffies.h: In function ‘jiffies_delta_to_clock_t’:
> ./include/linux/kernel.h:855:2: error: first argument to ‘__builtin_choose_expr’ not a constant
> __builtin_choose_expr(__builtin_constant_p(x) && \
> ^
> ./include/linux/kernel.h:867:19: note: in expansion of macro ‘__max’
> #define max(x, y) __max(typeof(x), typeof(y), x, y)
>
> Machine Type: Power8 Baremetal
> gcc: 4.8.5
>
>
> Builds fine when below patch is reverted
> c7c133f3 kernel.h: skip single-eval logic on literals in min()/max()
Those patches have been removed from today's linux-next (next-20180314).
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc/64s: Fix NULL AT_BASE_PLATFORM when using DT CPU features
From: Li Yi (Adam) @ 2018-03-14 8:34 UTC (permalink / raw)
To: linuxppc-dev
> Date: Wed, 14 Mar 2018 10:14:11 +1100
> From: Michael Ellerman <mpe@ellerman.id.au>
> To: linuxppc-dev@ozlabs.org
> Cc: sukadev@linux.vnet.ibm.com, npiggin@gmail.com
> Subject: [PATCH] powerpc/64s: Fix NULL AT_BASE_PLATFORM when using DT
> CPU features
> Message-ID: <20180313231411.9537-1-mpe@ellerman.id.au>
>
> When running virtualised the powerpc kernel is able to run the system
> in "compat mode" - which means the kernel and hardware are pretending
> to userspace that the CPU is an older version than it actually is.
>
> AT_BASE_PLATFORM is an AUXV entry that we export to userspace for use
> when we're running in that mode, which tells userspace the "platform"
> string for the real CPU version, as opposed to the faked version.
>
> Although we don't support compat mode when using DT CPU features, and
> arguably don't need to set AT_BASE_PLATFORM, the existing cputable
> based code always sets it even when we're running bare metal. That
> means the lack of AT_BASE_PLATFORM is a user-visible artifact of the
> fact that the kernel is using DT CPU features, which we don't want.
>
> So set it in the DT CPU features code also.
>
> This results in eg:
> $ LD_SHOW_AUXV=1 /bin/true | grep "AT_.*PLATFORM"
> AT_PLATFORM: power9
> AT_BASE_PLATFORM:power9
>
Is this issue related with DD2.2 CPU?
I tested on a Boston system with DD2.1 CPU, with kernel 4.14.23,
AT_BASE_PLATFORM value is correct:
[root@boston-sh-04 ~]# LD_SHOW_AUXV=1 /bin/true | grep "AT_.*PLATFORM"
AT_PLATFORM: power9
AT_BASE_PLATFORM:power9
[root@boston-sh-04 ~]# uname -a
Linux boston-sh-04 4.14.23 #1 SMP Sat Mar 3 12:14:56 CST 2018 ppc64le
ppc64le ppc64le GNU/Linux
Thanks,
-Yi
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
> ---
> arch/powerpc/kernel/dt_cpu_ftrs.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/powerpc/kernel/dt_cpu_ftrs.c b/arch/powerpc/kernel/dt_cpu_ftrs.c
> index 945e2c29ad2d..0bcfb0f256e1 100644
> --- a/arch/powerpc/kernel/dt_cpu_ftrs.c
> +++ b/arch/powerpc/kernel/dt_cpu_ftrs.c
> @@ -720,6 +720,9 @@ static void __init cpufeatures_setup_finished(void)
> cur_cpu_spec->cpu_features |= CPU_FTR_HVMODE;
> }
>
> + /* Make sure powerpc_base_platform is non-NULL */
> + powerpc_base_platform = cur_cpu_spec->platform;
> +
> system_registers.lpcr = mfspr(SPRN_LPCR);
> system_registers.hfscr = mfspr(SPRN_HFSCR);
> system_registers.fscr = mfspr(SPRN_FSCR);
> --
> 2.14.1
^ permalink raw reply
* [linux-next][bisected c7c133f3][gcc 4.8.5] build fail with error: first argument to ‘__builtin_choose_expr’ not a constant
From: Abdul Haleem @ 2018-03-14 8:29 UTC (permalink / raw)
To: linuxppc-dev
Cc: linux-next, linux-kernel, Stephen Rothwell, Kees Cook, mpe,
sachinp
Greetings,
Today's next kernel fails to build with gcc 4.8.5 on powerpc machine.
./include/linux/jiffies.h: In function ‘jiffies_delta_to_clock_t’:
./include/linux/kernel.h:855:2: error: first argument to ‘__builtin_choose_expr’ not a constant
__builtin_choose_expr(__builtin_constant_p(x) && \
^
./include/linux/kernel.h:867:19: note: in expansion of macro ‘__max’
#define max(x, y) __max(typeof(x), typeof(y), x, y)
Machine Type: Power8 Baremetal
gcc: 4.8.5
Builds fine when below patch is reverted
c7c133f3 kernel.h: skip single-eval logic on literals in min()/max()
--
Regard's
Abdul Haleem
IBM Linux Technology Centre
^ permalink raw reply
* Re: [PATCH] x86, powerpc : pkey-mprotect must allow pkey-0
From: Florian Weimer @ 2018-03-14 8:05 UTC (permalink / raw)
To: Ram Pai
Cc: mpe, mingo, akpm, linuxppc-dev, linux-mm, x86, linux-arch,
linux-kernel, dave.hansen, benh, paulus, khandual, aneesh.kumar,
bsingharora, hbabu, mhocko, bauerman, ebiederm, corbet, arnd,
msuchanek, Ulrich.Weigand
In-Reply-To: <f71b583f-2b66-e9ed-b08b-fddff228a5a7@redhat.com>
On 03/14/2018 09:00 AM, Florian Weimer wrote:
> On 03/09/2018 09:00 PM, Ram Pai wrote:
>> On Fri, Mar 09, 2018 at 12:04:49PM +0100, Florian Weimer wrote:
>>> On 03/09/2018 09:12 AM, Ram Pai wrote:
>>>> Once an address range is associated with an allocated pkey, it
>>>> cannot be
>>>> reverted back to key-0. There is no valid reason for the above
>>>> behavior.
>>>
>>> mprotect without a key does not necessarily use key 0, e.g. if
>>> protection keys are used to emulate page protection flag combination
>>> which is not directly supported by the hardware.
>>>
>>> Therefore, it seems to me that filtering out non-allocated keys is
>>> the right thing to do.
>>
>> I am not sure, what you mean. Do you agree with the patch or otherwise?
>
> I think it's inconsistent to make key 0 allocated, but not the key which
> is used for PROT_EXEC emulation, which is still reserved. Even if you
> change the key 0 behavior, it is still not possible to emulate mprotect
> behavior faithfully with an allocated key.
Ugh. Should have read the code first before replying:
/* Do we need to assign a pkey for mm's execute-only maps? */
if (execute_only_pkey == -1) {
/* Go allocate one to use, which might fail */
execute_only_pkey = mm_pkey_alloc(mm);
if (execute_only_pkey < 0)
return -1;
need_to_set_mm_pkey = true;
}
So we do allocate the PROT_EXEC-only key, and I assume it means that the
key can be restored using pkey_mprotect. So the key 0 behavior is a
true exception after all, and it makes sense to realign the behavior
with the other keys.
Thanks,
Florian
^ permalink raw reply
* Re: [PATCH] x86, powerpc : pkey-mprotect must allow pkey-0
From: Florian Weimer @ 2018-03-14 8:00 UTC (permalink / raw)
To: Ram Pai
Cc: mpe, mingo, akpm, linuxppc-dev, linux-mm, x86, linux-arch,
linux-kernel, dave.hansen, benh, paulus, khandual, aneesh.kumar,
bsingharora, hbabu, mhocko, bauerman, ebiederm, corbet, arnd,
msuchanek, Ulrich.Weigand
In-Reply-To: <20180309200017.GR1060@ram.oc3035372033.ibm.com>
On 03/09/2018 09:00 PM, Ram Pai wrote:
> On Fri, Mar 09, 2018 at 12:04:49PM +0100, Florian Weimer wrote:
>> On 03/09/2018 09:12 AM, Ram Pai wrote:
>>> Once an address range is associated with an allocated pkey, it cannot be
>>> reverted back to key-0. There is no valid reason for the above behavior.
>>
>> mprotect without a key does not necessarily use key 0, e.g. if
>> protection keys are used to emulate page protection flag combination
>> which is not directly supported by the hardware.
>>
>> Therefore, it seems to me that filtering out non-allocated keys is
>> the right thing to do.
>
> I am not sure, what you mean. Do you agree with the patch or otherwise?
I think it's inconsistent to make key 0 allocated, but not the key which
is used for PROT_EXEC emulation, which is still reserved. Even if you
change the key 0 behavior, it is still not possible to emulate mprotect
behavior faithfully with an allocated key.
Thanks,
Florian
^ permalink raw reply
* Re: [PATCH v2] powerpc/numa: Correct kernel message severity
From: Christophe LEROY @ 2018-03-14 7:58 UTC (permalink / raw)
To: Vipin K Parashar, linuxppc-dev; +Cc: nfont
In-Reply-To: <1521013954-21348-1-git-send-email-vipin@linux.vnet.ibm.com>
Le 14/03/2018 à 08:52, Vipin K Parashar a écrit :
> printk() in unmap_cpu_from_node() uses KERN_ERR message severity,
> for a WARNING message. Change it to pr_warn().
>
> Signed-off-by: Vipin K Parashar <vipin@linux.vnet.ibm.com>
Reviewed-by: Christophe Leroy <christophe.leroy@c-s.fr>
> ---
> arch/powerpc/mm/numa.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
> index edd8d0b..1632f4b 100644
> --- a/arch/powerpc/mm/numa.c
> +++ b/arch/powerpc/mm/numa.c
> @@ -163,8 +163,7 @@ static void unmap_cpu_from_node(unsigned long cpu)
> if (cpumask_test_cpu(cpu, node_to_cpumask_map[node])) {
> cpumask_clear_cpu(cpu, node_to_cpumask_map[node]);
> } else {
> - printk(KERN_ERR "WARNING: cpu %lu not found in node %d\n",
> - cpu, node);
> + pr_warn("WARNING: cpu %lu not found in node %d\n", cpu, node);
> }
> }
> #endif /* CONFIG_HOTPLUG_CPU || CONFIG_PPC_SPLPAR */
>
^ permalink raw reply
* Re: [PATCH] powerpc/numa: Correct kernel message severity
From: Vipin K Parashar @ 2018-03-14 7:53 UTC (permalink / raw)
To: Christophe LEROY, linuxppc-dev; +Cc: nfont
In-Reply-To: <29183547-d1c5-5282-86cb-3d5acbade58f@c-s.fr>
On Tuesday 13 March 2018 03:58 PM, Christophe LEROY wrote:
>
>
> Le 13/03/2018 à 11:11, Vipin K Parashar a écrit :
>> printk in unmap_cpu_from_node() uses KERN_ERR message severity
>> for a WARNING message. Correct message severity to KERN_WARNING.
>>
>> Signed-off-by: Vipin K Parashar <vipin@linux.vnet.ibm.com>
>> ---
>> arch/powerpc/mm/numa.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
>> index edd8d0b..79c94cc 100644
>> --- a/arch/powerpc/mm/numa.c
>> +++ b/arch/powerpc/mm/numa.c
>> @@ -163,7 +163,7 @@ static void unmap_cpu_from_node(unsigned long cpu)
>> if (cpumask_test_cpu(cpu, node_to_cpumask_map[node])) {
>> cpumask_clear_cpu(cpu, node_to_cpumask_map[node]);
>> } else {
>> - printk(KERN_ERR "WARNING: cpu %lu not found in node %d\n",
>> + printk(KERN_WARNING "WARNING: cpu %lu not found in node %d\n",
> > cpu, node);
>
> Why not take the opportunity to use pr_warn() instead, hence to put
> back the cpu and node vars on the same line.
>
> Christophe
>
Yes, Thanks!!
Send v2.
>> }
>> }
>>
>
^ permalink raw reply
* [PATCH v2] powerpc/numa: Correct kernel message severity
From: Vipin K Parashar @ 2018-03-14 7:52 UTC (permalink / raw)
To: linuxppc-dev; +Cc: nfont, Vipin K Parashar
printk() in unmap_cpu_from_node() uses KERN_ERR message severity,
for a WARNING message. Change it to pr_warn().
Signed-off-by: Vipin K Parashar <vipin@linux.vnet.ibm.com>
---
arch/powerpc/mm/numa.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
index edd8d0b..1632f4b 100644
--- a/arch/powerpc/mm/numa.c
+++ b/arch/powerpc/mm/numa.c
@@ -163,8 +163,7 @@ static void unmap_cpu_from_node(unsigned long cpu)
if (cpumask_test_cpu(cpu, node_to_cpumask_map[node])) {
cpumask_clear_cpu(cpu, node_to_cpumask_map[node]);
} else {
- printk(KERN_ERR "WARNING: cpu %lu not found in node %d\n",
- cpu, node);
+ pr_warn("WARNING: cpu %lu not found in node %d\n", cpu, node);
}
}
#endif /* CONFIG_HOTPLUG_CPU || CONFIG_PPC_SPLPAR */
--
2.7.4
^ permalink raw reply related
* PASEMI: PCI_SCAN_ALL_PCIE_DEVS
From: Christian Zigotzky @ 2018-03-14 7:48 UTC (permalink / raw)
To: linuxppc-dev, Olof Johansson
In-Reply-To: <BD2DFDC2-07CF-41A8-9AAE-9D990EFF6360@xenosoft.de>
[-- Attachment #1: Type: text/plain, Size: 256 bytes --]
Hi All,
Please find attached the current pci.c patch. We use this patch on our
P.A. Semi boards because we don't need to add 'pci=pcie_scan_all' to the
kernel boot arguments.
Please add this patch to the official kernel source code.
Thanks,
Christian
[-- Attachment #2: pci.c.patch --]
[-- Type: text/x-patch, Size: 541 bytes --]
arch/powerpc/platforms/pasemi/pci.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/platforms/pasemi/pci.c b/arch/powerpc/platforms/pasemi/pci.c
index 5ff6108..ea54ed2 100644
--- a/arch/powerpc/platforms/pasemi/pci.c
+++ b/arch/powerpc/platforms/pasemi/pci.c
@@ -224,6 +224,8 @@ void __init pas_pci_init(void)
return;
}
+ pci_set_flags(PCI_SCAN_ALL_PCIE_DEVS);
+
for (np = NULL; (np = of_get_next_child(root, np)) != NULL;)
if (np->name && !strcmp(np->name, "pxp") && !pas_add_bridge(np))
of_node_get(np);
^ permalink raw reply related
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