* Re: [-next] ocxl: Fix missing unlock on error in afu_ioctl_enable_p9_wait()
From: Michael Ellerman @ 2018-06-05 15:19 UTC (permalink / raw)
To: Wei Yongjun, Frederic Barrat, Andrew Donnellan, Arnd Bergmann,
Greg Kroah-Hartman, Alastair D'Silva
Cc: linuxppc-dev, kernel-janitors, Wei Yongjun, linux-kernel
In-Reply-To: <1528190181-15745-1-git-send-email-weiyongjun1@huawei.com>
On Tue, 2018-06-05 at 09:16:21 UTC, Wei Yongjun wrote:
> Add the missing unlock before return from function
> afu_ioctl_enable_p9_wait() in the error handling case.
>
> Fixes: e948e06fc63a ("ocxl: Expose the thread_id needed for wait on POWER9")
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
> Reviewed-by: Alastair D'Silva <alastair@d-silva.org>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/2e5c93d6bb2f7bc17eb82748943a1b
cheers
^ permalink raw reply
* Re: powerpc: fix build failure by disabling attribute-alias warning in pci_32
From: Michael Ellerman @ 2018-06-05 15:19 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <fa51770430e00ac2db1c621365473a0c893d105e.1528179842.git.christophe.leroy@c-s.fr>
On Tue, 2018-06-05 at 06:57:43 UTC, Christophe Leroy wrote:
> Commit 2479bfc9bc600 ("powerpc: Fix build by disabling attribute-alias
> warning for SYSCALL_DEFINEx") forgot arch/powerpc/kernel/pci_32.c
>
> Latest GCC version emit the following warnings
>
> As arch/powerpc code is built with -Werror, this breaks build with
> GCC 8.1
>
> This patch inhibits this warning
>
> In file included from arch/powerpc/kernel/pci_32.c:14:
> ./include/linux/syscalls.h:233:18: error: 'sys_pciconfig_iobase' alias between functions of incompatible types 'long int(long int, long unsigned int, long unsigned int)' and 'long int(long int, long int, long int)' [-Werror=attribute-alias]
> asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__)) \
> ^~~
> ./include/linux/syscalls.h:222:2: note: in expansion of macro '__SYSCALL_DEFINEx'
> __SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
> ^~~~~~~~~~~~~~~~~
>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/415520373975d2eba565c256d2cad8
cheers
^ permalink raw reply
* Re: powerpc/powernv: copy/paste - Mask SO bit in CR
From: Michael Ellerman @ 2018-06-05 15:19 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev
In-Reply-To: <20180604083338.2661-1-mpe@ellerman.id.au>
On Mon, 2018-06-04 at 08:33:38 UTC, Michael Ellerman wrote:
> NX can set the 3rd bit in CR register for XER[SO] (Summary overflow)
> which is not related to paste request. The current paste function
> returns failure for a successful request when this bit is set. So mask
> this bit and check the proper return status.
>
> Fixes: 2392c8c8c045 ("powerpc/powernv/vas: Define copy/paste interfaces")
> Cc: stable@vger.kernel.org # v4.14+
> Signed-off-by: Haren Myneni <haren@us.ibm.com>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Applied to powerpc next.
https://git.kernel.org/powerpc/c/75743649064ec0cf5ddd69f240ef23
cheers
^ permalink raw reply
* Re: cpuidle:powernv: Make the snooze timeout dynamic.
From: Michael Ellerman @ 2018-06-05 15:19 UTC (permalink / raw)
To: Gautham R. Shenoy, Rafael J. Wysocki, Daniel Lezcano,
Stewart Smith, Michael Neuling, Vaidyanathan Srinivasan,
Shilpasri G Bhat, Akshay Adiga, Nicholas Piggin
Cc: Gautham R. Shenoy, linuxppc-dev, linux-kernel, linux-pm
In-Reply-To: <1527768909-32637-1-git-send-email-ego@linux.vnet.ibm.com>
On Thu, 2018-05-31 at 12:15:09 UTC, "Gautham R. Shenoy" wrote:
> From: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>
>
> The commit 78eaa10f027c ("cpuidle: powernv/pseries: Auto-promotion of
> snooze to deeper idle state") introduced a timeout for the snooze idle
> state so that it could be eventually be promoted to a deeper idle
> state. The snooze timeout value is static and set to the target
> residency of the next idle state, which would train the cpuidle
> governor to pick the next idle state eventually.
>
> The unfortunate side-effect of this is that if the next idle state(s)
> is disabled, the CPU will forever remain in snooze, despite the fact
> that the system is completely idle, and other deeper idle states are
> available.
>
> This patch fixes the issue by dynamically setting the snooze timeout
> to the target residency of the next enabled state on the device.
>
> Before Patch
> Reviewed-by: Balbir Singh <bsingharora@gmail.com>
>
> ==================
> POWER8 : Only nap disabled.
> $cpupower monitor sleep 30
> sleep took 30.01297 seconds and exited with status 0
> |Idle_Stats
> PKG |CORE|CPU | snoo | Nap | Fast
> 0| 8| 0| 96.41| 0.00| 0.00
> 0| 8| 1| 96.43| 0.00| 0.00
> 0| 8| 2| 96.47| 0.00| 0.00
> 0| 8| 3| 96.35| 0.00| 0.00
> 0| 8| 4| 96.37| 0.00| 0.00
> 0| 8| 5| 96.37| 0.00| 0.00
> 0| 8| 6| 96.47| 0.00| 0.00
> 0| 8| 7| 96.47| 0.00| 0.00
>
> POWER9: Shallow states (stop0lite, stop1lite, stop2lite, stop0, stop1,
> stop2) disabled:
> $cpupower monitor sleep 30
> sleep took 30.05033 seconds and exited with status 0
> |Idle_Stats
> PKG |CORE|CPU | snoo | stop | stop | stop | stop | stop | stop | stop | stop
> 0| 16| 0| 89.79| 0.00| 0.00| 0.00| 0.00| 0.00| 0.00| 0.00| 0.00
> 0| 16| 1| 90.12| 0.00| 0.00| 0.00| 0.00| 0.00| 0.00| 0.00| 0.00
> 0| 16| 2| 90.21| 0.00| 0.00| 0.00| 0.00| 0.00| 0.00| 0.00| 0.00
> 0| 16| 3| 90.29| 0.00| 0.00| 0.00| 0.00| 0.00| 0.00| 0.00| 0.00
>
> After Patch
> ======================
> POWER8 : Only nap disabled.
> $ cpupower monitor sleep 30
> sleep took 30.01200 seconds and exited with status 0
> |Idle_Stats
> PKG |CORE|CPU | snoo | Nap | Fast
> 0| 8| 0| 16.58| 0.00| 77.21
> 0| 8| 1| 18.42| 0.00| 75.38
> 0| 8| 2| 4.70| 0.00| 94.09
> 0| 8| 3| 17.06| 0.00| 81.73
> 0| 8| 4| 3.06| 0.00| 95.73
> 0| 8| 5| 7.00| 0.00| 96.80
> 0| 8| 6| 1.00| 0.00| 98.79
> 0| 8| 7| 5.62| 0.00| 94.17
>
> POWER9: Shallow states (stop0lite, stop1lite, stop2lite, stop0, stop1,
> stop2) disabled:
>
> $cpupower monitor sleep 30
> sleep took 30.02110 seconds and exited with status 0
> |Idle_Stats
> PKG |CORE|CPU | snoo | stop | stop | stop | stop | stop | stop | stop | stop
> 0| 0| 0| 0.69| 0.00| 0.00| 0.00| 0.00| 0.00| 0.00| 9.39| 89.70
> 0| 0| 1| 0.00| 0.00| 0.00| 0.00| 0.00| 0.00| 0.00| 0.05| 93.21
> 0| 0| 2| 0.00| 0.00| 0.00| 0.00| 0.00| 0.00| 0.00| 0.00| 89.93
> 0| 0| 3| 0.00| 0.00| 0.00| 0.00| 0.00| 0.00| 0.00| 0.00| 93.26
>
> Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/0a4ec6aa035a52c422eceb2ed51ed8
cheers
^ permalink raw reply
* Re: powerpc-opal: fix spelling mistake "Uniterrupted" -> "Uninterrupted"
From: Michael Ellerman @ 2018-06-05 15:19 UTC (permalink / raw)
To: Colin King, Benjamin Herrenschmidt, Paul Mackerras,
Markus Elfring, linuxppc-dev
Cc: kernel-janitors, linux-kernel
In-Reply-To: <20180526151531.10920-1-colin.king@canonical.com>
On Sat, 2018-05-26 at 15:15:31 UTC, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> Trivial fix to spelling mistake in hmi_error_types text
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> Reviewed-by: Stewart Smith <stewart@linux.ibm.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/b0c4acb1dd7c653f78391661079af5
cheers
^ permalink raw reply
* Re: powerpc/pkeys: Detach execute_only key on !PROT_EXEC
From: Michael Ellerman @ 2018-06-05 15:19 UTC (permalink / raw)
To: Ram Pai
Cc: dave.hansen, msuchanek, Ulrich.Weigand, linuxram, mhocko, paulus,
aneesh.kumar, bauerman, Shakeel Butt, linuxppc-dev
In-Reply-To: <1525464111-1096-1-git-send-email-linuxram@us.ibm.com>
On Fri, 2018-05-04 at 20:01:51 UTC, Ram Pai wrote:
> Disassociate the exec_key from a VMA if the VMA permission is not
> PROT_EXEC anymore. Otherwise the exec_only key continues to be
> associated with the vma, causing unexpected behavior.
>
> The problem was reported on x86 by Shakeel Butt,
> which is also applicable on powerpc.
>
> cc: Shakeel Butt <shakeelb@google.com>
> Reported-by: Shakeel Butt <shakeelb@google.com>
> Fixes 5586cf6 ("powerpc: introduce execute-only pkey")
> Signed-off-by: Ram Pai <linuxram@us.ibm.com>
> Reviewed-by: Thiago Jung Bauermann <bauerman@linux.ibm.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/eabdb8ca8690eedd461e61ea778059
cheers
^ permalink raw reply
* Re: powerpc: fix spelling mistake: "Usupported" -> "Unsupported"
From: Michael Ellerman @ 2018-06-05 15:19 UTC (permalink / raw)
To: Colin King, Benjamin Herrenschmidt, Paul Mackerras, linuxppc-dev
Cc: kernel-janitors, linux-kernel
In-Reply-To: <20180330155553.7170-1-colin.king@canonical.com>
On Fri, 2018-03-30 at 15:55:53 UTC, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> Trivial fix to spelling mistake in bootx_printf message text
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/e6536a9f94c00a5e1da0a869ccea07
cheers
^ permalink raw reply
* Re: Problems building ppc images in v4.14.y and v4.16.y using gcc 7.3.0 / 8.1.0 from kernel.org
From: Arnd Bergmann @ 2018-06-05 14:31 UTC (permalink / raw)
To: Guenter Roeck; +Cc: stable, Greg Kroah-Hartman, linuxppc-dev
In-Reply-To: <e11832b0-f071-b709-be34-417f2d3bc343@roeck-us.net>
On Tue, Jun 5, 2018 at 3:52 PM, Guenter Roeck <linux@roeck-us.net> wrote:
> Hi Arnd,
>
> when using the ppc64 compiler from kernel.org, I see the following problems
> when trying to compile ppc:allnoconfig in v4.14.y or v4.16.y.
>
> gcc 7.3.0: Compilation of kernel.cpu.o hangs
>
> The problem goes away if I apply the following two patches (tested with
> 4.16.y)
>
> 17a2f1ced028 cpu/hotplug: Merge cpuhp_bp_states and cpuhp_ap_states
> fcb3029a8d89 cpu/hotplug: Fix unused function warning
This is probably the same as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84038
I thought I had included the fix in my builds.
> gcc 8.1.0: Compilation of kernel/cpu.o results in the following error
>
> powerpc64-linux-gcc: error: unrecognized command line option '-mno-spe'; did
> you mean '-fno-see'?
> powerpc64-linux-gcc: error: unrecognized command line option '-mspe=no'; did
> you mean '-misel=no'?
>
> This problem is also seen with mainline.
I've seen it, but couldn't figure out what the right fix is. I ended
up commenting
out those two lines in my private builds:
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -215,8 +215,8 @@ KBUILD_CFLAGS += $(call cc-option,-mno-vsx)
# No SPE instruction when building kernel
# (We use all available options to help semi-broken compilers)
-KBUILD_CFLAGS += $(call cc-option,-mno-spe)
-KBUILD_CFLAGS += $(call cc-option,-mspe=no)
+#KBUILD_CFLAGS += $(call cc-option,-mno-spe)
+#KBUILD_CFLAGS += $(call cc-option,-mspe=no)
# Enable unit-at-a-time mode when possible. It shrinks the
# kernel considerably.
I think there were some changes in how cc-option gets evaluated, maybe
those rely on something else to be enabled or disabled first?
Arnd
^ permalink raw reply
* Re: [PATCH 09/10] dpaa_eth: add support for hardware timestamping
From: Richard Cochran @ 2018-06-05 13:57 UTC (permalink / raw)
To: Y.b. Lu
Cc: netdev@vger.kernel.org, Madalin-cristian Bucur, Rob Herring,
Shawn Guo, David S . Miller, devicetree@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <DB6PR0401MB2536376432EC481473A5B4A3F8660@DB6PR0401MB2536.eurprd04.prod.outlook.com>
On Tue, Jun 05, 2018 at 03:35:28AM +0000, Y.b. Lu wrote:
> [Y.b. Lu] Actually these timestamping codes affected DPAA networking performance in our previous performance test.
> That's why we used ifdef for it.
How much does time stamping hurt performance?
If the time stamping is compiled in but not enabled at run time, does
it still affect performace?
Thanks,
Richard
^ permalink raw reply
* Re: [PATCH -next] ocxl: Fix missing unlock on error in afu_ioctl_enable_p9_wait()
From: Frederic Barrat @ 2018-06-05 12:57 UTC (permalink / raw)
To: Wei Yongjun, Frederic Barrat, Andrew Donnellan, Arnd Bergmann,
Greg Kroah-Hartman, Alastair D'Silva
Cc: linuxppc-dev, linux-kernel, kernel-janitors
In-Reply-To: <1528190181-15745-1-git-send-email-weiyongjun1@huawei.com>
Le 05/06/2018 à 11:16, Wei Yongjun a écrit :
> Add the missing unlock before return from function
> afu_ioctl_enable_p9_wait() in the error handling case.
>
> Fixes: e948e06fc63a ("ocxl: Expose the thread_id needed for wait on POWER9")
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
> ---
> drivers/misc/ocxl/file.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/misc/ocxl/file.c b/drivers/misc/ocxl/file.c
> index 33ae46c..e6a6074 100644
> --- a/drivers/misc/ocxl/file.c
> +++ b/drivers/misc/ocxl/file.c
> @@ -139,8 +139,10 @@ static long afu_ioctl_enable_p9_wait(struct ocxl_context *ctx,
> // Locks both status & tidr
> mutex_lock(&ctx->status_mutex);
> if (!ctx->tidr) {
> - if (set_thread_tidr(current))
> + if (set_thread_tidr(current)) {
> + mutex_unlock(&ctx->status_mutex);
> return -ENOENT;
> + }
O_o Thanks for fixing it
Acked-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
> ctx->tidr = current->thread.tidr;
> }
>
^ permalink raw reply
* Re: [RFC PATCH for 4.18 10/16] powerpc: Wire up restartable sequences system call
From: Mathieu Desnoyers @ 2018-06-05 12:51 UTC (permalink / raw)
To: Michael Ellerman
Cc: Peter Zijlstra, Paul E. McKenney, Boqun Feng, Andy Lutomirski,
Dave Watson, linux-kernel, linux-api, Paul Turner, Andrew Morton,
Russell King, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Andrew Hunter, Andi Kleen, Chris Lameter, Ben Maurer, rostedt,
Josh Triplett, Linus Torvalds, Catalin Marinas, Will Deacon,
Michael Kerrisk, Joel Fernandes, Benjamin Herrenschmidt,
Paul Mackerras, linuxppc-dev
In-Reply-To: <874lihbykr.fsf@concordia.ellerman.id.au>
----- On Jun 5, 2018, at 1:18 AM, Michael Ellerman mpe@ellerman.id.au wrote:
> Mathieu Desnoyers <mathieu.desnoyers@efficios.com> writes:
>
>> From: Boqun Feng <boqun.feng@gmail.com>
>>
>> Wire up the rseq system call on powerpc.
>>
>> This provides an ABI improving the speed of a user-space getcpu
>> operation on powerpc by skipping the getcpu system call on the fast
>> path, as well as improving the speed of user-space operations on per-cpu
>> data compared to using load-reservation/store-conditional atomics.
>>
>> Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
>> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
>> CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>> CC: Paul Mackerras <paulus@samba.org>
>> CC: Michael Ellerman <mpe@ellerman.id.au>
>> CC: Peter Zijlstra <peterz@infradead.org>
>> CC: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
>> CC: linuxppc-dev@lists.ozlabs.org
>> ---
>> arch/powerpc/include/asm/systbl.h | 1 +
>> arch/powerpc/include/asm/unistd.h | 2 +-
>> arch/powerpc/include/uapi/asm/unistd.h | 1 +
>> 3 files changed, 3 insertions(+), 1 deletion(-)
>
> Looks fine to me.
>
> I don't have any other new syscalls in my next, so this should not
> conflict with anything for 4.18.
>
> Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
Added your ack to the series, thanks!
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
^ permalink raw reply
* Re: [RFC PATCH for 4.18 09/16] powerpc: Add syscall detection for restartable sequences
From: Mathieu Desnoyers @ 2018-06-05 12:50 UTC (permalink / raw)
To: Michael Ellerman
Cc: Peter Zijlstra, Paul E. McKenney, Boqun Feng, Andy Lutomirski,
Dave Watson, linux-kernel, linux-api, Paul Turner, Andrew Morton,
Russell King, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Andrew Hunter, Andi Kleen, Chris Lameter, Ben Maurer, rostedt,
Josh Triplett, Linus Torvalds, Catalin Marinas, Will Deacon,
Michael Kerrisk, Joel Fernandes, Benjamin Herrenschmidt,
Paul Mackerras, linuxppc-dev
In-Reply-To: <871sdlbyg7.fsf@concordia.ellerman.id.au>
----- On Jun 5, 2018, at 1:21 AM, Michael Ellerman mpe@ellerman.id.au wrote:
> Mathieu Desnoyers <mathieu.desnoyers@efficios.com> writes:
>> From: Boqun Feng <boqun.feng@gmail.com>
>>
>> Syscalls are not allowed inside restartable sequences, so add a call to
>> rseq_syscall() at the very beginning of system call exiting path for
>> CONFIG_DEBUG_RSEQ=y kernel. This could help us to detect whether there
>> is a syscall issued inside restartable sequences.
>>
>> [ Tested on 64-bit powerpc kernel by Mathieu Desnoyers. Still needs to
>> be tested on 32-bit powerpc kernel. ]
>>
>> Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
>> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
>> CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>> CC: Paul Mackerras <paulus@samba.org>
>> CC: Michael Ellerman <mpe@ellerman.id.au>
>> CC: Peter Zijlstra <peterz@infradead.org>
>> CC: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
>> CC: linuxppc-dev@lists.ozlabs.org
>> ---
>> arch/powerpc/kernel/entry_32.S | 7 +++++++
>> arch/powerpc/kernel/entry_64.S | 8 ++++++++
>> 2 files changed, 15 insertions(+)
>
> I don't _love_ the #ifdefs in here, but they look correct and there's
> not really a better option until we rewrite the syscall handler in C.
>
> The rseq selftests passed for me with this applied and enabled. So if
> you like here's some tags:
>
> Tested-by: Michael Ellerman <mpe@ellerman.id.au>
> Acked-by: Michael Ellerman <mpe@ellerman.id.au>
>
Adding you ack to the series.
Thanks!
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
^ permalink raw reply
* Re: [v3] powerpc: fix build failure by disabling attribute-alias warning
From: Michael Ellerman @ 2018-06-05 12:21 UTC (permalink / raw)
To: Christophe LEROY, Michael Ellerman, Benjamin Herrenschmidt,
Paul Mackerras, segher
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <0332913c-04c0-362f-313f-8d42099f168d@c-s.fr>
Christophe LEROY <christophe.leroy@c-s.fr> writes:
> Le 04/06/2018 =C3=A0 16:11, Michael Ellerman a =C3=A9crit=C2=A0:
>> On Tue, 2018-05-29 at 16:06:41 UTC, Christophe Leroy wrote:
>>> Latest GCC version emit the following warnings
>>>
>>> As arch/powerpc code is built with -Werror, this breaks build with
>>> GCC 8.1
>>>
....
>>>
>>> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
>>=20
>> Applied to powerpc next, thanks.
>>=20
>> https://git.kernel.org/powerpc/c/2479bfc9bc600dcce7f932d52dcfa8
>
> Oops, you didn't take v4 but v3 which was missing the fix into pci_32.c
Yep sorry. I had v3 in my tree since a few days.
If the patch is "Under Review" in patchwork that usually means I have it
applied and am testing it. Although sometimes I forget :)
> I'll send you a patch to add the fix in pci_32.c
Thanks, applied.
cheers
^ permalink raw reply
* Re: [PATCH] cpuidle:powernv: Make the snooze timeout dynamic.
From: Michael Ellerman @ 2018-06-05 12:18 UTC (permalink / raw)
To: Gautham R Shenoy
Cc: Gautham R. Shenoy, Rafael J. Wysocki, Daniel Lezcano,
Stewart Smith, Michael Neuling, Vaidyanathan Srinivasan,
Shilpasri G Bhat, Akshay Adiga, Nicholas Piggin, linuxppc-dev,
linux-kernel, linux-pm
In-Reply-To: <20180605084529.GA5656@in.ibm.com>
Gautham R Shenoy <ego@linux.vnet.ibm.com> writes:
> Hello Michael,
>
> On Mon, Jun 04, 2018 at 09:27:40PM +1000, Michael Ellerman wrote:
>> "Gautham R. Shenoy" <ego@linux.vnet.ibm.com> writes:
>>
>> > From: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>
>> >
>> > The commit 78eaa10f027c ("cpuidle: powernv/pseries: Auto-promotion of
>> > snooze to deeper idle state") introduced a timeout for the snooze idle
>> > state so that it could be eventually be promoted to a deeper idle
>> > state. The snooze timeout value is static and set to the target
>> > residency of the next idle state, which would train the cpuidle
>> > governor to pick the next idle state eventually.
>> >
>> > The unfortunate side-effect of this is that if the next idle state(s)
>> > is disabled, the CPU will forever remain in snooze, despite the fact
>> > that the system is completely idle, and other deeper idle states are
>> > available.
>>
>> That sounds like a bug, I'll add?
>
> Yes, this is a bug-fix for a customer scenario which we encountered
> recently.
OK, the change log could have used some more scary words to make that
clearer ;)
I changed the subject to:
cpuidle: powernv: Fix promotion from snooze if next state disabled
Which hopefully makes sense.
>> Fixes: 78eaa10f027c ("cpuidle: powernv/pseries: Auto-promotion of snooze to deeper idle state")
>> Cc: stable@vger.kernel.org # v4.2+
>
> This patch applies cleanly from v4.13 onwards. Prior to that there are
> some (minor) conflicts.
>
> Should I spin a version separately for the prior stable versions ?
Yes please, that would be great.
You might want to avoid "=====" in the change log too, as patchwork and
possibly other tools will think it's part of the diff.
cheers
^ permalink raw reply
* RE: [PATCH -next] ocxl: Fix missing unlock on error in afu_ioctl_enable_p9_wait()
From: Alastair D'Silva @ 2018-06-05 9:41 UTC (permalink / raw)
To: 'Wei Yongjun', 'Frederic Barrat',
'Andrew Donnellan', 'Arnd Bergmann',
'Greg Kroah-Hartman'
Cc: linuxppc-dev, linux-kernel, kernel-janitors
In-Reply-To: <1528190181-15745-1-git-send-email-weiyongjun1@huawei.com>
> -----Original Message-----
> From: Wei Yongjun <weiyongjun1@huawei.com>
> Sent: Tuesday, 5 June 2018 7:16 PM
> To: Frederic Barrat <fbarrat@linux.vnet.ibm.com>; Andrew Donnellan
> <andrew.donnellan@au1.ibm.com>; Arnd Bergmann <arnd@arndb.de>;
> Greg Kroah-Hartman <gregkh@linuxfoundation.org>; Alastair D'Silva
> <alastair@d-silva.org>
> Cc: Wei Yongjun <weiyongjun1@huawei.com>; linuxppc-
> dev@lists.ozlabs.org; linux-kernel@vger.kernel.org; kernel-
> janitors@vger.kernel.org
> Subject: [PATCH -next] ocxl: Fix missing unlock on error in
> afu_ioctl_enable_p9_wait()
>
> Add the missing unlock before return from function
> afu_ioctl_enable_p9_wait() in the error handling case.
>
> Fixes: e948e06fc63a ("ocxl: Expose the thread_id needed for wait on
> POWER9")
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
> ---
> drivers/misc/ocxl/file.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/misc/ocxl/file.c b/drivers/misc/ocxl/file.c index
> 33ae46c..e6a6074 100644
> --- a/drivers/misc/ocxl/file.c
> +++ b/drivers/misc/ocxl/file.c
> @@ -139,8 +139,10 @@ static long afu_ioctl_enable_p9_wait(struct
> ocxl_context *ctx,
> // Locks both status & tidr
> mutex_lock(&ctx->status_mutex);
> if (!ctx->tidr) {
> - if (set_thread_tidr(current))
> + if (set_thread_tidr(current)) {
> + mutex_unlock(&ctx->status_mutex);
> return -ENOENT;
> + }
>
> ctx->tidr = current->thread.tidr;
> }
Thanks for picking that up!
Reviewed-by: Alastair D'Silva <alastair@d-silva.org>
--
Alastair D'Silva mob: 0423 762 819
skype: alastair_dsilva msn: alastair@d-silva.org
blog: http://alastair.d-silva.org Twitter: @EvilDeece
^ permalink raw reply
* [PATCH -next] ocxl: Fix missing unlock on error in afu_ioctl_enable_p9_wait()
From: Wei Yongjun @ 2018-06-05 9:16 UTC (permalink / raw)
To: Frederic Barrat, Andrew Donnellan, Arnd Bergmann,
Greg Kroah-Hartman, Alastair D'Silva
Cc: Wei Yongjun, linuxppc-dev, linux-kernel, kernel-janitors
Add the missing unlock before return from function
afu_ioctl_enable_p9_wait() in the error handling case.
Fixes: e948e06fc63a ("ocxl: Expose the thread_id needed for wait on POWER9")
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
drivers/misc/ocxl/file.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/ocxl/file.c b/drivers/misc/ocxl/file.c
index 33ae46c..e6a6074 100644
--- a/drivers/misc/ocxl/file.c
+++ b/drivers/misc/ocxl/file.c
@@ -139,8 +139,10 @@ static long afu_ioctl_enable_p9_wait(struct ocxl_context *ctx,
// Locks both status & tidr
mutex_lock(&ctx->status_mutex);
if (!ctx->tidr) {
- if (set_thread_tidr(current))
+ if (set_thread_tidr(current)) {
+ mutex_unlock(&ctx->status_mutex);
return -ENOENT;
+ }
ctx->tidr = current->thread.tidr;
}
^ permalink raw reply related
* Re: [PATCH v2] cpuidle/powernv : Add Description for cpuidle state
From: Akshay Adiga @ 2018-06-05 9:08 UTC (permalink / raw)
To: Abhishek
Cc: Benjamin Herrenschmidt, stewart, linux-pm, daniel.lezcano, rjw,
linux-kernel, paulus, linuxppc-dev
In-Reply-To: <17cd53ec-6bc1-5814-8824-3c6a4f0b90cd@linux.vnet.ibm.com>
On Tue, Jun 05, 2018 at 02:24:39PM +0530, Abhishek wrote:
>
>
> On 06/04/2018 05:15 PM, Akshay Adiga wrote:
> > On Mon, Jun 04, 2018 at 07:04:14PM +1000, Benjamin Herrenschmidt wrote:
> > > Is this a new property ? I'm not fan of adding yet another of those
> > > silly arrays.
> > >
> > > I would say this is the right time now to switch over to a node per
> > > state instead, as we discussed with Vaidy.
>
> It is not a new property. Name was being used for description as description
> was not present in device tree. A skiboot patch adding description to device
> tree have been posted. This patch reads those description instead of copying
> name itself into description. And we fall back to reading name into
> description to not break the comaptibility with older firmware.
>From a cpuidle point of view this is a exisiting property, but for
powernv there was no device-tree property describing this.
Abhishek has added the following skiboot patch for adding description
for each idle state in device-tree .
https://patchwork.ozlabs.org/patch/924879/
I agree this can go into new device tree format which each idle state
as a node. Probably i will roll this patch into mine in the next
version.
>
> Thanks
> Abhishek
>
> > I posted the node based device tree here :
> > skiboot patch : https://patchwork.ozlabs.org/patch/923120/
> > kernel patch : https://lkml.org/lkml/2018/5/30/1146
> >
> > Do you have any inputs for this design ?
> >
> > > Additionally, while doing that, we can provide the versioning mechanism
> > > I proposed so we can deal with state specific issues and erratas.
> > >
> > > Cheers,
> > > Ben.
> > >
>
^ permalink raw reply
* Re: [PATCH v2] cpuidle/powernv : Add Description for cpuidle state
From: Abhishek @ 2018-06-05 8:54 UTC (permalink / raw)
To: Akshay Adiga, Benjamin Herrenschmidt
Cc: rjw, daniel.lezcano, paulus, mpe, linux-pm, linuxppc-dev,
linux-kernel, stewart
In-Reply-To: <20180604114500.3rlpuso5aftesnf5@aksadiga.ibm>
On 06/04/2018 05:15 PM, Akshay Adiga wrote:
> On Mon, Jun 04, 2018 at 07:04:14PM +1000, Benjamin Herrenschmidt wrote:
>> Is this a new property ? I'm not fan of adding yet another of those
>> silly arrays.
>>
>> I would say this is the right time now to switch over to a node per
>> state instead, as we discussed with Vaidy.
It is not a new property. Name was being used for description as
description was not present in device tree. A skiboot patch adding
description to device tree have been posted. This patch reads those
description instead of copying name itself into description. And we fall
back to reading name into description to not break the comaptibility
with older firmware.
Thanks
Abhishek
> I posted the node based device tree here :
> skiboot patch : https://patchwork.ozlabs.org/patch/923120/
> kernel patch : https://lkml.org/lkml/2018/5/30/1146
>
> Do you have any inputs for this design ?
>
>> Additionally, while doing that, we can provide the versioning mechanism
>> I proposed so we can deal with state specific issues and erratas.
>>
>> Cheers,
>> Ben.
>>
^ permalink raw reply
* Re: [PATCH] cpuidle:powernv: Make the snooze timeout dynamic.
From: Gautham R Shenoy @ 2018-06-05 8:45 UTC (permalink / raw)
To: Michael Ellerman
Cc: Gautham R. Shenoy, Rafael J. Wysocki, Daniel Lezcano,
Stewart Smith, Michael Neuling, Vaidyanathan Srinivasan,
Shilpasri G Bhat, Akshay Adiga, Nicholas Piggin, linuxppc-dev,
linux-kernel, linux-pm
In-Reply-To: <87fu22bxlf.fsf@concordia.ellerman.id.au>
Hello Michael,
On Mon, Jun 04, 2018 at 09:27:40PM +1000, Michael Ellerman wrote:
> "Gautham R. Shenoy" <ego@linux.vnet.ibm.com> writes:
>
> > From: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>
> >
> > The commit 78eaa10f027c ("cpuidle: powernv/pseries: Auto-promotion of
> > snooze to deeper idle state") introduced a timeout for the snooze idle
> > state so that it could be eventually be promoted to a deeper idle
> > state. The snooze timeout value is static and set to the target
> > residency of the next idle state, which would train the cpuidle
> > governor to pick the next idle state eventually.
> >
> > The unfortunate side-effect of this is that if the next idle state(s)
> > is disabled, the CPU will forever remain in snooze, despite the fact
> > that the system is completely idle, and other deeper idle states are
> > available.
>
> That sounds like a bug, I'll add?
>
Yes, this is a bug-fix for a customer scenario which we encountered
recently.
> Fixes: 78eaa10f027c ("cpuidle: powernv/pseries: Auto-promotion of snooze to deeper idle state")
> Cc: stable@vger.kernel.org # v4.2+
This patch applies cleanly from v4.13 onwards. Prior to that there are
some (minor) conflicts.
Should I spin a version separately for the prior stable versions ?
>
> cheers
>
^ permalink raw reply
* Re: [v3] powerpc: fix build failure by disabling attribute-alias warning
From: Christophe LEROY @ 2018-06-05 7:00 UTC (permalink / raw)
To: Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras, segher
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <40zxgb4SmTz9s7c@ozlabs.org>
Le 04/06/2018 à 16:11, Michael Ellerman a écrit :
> On Tue, 2018-05-29 at 16:06:41 UTC, Christophe Leroy wrote:
>> Latest GCC version emit the following warnings
>>
>> As arch/powerpc code is built with -Werror, this breaks build with
>> GCC 8.1
>>
>> This patch inhibits those warnings
>>
>> CC arch/powerpc/kernel/syscalls.o
>> In file included from arch/powerpc/kernel/syscalls.c:24:
>> ./include/linux/syscalls.h:233:18: error: 'sys_mmap2' alias between functions of incompatible types 'long int(long unsigned int, size_t, long unsigned int, long unsigned int, long unsigned int, long unsigned int)' {aka 'long int(long unsigned int, long unsigned int, long unsigned int, long unsigned int, long unsigned int, long unsigned int)'} and 'long int(long int, long int, long int, long int, long int, long int)' [-Werror=attribute-alias]
>> asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__)) \
>> ^~~
>> ./include/linux/syscalls.h:222:2: note: in expansion of macro '__SYSCALL_DEFINEx'
>> __SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
>> ^~~~~~~~~~~~~~~~~
>> ./include/linux/syscalls.h:216:36: note: in expansion of macro 'SYSCALL_DEFINEx'
>> #define SYSCALL_DEFINE6(name, ...) SYSCALL_DEFINEx(6, _##name, __VA_ARGS__)
>> ^~~~~~~~~~~~~~~
>> arch/powerpc/kernel/syscalls.c:65:1: note: in expansion of macro 'SYSCALL_DEFINE6'
>> SYSCALL_DEFINE6(mmap2, unsigned long, addr, size_t, len,
>> ^~~~~~~~~~~~~~~
>> ./include/linux/syscalls.h:238:18: note: aliased declaration here
>> asmlinkage long __se_sys##name(__MAP(x,__SC_LONG,__VA_ARGS__)) \
>> ^~~~~~~~
>> ./include/linux/syscalls.h:222:2: note: in expansion of macro '__SYSCALL_DEFINEx'
>> __SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
>> ^~~~~~~~~~~~~~~~~
>> ./include/linux/syscalls.h:216:36: note: in expansion of macro 'SYSCALL_DEFINEx'
>> #define SYSCALL_DEFINE6(name, ...) SYSCALL_DEFINEx(6, _##name, __VA_ARGS__)
>> ^~~~~~~~~~~~~~~
>> arch/powerpc/kernel/syscalls.c:65:1: note: in expansion of macro 'SYSCALL_DEFINE6'
>> SYSCALL_DEFINE6(mmap2, unsigned long, addr, size_t, len,
>> ^~~~~~~~~~~~~~~
>> ./include/linux/syscalls.h:233:18: error: 'sys_mmap' alias between functions of incompatible types 'long int(long unsigned int, size_t, long unsigned int, long unsigned int, long unsigned int, off_t)' {aka 'long int(long unsigned int, long unsigned int, long unsigned int, long unsigned int, long unsigned int, long int)'} and 'long int(long int, long int, long int, long int, long int, long int)' [-Werror=attribute-alias]
>> asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__)) \
>> ^~~
>> ./include/linux/syscalls.h:222:2: note: in expansion of macro '__SYSCALL_DEFINEx'
>> __SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
>> ^~~~~~~~~~~~~~~~~
>> ./include/linux/syscalls.h:216:36: note: in expansion of macro 'SYSCALL_DEFINEx'
>> #define SYSCALL_DEFINE6(name, ...) SYSCALL_DEFINEx(6, _##name, __VA_ARGS__)
>> ^~~~~~~~~~~~~~~
>> arch/powerpc/kernel/syscalls.c:72:1: note: in expansion of macro 'SYSCALL_DEFINE6'
>> SYSCALL_DEFINE6(mmap, unsigned long, addr, size_t, len,
>> ^~~~~~~~~~~~~~~
>> ./include/linux/syscalls.h:238:18: note: aliased declaration here
>> asmlinkage long __se_sys##name(__MAP(x,__SC_LONG,__VA_ARGS__)) \
>> ^~~~~~~~
>> ./include/linux/syscalls.h:222:2: note: in expansion of macro '__SYSCALL_DEFINEx'
>> __SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
>> ^~~~~~~~~~~~~~~~~
>> ./include/linux/syscalls.h:216:36: note: in expansion of macro 'SYSCALL_DEFINEx'
>> #define SYSCALL_DEFINE6(name, ...) SYSCALL_DEFINEx(6, _##name, __VA_ARGS__)
>> ^~~~~~~~~~~~~~~
>> arch/powerpc/kernel/syscalls.c:72:1: note: in expansion of macro 'SYSCALL_DEFINE6'
>> SYSCALL_DEFINE6(mmap, unsigned long, addr, size_t, len,
>> ^~~~~~~~~~~~~~~
>> CC arch/powerpc/kernel/signal_32.o
>> In file included from arch/powerpc/kernel/signal_32.c:31:
>> ./include/linux/compat.h:74:18: error: 'compat_sys_swapcontext' alias between functions of incompatible types 'long int(struct ucontext32 *, struct ucontext32 *, int)' and 'long int(long int, long int, long int)' [-Werror=attribute-alias]
>> asmlinkage long compat_sys##name(__MAP(x,__SC_DECL,__VA_ARGS__)) \
>> ^~~~~~~~~~
>> ./include/linux/compat.h:58:2: note: in expansion of macro 'COMPAT_SYSCALL_DEFINEx'
>> COMPAT_SYSCALL_DEFINEx(3, _##name, __VA_ARGS__)
>> ^~~~~~~~~~~~~~~~~~~~~~
>> arch/powerpc/kernel/signal_32.c:1041:1: note: in expansion of macro 'COMPAT_SYSCALL_DEFINE3'
>> COMPAT_SYSCALL_DEFINE3(swapcontext, struct ucontext __user *, old_ctx,
>> ^~~~~~~~~~~~~~~~~~~~~~
>> ./include/linux/compat.h:79:18: note: aliased declaration here
>> asmlinkage long __se_compat_sys##name(__MAP(x,__SC_LONG,__VA_ARGS__)) \
>> ^~~~~~~~~~~~~~~
>> ./include/linux/compat.h:58:2: note: in expansion of macro 'COMPAT_SYSCALL_DEFINEx'
>> COMPAT_SYSCALL_DEFINEx(3, _##name, __VA_ARGS__)
>> ^~~~~~~~~~~~~~~~~~~~~~
>> arch/powerpc/kernel/signal_32.c:1041:1: note: in expansion of macro 'COMPAT_SYSCALL_DEFINE3'
>> COMPAT_SYSCALL_DEFINE3(swapcontext, struct ucontext __user *, old_ctx,
>> ^~~~~~~~~~~~~~~~~~~~~~
>> CC arch/powerpc/kernel/signal_64.o
>> In file included from arch/powerpc/kernel/signal_64.c:27:
>> ./include/linux/syscalls.h:233:18: error: 'sys_swapcontext' alias between functions of incompatible types 'long int(struct ucontext *, struct ucontext *, long int)' and 'long int(long int, long int, long int)' [-Werror=attribute-alias]
>> asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__)) \
>> ^~~
>> ./include/linux/syscalls.h:222:2: note: in expansion of macro '__SYSCALL_DEFINEx'
>> __SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
>> ^~~~~~~~~~~~~~~~~
>> ./include/linux/syscalls.h:213:36: note: in expansion of macro 'SYSCALL_DEFINEx'
>> #define SYSCALL_DEFINE3(name, ...) SYSCALL_DEFINEx(3, _##name, __VA_ARGS__)
>> ^~~~~~~~~~~~~~~
>> arch/powerpc/kernel/signal_64.c:628:1: note: in expansion of macro 'SYSCALL_DEFINE3'
>> SYSCALL_DEFINE3(swapcontext, struct ucontext __user *, old_ctx,
>> ^~~~~~~~~~~~~~~
>> ./include/linux/syscalls.h:238:18: note: aliased declaration here
>> asmlinkage long __se_sys##name(__MAP(x,__SC_LONG,__VA_ARGS__)) \
>> ^~~~~~~~
>> ./include/linux/syscalls.h:222:2: note: in expansion of macro '__SYSCALL_DEFINEx'
>> __SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
>> ^~~~~~~~~~~~~~~~~
>> ./include/linux/syscalls.h:213:36: note: in expansion of macro 'SYSCALL_DEFINEx'
>> #define SYSCALL_DEFINE3(name, ...) SYSCALL_DEFINEx(3, _##name, __VA_ARGS__)
>> ^~~~~~~~~~~~~~~
>> arch/powerpc/kernel/signal_64.c:628:1: note: in expansion of macro 'SYSCALL_DEFINE3'
>> SYSCALL_DEFINE3(swapcontext, struct ucontext __user *, old_ctx,
>> ^~~~~~~~~~~~~~~
>> CC arch/powerpc/kernel/rtas.o
>> In file included from arch/powerpc/kernel/rtas.c:29:
>> ./include/linux/syscalls.h:233:18: error: 'sys_rtas' alias between functions of incompatible types 'long int(struct rtas_args *)' and 'long int(long int)' [-Werror=attribute-alias]
>> asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__)) \
>> ^~~
>> ./include/linux/syscalls.h:222:2: note: in expansion of macro '__SYSCALL_DEFINEx'
>> __SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
>> ^~~~~~~~~~~~~~~~~
>> ./include/linux/syscalls.h:211:36: note: in expansion of macro 'SYSCALL_DEFINEx'
>> #define SYSCALL_DEFINE1(name, ...) SYSCALL_DEFINEx(1, _##name, __VA_ARGS__)
>> ^~~~~~~~~~~~~~~
>> arch/powerpc/kernel/rtas.c:1054:1: note: in expansion of macro 'SYSCALL_DEFINE1'
>> SYSCALL_DEFINE1(rtas, struct rtas_args __user *, uargs)
>> ^~~~~~~~~~~~~~~
>> ./include/linux/syscalls.h:238:18: note: aliased declaration here
>> asmlinkage long __se_sys##name(__MAP(x,__SC_LONG,__VA_ARGS__)) \
>> ^~~~~~~~
>> ./include/linux/syscalls.h:222:2: note: in expansion of macro '__SYSCALL_DEFINEx'
>> __SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
>> ^~~~~~~~~~~~~~~~~
>> ./include/linux/syscalls.h:211:36: note: in expansion of macro 'SYSCALL_DEFINEx'
>> #define SYSCALL_DEFINE1(name, ...) SYSCALL_DEFINEx(1, _##name, __VA_ARGS__)
>> ^~~~~~~~~~~~~~~
>> arch/powerpc/kernel/rtas.c:1054:1: note: in expansion of macro 'SYSCALL_DEFINE1'
>> SYSCALL_DEFINE1(rtas, struct rtas_args __user *, uargs)
>> ^~~~~~~~~~~~~~~
>> CC arch/powerpc/kernel/pci_64.o
>> In file included from arch/powerpc/kernel/pci_64.c:23:
>> ./include/linux/syscalls.h:233:18: error: 'sys_pciconfig_iobase' alias between functions of incompatible types 'long int(long int, long unsigned int, long unsigned int)' and 'long int(long int, long int, long int)' [-Werror=attribute-alias]
>> asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__)) \
>> ^~~
>> ./include/linux/syscalls.h:222:2: note: in expansion of macro '__SYSCALL_DEFINEx'
>> __SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
>> ^~~~~~~~~~~~~~~~~
>> ./include/linux/syscalls.h:213:36: note: in expansion of macro 'SYSCALL_DEFINEx'
>> #define SYSCALL_DEFINE3(name, ...) SYSCALL_DEFINEx(3, _##name, __VA_ARGS__)
>> ^~~~~~~~~~~~~~~
>> arch/powerpc/kernel/pci_64.c:206:1: note: in expansion of macro 'SYSCALL_DEFINE3'
>> SYSCALL_DEFINE3(pciconfig_iobase, long, which, unsigned long, in_bus,
>> ^~~~~~~~~~~~~~~
>> ./include/linux/syscalls.h:238:18: note: aliased declaration here
>> asmlinkage long __se_sys##name(__MAP(x,__SC_LONG,__VA_ARGS__)) \
>> ^~~~~~~~
>> ./include/linux/syscalls.h:222:2: note: in expansion of macro '__SYSCALL_DEFINEx'
>> __SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
>> ^~~~~~~~~~~~~~~~~
>> ./include/linux/syscalls.h:213:36: note: in expansion of macro 'SYSCALL_DEFINEx'
>> #define SYSCALL_DEFINE3(name, ...) SYSCALL_DEFINEx(3, _##name, __VA_ARGS__)
>> ^~~~~~~~~~~~~~~
>> arch/powerpc/kernel/pci_64.c:206:1: note: in expansion of macro 'SYSCALL_DEFINE3'
>> SYSCALL_DEFINE3(pciconfig_iobase, long, which, unsigned long, in_bus,
>> ^~~~~~~~~~~~~~~
>>
>> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
>
> Applied to powerpc next, thanks.
>
> https://git.kernel.org/powerpc/c/2479bfc9bc600dcce7f932d52dcfa8
Oops, you didn't take v4 but v3 which was missing the fix into pci_32.c
I'll send you a patch to add the fix in pci_32.c
Christophe
>
> cheers
>
^ permalink raw reply
* [PATCH] powerpc: fix build failure by disabling attribute-alias warning in pci_32
From: Christophe Leroy @ 2018-06-05 6:57 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: linux-kernel, linuxppc-dev
Commit 2479bfc9bc600 ("powerpc: Fix build by disabling attribute-alias
warning for SYSCALL_DEFINEx") forgot arch/powerpc/kernel/pci_32.c
Latest GCC version emit the following warnings
As arch/powerpc code is built with -Werror, this breaks build with
GCC 8.1
This patch inhibits this warning
In file included from arch/powerpc/kernel/pci_32.c:14:
./include/linux/syscalls.h:233:18: error: 'sys_pciconfig_iobase' alias between functions of incompatible types 'long int(long int, long unsigned int, long unsigned int)' and 'long int(long int, long int, long int)' [-Werror=attribute-alias]
asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__)) \
^~~
./include/linux/syscalls.h:222:2: note: in expansion of macro '__SYSCALL_DEFINEx'
__SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
^~~~~~~~~~~~~~~~~
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
---
arch/powerpc/kernel/pci_32.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/powerpc/kernel/pci_32.c b/arch/powerpc/kernel/pci_32.c
index d63b488d34d7..4f861055a852 100644
--- a/arch/powerpc/kernel/pci_32.c
+++ b/arch/powerpc/kernel/pci_32.c
@@ -285,6 +285,9 @@ pci_bus_to_hose(int bus)
* Note that the returned IO or memory base is a physical address
*/
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wpragmas"
+#pragma GCC diagnostic ignored "-Wattribute-alias"
SYSCALL_DEFINE3(pciconfig_iobase, long, which,
unsigned long, bus, unsigned long, devfn)
{
@@ -310,3 +313,4 @@ SYSCALL_DEFINE3(pciconfig_iobase, long, which,
return result;
}
+#pragma GCC diagnostic pop
--
2.13.3
^ permalink raw reply related
* Re: [RFC PATCH for 4.18 09/16] powerpc: Add syscall detection for restartable sequences
From: Michael Ellerman @ 2018-06-05 5:21 UTC (permalink / raw)
To: Mathieu Desnoyers, Peter Zijlstra, Paul E . McKenney, Boqun Feng,
Andy Lutomirski, Dave Watson
Cc: linux-kernel, linux-api, Paul Turner, Andrew Morton, Russell King,
Thomas Gleixner, Ingo Molnar, H . Peter Anvin, Andrew Hunter,
Andi Kleen, Chris Lameter, Ben Maurer, Steven Rostedt,
Josh Triplett, Linus Torvalds, Catalin Marinas, Will Deacon,
Michael Kerrisk, Joel Fernandes, Mathieu Desnoyers,
Benjamin Herrenschmidt, Paul Mackerras, linuxppc-dev
In-Reply-To: <20180602124408.8430-10-mathieu.desnoyers@efficios.com>
Mathieu Desnoyers <mathieu.desnoyers@efficios.com> writes:
> From: Boqun Feng <boqun.feng@gmail.com>
>
> Syscalls are not allowed inside restartable sequences, so add a call to
> rseq_syscall() at the very beginning of system call exiting path for
> CONFIG_DEBUG_RSEQ=y kernel. This could help us to detect whether there
> is a syscall issued inside restartable sequences.
>
> [ Tested on 64-bit powerpc kernel by Mathieu Desnoyers. Still needs to
> be tested on 32-bit powerpc kernel. ]
>
> Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
> CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> CC: Paul Mackerras <paulus@samba.org>
> CC: Michael Ellerman <mpe@ellerman.id.au>
> CC: Peter Zijlstra <peterz@infradead.org>
> CC: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
> CC: linuxppc-dev@lists.ozlabs.org
> ---
> arch/powerpc/kernel/entry_32.S | 7 +++++++
> arch/powerpc/kernel/entry_64.S | 8 ++++++++
> 2 files changed, 15 insertions(+)
I don't _love_ the #ifdefs in here, but they look correct and there's
not really a better option until we rewrite the syscall handler in C.
The rseq selftests passed for me with this applied and enabled. So if
you like here's some tags:
Tested-by: Michael Ellerman <mpe@ellerman.id.au>
Acked-by: Michael Ellerman <mpe@ellerman.id.au>
cheers
^ permalink raw reply
* Re: [RFC PATCH for 4.18 10/16] powerpc: Wire up restartable sequences system call
From: Michael Ellerman @ 2018-06-05 5:18 UTC (permalink / raw)
To: Mathieu Desnoyers, Peter Zijlstra, Paul E . McKenney, Boqun Feng,
Andy Lutomirski, Dave Watson
Cc: linux-kernel, linux-api, Paul Turner, Andrew Morton, Russell King,
Thomas Gleixner, Ingo Molnar, H . Peter Anvin, Andrew Hunter,
Andi Kleen, Chris Lameter, Ben Maurer, Steven Rostedt,
Josh Triplett, Linus Torvalds, Catalin Marinas, Will Deacon,
Michael Kerrisk, Joel Fernandes, Mathieu Desnoyers,
Benjamin Herrenschmidt, Paul Mackerras, linuxppc-dev
In-Reply-To: <20180602124408.8430-11-mathieu.desnoyers@efficios.com>
Mathieu Desnoyers <mathieu.desnoyers@efficios.com> writes:
> From: Boqun Feng <boqun.feng@gmail.com>
>
> Wire up the rseq system call on powerpc.
>
> This provides an ABI improving the speed of a user-space getcpu
> operation on powerpc by skipping the getcpu system call on the fast
> path, as well as improving the speed of user-space operations on per-cpu
> data compared to using load-reservation/store-conditional atomics.
>
> Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
> CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> CC: Paul Mackerras <paulus@samba.org>
> CC: Michael Ellerman <mpe@ellerman.id.au>
> CC: Peter Zijlstra <peterz@infradead.org>
> CC: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
> CC: linuxppc-dev@lists.ozlabs.org
> ---
> arch/powerpc/include/asm/systbl.h | 1 +
> arch/powerpc/include/asm/unistd.h | 2 +-
> arch/powerpc/include/uapi/asm/unistd.h | 1 +
> 3 files changed, 3 insertions(+), 1 deletion(-)
Looks fine to me.
I don't have any other new syscalls in my next, so this should not
conflict with anything for 4.18.
Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
cheers
^ permalink raw reply
* Re: [RFC V2] virtio: Add platform specific DMA API translation for virito devices
From: Christoph Hellwig @ 2018-06-05 4:52 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Michael S. Tsirkin, Anshuman Khandual, virtualization,
linux-kernel, linuxppc-dev, aik, robh, joe, elfring, david,
jasowang, mpe, hch, luto
In-Reply-To: <6164442a718645a754879eac5c4c5fad9283c211.camel@kernel.crashing.org>
On Tue, Jun 05, 2018 at 09:26:56AM +1000, Benjamin Herrenschmidt wrote:
> Sorry Michael, that doesn't click. Yes of course virtio is implemented
> in qemu, but the problem we are trying to solve is *not* a qemu problem
> (the fact that the Linux drivers bypass the DMA API is wrong, needs
> fixing, and isnt a qemu problem). The fact that the secure guests need
> bounce buffering is not a qemu problem either.
>
> Whether qemu chose to use an iommu or not is, and should remain an
> orthogonal problem.
Agreed. We have a problem with qemu (old qemu only?) punching a hole
into the VM abstraction by deciding that even if firmware tables
claim use of an IOMMU for a PCI bus it expects virtio to use physiscal
addresses. So far so bad. The answer to that should have been to
quirk the affected qemu versions and move on. Instead we now have
virtio not use the DMA API by default and are creating a worse problem.
Let's fix this issue ASAP and quirk the buggy implementations instead
of letting everyone else suffer.
> The DMA API itself isn't the one that needs to learn "per-device
> quirks", it's just plumbing into arch backends. The "quirk" is at the
> point of establishing the backend for a given device.
>
> We can go a good way down that path simply by having virtio in Linux
> start with putting *itself* its own direct ops in there when
> VIRTIO_F_IOMMU_PLATFORM is not set, and removing all the special casing
> in the rest of the driver.
Yes. And we have all the infrastructure for that now. A few RDMA
drivers quirk to virt_dma_ops, and virtio could quirk to dma_direct_ops
anytime now. In fact given how much time we are spending arguing here
I'm going to give it a spin today.
> Once that's done, we have a single point of establishing the dma ops,
> we can quirk in there if needed, that's rather nicely contained, or put
> an arch hook, or whatever is necessary.
Yes.
^ permalink raw reply
* Re: [PATCH v7 0/5] powerpc/64: memcmp() optimization
From: Simon Guo @ 2018-06-04 10:27 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Paul Mackerras, Naveen N. Rao, Cyril Bur
In-Reply-To: <877eneasg9.fsf@concordia.ellerman.id.au>
Hi Michael,
On Tue, Jun 05, 2018 at 12:16:22PM +1000, Michael Ellerman wrote:
> Hi Simon,
>
> wei.guo.simon@gmail.com writes:
> > From: Simon Guo <wei.guo.simon@gmail.com>
> >
> > There is some room to optimize memcmp() in powerpc 64 bits version for
> > following 2 cases:
> > (1) Even src/dst addresses are not aligned with 8 bytes at the beginning,
> > memcmp() can align them and go with .Llong comparision mode without
> > fallback to .Lshort comparision mode do compare buffer byte by byte.
> > (2) VMX instructions can be used to speed up for large size comparision,
> > currently the threshold is set for 4K bytes. Notes the VMX instructions
> > will lead to VMX regs save/load penalty. This patch set includes a
> > patch to add a 32 bytes pre-checking to minimize the penalty.
> >
> > It did the similar with glibc commit dec4a7105e (powerpc: Improve memcmp
> > performance for POWER8). Thanks Cyril Bur's information.
> > This patch set also updates memcmp selftest case to make it compiled and
> > incorporate large size comparison case.
>
> I'm seeing a few crashes with this applied, I haven't had time to look
> into what is happening yet, sorry.
Sorry I didn't catch this in my testing. I will check the root cause
and update later.
Thanks,
- Simon
>
> [ 2471.300595] kselftest: Running tests in user
> [ 2471.302785] calling test_user_copy_init+0x0/0xd14 [test_user_copy] @ 44883
> [ 2471.302892] Unable to handle kernel paging request for data at address 0xc008000018553005
> [ 2471.303014] Faulting instruction address: 0xc00000000001f29c
> [ 2471.303119] Oops: Kernel access of bad area, sig: 11 [#1]
> [ 2471.303193] LE SMP NR_CPUS=2048 NUMA PowerNV
> [ 2471.303256] Modules linked in: test_user_copy(+) vxlan ip6_udp_tunnel udp_tunnel 8021q bridge stp llc dummy test_printf test_firmware vmx_crypto crct10dif_vpmsum crct10dif_common crc32c_vpmsum veth [last unloaded: test_static_key_base]
> [ 2471.303532] CPU: 4 PID: 44883 Comm: modprobe Tainted: G W 4.17.0-rc3-gcc7x-g7204012 #1
> [ 2471.303644] NIP: c00000000001f29c LR: c00000000001f6e4 CTR: 0000000000000000
> [ 2471.303754] REGS: c000001fddc2b560 TRAP: 0300 Tainted: G W (4.17.0-rc3-gcc7x-g7204012)
> [ 2471.303873] MSR: 9000000002009033 <SF,HV,VEC,EE,ME,IR,DR,RI,LE> CR: 24222844 XER: 00000000
> [ 2471.303996] CFAR: c00000000001f6e0 DAR: c008000018553005 DSISR: 40000000 IRQMASK: 0
> [ 2471.303996] GPR00: c00000000001f6e4 c000001fddc2b7e0 c008000018529900 0000000002000000
> [ 2471.303996] GPR04: c000001fe4b90020 000000000000ffe0 0000000000000000 03fffffe01b48000
> [ 2471.303996] GPR08: 0000000080000000 c008000018553005 c000001fddc28000 c008000018520df0
> [ 2471.303996] GPR12: c00000000009c430 c000001fffffbc00 0000000020000000 0000000000000000
> [ 2471.303996] GPR16: c000001fddc2bc20 0000000000000030 c0000000001f7ba0 0000000000000001
> [ 2471.303996] GPR20: 0000000000000000 c000000000c772b0 c0000000010b4018 0000000000000000
> [ 2471.303996] GPR24: 0000000000000000 c008000018521c98 0000000000000000 c000001fe4b90000
> [ 2471.303996] GPR28: fffffffffffffff4 0000000002000000 9000000002009033 9000000002009033
> [ 2471.304930] NIP [c00000000001f29c] msr_check_and_set+0x3c/0xc0
> [ 2471.305008] LR [c00000000001f6e4] enable_kernel_altivec+0x44/0x100
> [ 2471.305084] Call Trace:
> [ 2471.305122] [c000001fddc2b7e0] [c00000000009baa8] __copy_tofrom_user_base+0x9c/0x574 (unreliable)
> [ 2471.305240] [c000001fddc2b860] [c00000000001f6e4] enable_kernel_altivec+0x44/0x100
> [ 2471.305336] [c000001fddc2b890] [c00000000009ce40] enter_vmx_ops+0x50/0x70
> [ 2471.305418] [c000001fddc2b8b0] [c00000000009c768] memcmp+0x338/0x680
> [ 2471.305501] [c000001fddc2b9b0] [c008000018520190] test_user_copy_init+0x188/0xd14 [test_user_copy]
> [ 2471.305617] [c000001fddc2ba60] [c00000000000de20] do_one_initcall+0x90/0x560
> [ 2471.305710] [c000001fddc2bb30] [c000000000200630] do_init_module+0x90/0x260
> [ 2471.305795] [c000001fddc2bbc0] [c0000000001fec88] load_module+0x1a28/0x1ce0
> [ 2471.305875] [c000001fddc2bd70] [c0000000001ff1e8] sys_finit_module+0xc8/0x110
> [ 2471.305983] [c000001fddc2be30] [c00000000000b528] system_call+0x58/0x6c
> [ 2471.306066] Instruction dump:
> [ 2471.306112] fba1ffe8 fbc1fff0 fbe1fff8 f8010010 f821ff81 7c7d1b78 60000000 60000000
> [ 2471.306216] 7fe000a6 3d220003 39299705 7ffeeb78 <89290000> 2f890000 419e0044 60000000
> [ 2471.306326] ---[ end trace daf8d409e65b9841 ]---
>
> And:
>
> [ 19.096709] test_bpf: test_skb_segment: success in skb_segment!
> [ 19.096799] initcall test_bpf_init+0x0/0xae0 [test_bpf] returned 0 after 591217 usecs
> [ 19.115869] calling test_user_copy_init+0x0/0xd14 [test_user_copy] @ 3159
> [ 19.116165] Unable to handle kernel paging request for data at address 0xd000000003852805
> [ 19.116352] Faulting instruction address: 0xc00000000001f44c
> [ 19.116483] Oops: Kernel access of bad area, sig: 11 [#1]
> [ 19.116583] LE SMP NR_CPUS=2048 NUMA pSeries
> [ 19.116684] Modules linked in: test_user_copy(+) lzo_compress crc_itu_t zstd_compress zstd_decompress test_bpf test_static_keys test_static_key_base xxhash test_firmware af_key cls_bpf act_bpf bridge nf_nat_irc xt_NFLOG nfnetlink_log xt_policy nf_conntrack_netlink nfnetlink xt_nat nf_conntrack_irc xt_mark xt_tcpudp nf_nat_sip xt_TCPMSS xt_LOG nf_nat_ftp nf_conntrack_ftp xt_conntrack nf_conntrack_sip xt_addrtype xt_state 8021q iptable_filter ipt_MASQUERADE nf_log_ipv4 iptable_mangle nf_nat_masquerade_ipv4 ipt_REJECT nf_reject_ipv4 iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack ip_tables x_tables nf_log_arp nf_log_common ah4 ipcomp xfrm4_tunnel esp4 rpcrdma stp p8022 psnap llc xfrm_ipcomp xfrm_user xfrm_algo platform_lcd lcd ocxl virtio_balloon virtio_crypto crypto_engine
> [ 19.118040] vmx_crypto nbd zram zsmalloc virtio_blk st be2iscsi cxgb3i cxgb4i libcxgbi bnx2i ibmvfc sym53c8xx scsi_transport_spi scsi_dh_alua scsi_dh_rdac qla4xxx mpt3sas scsi_transport_sas cxlflash cxl libiscsi_tcp lpfc crc_t10dif crct10dif_generic crct10dif_common qla2xxx iscsi_boot_sysfs raid_class parport_pc parport powernv_op_panel powernv_rng pseries_rng rng_core virtio_console pcspkr input_leds evdev dm_round_robin dm_mirror dm_region_hash dm_log raid10 dm_service_time multipath dm_queue_length dm_multipath dm_thin_pool faulty dm_persistent_data dm_zero dm_crypt dm_bio_prison dm_snapshot dm_bufio raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq rpadlpar_io rpaphp jsm icom hvcs ib_ipoib ib_srp ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_ucm ib_ucm ib_uverbs
> [ 19.119505] rdma_cm iw_cm ib_cm mlx4_ib iw_cxgb3 iw_cxgb4 ib_mthca ib_core leds_powernv led_class vhost_net vhost macvtap macvlan dummy bsd_comp ppp_async crc_ccitt pppoe ppp_synctty pppox ppp_deflate ppp_generic 3c59x s2io bnx2 cnic uio bnx2x libcrc32c i40e ixgbe ixgb cxgb3 libcxgb cxgb cxgb4 pcnet32 netxen_nic qlge be2net acenic mlx4_en mlx4_core myri10ge bonding slhc tap mdio veth vxlan udp_tunnel tun usb_storage usbmon oprofile sha1_powerpc md5_ppc crc32c_vpmsum kvm hvcserver
> [ 19.120358] CPU: 4 PID: 3159 Comm: modprobe Not tainted 4.17.0-rc3-gcc7x-g7204012 #1
> [ 19.120508] NIP: c00000000001f44c LR: c00000000001f894 CTR: 0000000000000000
> [ 19.120666] REGS: c0000000f8d9f570 TRAP: 0300 Not tainted (4.17.0-rc3-gcc7x-g7204012)
> [ 19.120817] MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 24222844 XER: 00000000
> [ 19.120984] CFAR: c00000000000c03c DAR: d000000003852805 DSISR: 40000000 IRQMASK: 0
> GPR00: c00000000001f894 c0000000f8d9f7f0 d000000003829900 0000000002000000
> GPR04: c0000000f9a30048 000000000000ffe0 0000000000000000 03fffffff065dffd
> GPR08: 0000000080000000 d000000003852805 c0000000f8d9c000 d000000003820df0
> GPR12: c00000000009ebb0 c00000003fffb300 c0000000f8d9fd90 d000000003840000
> GPR16: d000000003840000 0000000000000000 c0000000011d6900 d000000003821ad0
> GPR20: c000000000bd7860 0000000000000000 c000000000ff9060 00000000014000c0
> GPR24: 0000000000000000 0000000000000000 0000000000000100 c0000000f9a30028
> GPR28: fffffffffffffff4 0000000002000000 8000000002009033 8000000000009033
> [ 19.122454] NIP [c00000000001f44c] msr_check_and_set+0x3c/0xc0
> [ 19.122580] LR [c00000000001f894] enable_kernel_altivec+0x44/0x100
> [ 19.122707] Call Trace:
> [ 19.122789] [c0000000f8d9f7f0] [c00000000009e228] __copy_tofrom_user_base+0x9c/0x574 (unreliable)
> [ 19.122962] [c0000000f8d9f870] [c00000000001f894] enable_kernel_altivec+0x44/0x100
> [ 19.123344] [c0000000f8d9f8a0] [c00000000009f740] enter_vmx_ops+0x50/0x70
> [ 19.123583] [c0000000f8d9f8c0] [c00000000009eee8] memcmp+0x338/0x680
> [ 19.123728] [c0000000f8d9f9c0] [d000000003820190] test_user_copy_init+0x188/0xd14 [test_user_copy]
> [ 19.123909] [c0000000f8d9fa70] [c00000000000e37c] do_one_initcall+0x5c/0x2d0
> [ 19.124094] [c0000000f8d9fb30] [c00000000020066c] do_init_module+0x90/0x264
> [ 19.124234] [c0000000f8d9fbc0] [c0000000001ff084] load_module+0x2f64/0x3600
> [ 19.124371] [c0000000f8d9fd70] [c0000000001ff9c8] sys_finit_module+0xc8/0x110
> [ 19.124530] [c0000000f8d9fe30] [c00000000000b868] system_call+0x58/0x6c
> [ 19.124648] Instruction dump:
> [ 19.124721] fba1ffe8 fbc1fff0 fbe1fff8 f8010010 f821ff81 7c7d1b78 60000000 60000000
> [ 19.124869] 7fe000a6 3d220003 39298f05 7ffeeb78 <89290000> 2f890000 419e0044 60000000
> [ 19.125034] ---[ end trace 7c08acedd4b4e6aa ]---
>
>
> 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