* Re: [PATCH] powerpc/xive: Use the "ibm, chip-id" property only under PowerNV
From: Michael Ellerman @ 2021-04-19 4:00 UTC (permalink / raw)
To: Cédric Le Goater, linuxppc-dev
In-Reply-To: <20210413130352.1183267-1-clg@kaod.org>
On Tue, 13 Apr 2021 15:03:52 +0200, Cédric Le Goater wrote:
> The 'chip_id' field of the XIVE CPU structure is used to choose a
> target for a source located on the same chip. For that, the XIVE
> driver queries the chip identifier from the "ibm,chip-id" property
> and compares it to a 'src_chip' field identifying the chip of a
> source. This information is only available on the PowerNV platform,
> 'src_chip' being assigned to XIVE_INVALID_CHIP_ID under pSeries.
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/xive: Use the "ibm, chip-id" property only under PowerNV
https://git.kernel.org/powerpc/c/e9e16917bc388846163b8566a298a291d71e44c9
cheers
^ permalink raw reply
* Re: [PATCH v2 1/9] powerpc/mem: Move cache flushing functions into mm/cacheflush.c
From: Michael Ellerman @ 2021-04-19 4:00 UTC (permalink / raw)
To: Paul Mackerras, Benjamin Herrenschmidt, Christophe Leroy,
Michael Ellerman
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <7bf6f1600acad146e541a4e220940062f2e5b03d.1617895813.git.christophe.leroy@csgroup.eu>
On Thu, 8 Apr 2021 15:30:24 +0000 (UTC), Christophe Leroy wrote:
> Cache flushing functions are in the middle of completely
> unrelated stuff in mm/mem.c
>
> Create a dedicated mm/cacheflush.c for those functions.
>
> Also cleanup the list of included headers.
Applied to powerpc/next.
[1/9] powerpc/mem: Move cache flushing functions into mm/cacheflush.c
https://git.kernel.org/powerpc/c/b26e8f27253a47bff90972b987112fd8396e9b8d
[2/9] powerpc/mem: Declare __flush_dcache_icache() static
https://git.kernel.org/powerpc/c/bf26e0bbd2f82b52605cd7c880245eefe67e09f3
[3/9] powerpc/mem: Remove address argument to flush_coherent_icache()
https://git.kernel.org/powerpc/c/131637a17dc97fde3d007ab224e30c7ff4e62f6e
[4/9] powerpc/mem: Call flush_coherent_icache() at higher level
https://git.kernel.org/powerpc/c/e618c7aea1f2a2d615a99948f1f5cb4c11b6bf57
[5/9] powerpc/mem: Optimise flush_dcache_icache_hugepage()
https://git.kernel.org/powerpc/c/cd97d9e8b5aa45a7f867a10e99f1d6ce0a5deb8b
[6/9] powerpc/mem: flush_dcache_icache_phys() is for HIGHMEM pages only
https://git.kernel.org/powerpc/c/52d490437ffb1bab0a63ab7b1a64514d8c17dd4d
[7/9] powerpc/mem: Help GCC realise __flush_dcache_icache() flushes single pages
https://git.kernel.org/powerpc/c/67b8e6af191a6ed717be548307eb15048f8181d8
[8/9] powerpc/mem: Inline flush_dcache_page()
https://git.kernel.org/powerpc/c/6c96020882b17fb6f4fbf7f8cef8c606460fc14d
[9/9] powerpc/mem: Use kmap_local_page() in flushing functions
https://git.kernel.org/powerpc/c/7e9ab144c128df7660a2f33c9c6d1422fe798060
cheers
^ permalink raw reply
* Re: [PATCH RESEND v1 0/4] powerpc/vdso: Add support for time namespaces
From: Michael Ellerman @ 2021-04-19 4:00 UTC (permalink / raw)
To: Paul Mackerras, Benjamin Herrenschmidt, Christophe Leroy,
Michael Ellerman
Cc: linux-arch, arnd, dima, linux-kernel, avagin, luto, tglx,
vincenzo.frascino, linuxppc-dev
In-Reply-To: <cover.1617209141.git.christophe.leroy@csgroup.eu>
On Wed, 31 Mar 2021 16:48:43 +0000 (UTC), Christophe Leroy wrote:
> [Sorry, resending with complete destination list, I used the wrong script on the first delivery]
>
> This series adds support for time namespaces on powerpc.
>
> All timens selftests are successfull.
>
> Christophe Leroy (3):
> lib/vdso: Mark do_hres_timens() and do_coarse_timens()
> __always_inline()
> lib/vdso: Add vdso_data pointer as input to
> __arch_get_timens_vdso_data()
> powerpc/vdso: Add support for time namespaces
>
> [...]
Applied to powerpc/next.
[1/4] lib/vdso: Mark do_hres_timens() and do_coarse_timens() __always_inline()
https://git.kernel.org/powerpc/c/58efe9f696cf908f40d6672aeca81cb2ad2bc762
[2/4] lib/vdso: Add vdso_data pointer as input to __arch_get_timens_vdso_data()
https://git.kernel.org/powerpc/c/808094fcbf4196be0feb17afbbdc182ec95c8cec
[3/4] powerpc/vdso: Separate vvar vma from vdso
https://git.kernel.org/powerpc/c/1c4bce6753857dc409a0197342d18764e7f4b741
[4/4] powerpc/vdso: Add support for time namespaces
https://git.kernel.org/powerpc/c/74205b3fc2effde821b219d955c70e727dc43cc6
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/signal32: Fix build failure with CONFIG_SPE
From: Michael Ellerman @ 2021-04-19 3:59 UTC (permalink / raw)
To: Paul Mackerras, Benjamin Herrenschmidt, Christophe Leroy,
Michael Ellerman, linux
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <aad2cb1801a3cc99bc27081022925b9fc18a0dfb.1618159169.git.christophe.leroy@csgroup.eu>
On Sun, 11 Apr 2021 16:39:53 +0000 (UTC), Christophe Leroy wrote:
> Add missing fault exit label in unsafe_copy_from_user() in order to
> avoid following build failure with CONFIG_SPE
>
> CC arch/powerpc/kernel/signal_32.o
> arch/powerpc/kernel/signal_32.c: In function 'restore_user_regs':
> arch/powerpc/kernel/signal_32.c:565:36: error: macro "unsafe_copy_from_user" requires 4 arguments, but only 3 given
> 565 | ELF_NEVRREG * sizeof(u32));
> | ^
> In file included from ./include/linux/uaccess.h:11,
> from ./include/linux/sched/task.h:11,
> from ./include/linux/sched/signal.h:9,
> from ./include/linux/rcuwait.h:6,
> from ./include/linux/percpu-rwsem.h:7,
> from ./include/linux/fs.h:33,
> from ./include/linux/huge_mm.h:8,
> from ./include/linux/mm.h:707,
> from arch/powerpc/kernel/signal_32.c:17:
> ./arch/powerpc/include/asm/uaccess.h:428: note: macro "unsafe_copy_from_user" defined here
> 428 | #define unsafe_copy_from_user(d, s, l, e) \
> |
> arch/powerpc/kernel/signal_32.c:564:3: error: 'unsafe_copy_from_user' undeclared (first use in this function); did you mean 'raw_copy_from_user'?
> 564 | unsafe_copy_from_user(current->thread.evr, &sr->mc_vregs,
> | ^~~~~~~~~~~~~~~~~~~~~
> | raw_copy_from_user
> arch/powerpc/kernel/signal_32.c:564:3: note: each undeclared identifier is reported only once for each function it appears in
> make[3]: *** [arch/powerpc/kernel/signal_32.o] Error 1
Applied to powerpc/next.
[1/1] powerpc/signal32: Fix build failure with CONFIG_SPE
https://git.kernel.org/powerpc/c/af072b1a9d4d9edc24da84a071b0671e147026cb
cheers
^ permalink raw reply
* Re: [PATCH 1/3] powerpc/modules: Load modules closer to kernel text
From: Michael Ellerman @ 2021-04-19 3:59 UTC (permalink / raw)
To: Paul Mackerras, Benjamin Herrenschmidt, jniethe5,
Christophe Leroy, Michael Ellerman
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <0c3d5cb8a4dfdf6ca1b8aeb385c01470d6628d55.1617283827.git.christophe.leroy@csgroup.eu>
On Thu, 1 Apr 2021 13:30:41 +0000 (UTC), Christophe Leroy wrote:
> On book3s/32, when STRICT_KERNEL_RWX is selected, modules are
> allocated on the segment just before kernel text, ie on the
> 0xb0000000-0xbfffffff when PAGE_OFFSET is 0xc0000000.
>
> On the 8xx, TASK_SIZE is 0x80000000. The space between TASK_SIZE and
> PAGE_OFFSET is not used and could be used for modules.
>
> [...]
Applied to powerpc/next.
[1/3] powerpc/modules: Load modules closer to kernel text
https://git.kernel.org/powerpc/c/2ec13df167040cd153c25c4d96d0ffc573ac4c40
[2/3] powerpc/8xx: Define a MODULE area below kernel text
https://git.kernel.org/powerpc/c/9132a2e82adc6e5a1c7c7385df3bfb25576bdd80
[3/3] powerpc/32s: Define a MODULE area below kernel text all the time
https://git.kernel.org/powerpc/c/80edc68e0479bafdc4869ec3351e42316b824596
cheers
^ permalink raw reply
* Re: [PATCH 2/2] hotplug-cpu.c: set UNISOLATE on dlpar_cpu_remove() failure
From: David Gibson @ 2021-04-19 4:02 UTC (permalink / raw)
To: Daniel Henrique Barboza; +Cc: linuxppc-dev
In-Reply-To: <20210416210216.380291-3-danielhb413@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2335 bytes --]
On Fri, Apr 16, 2021 at 06:02:16PM -0300, Daniel Henrique Barboza wrote:
> The RTAS set-indicator call, when attempting to UNISOLATE a DRC that is
> already UNISOLATED or CONFIGURED, returns RTAS_OK and does nothing else
> for both QEMU and phyp. This gives us an opportunity to use this
> behavior to signal the hypervisor layer when an error during device
> removal happens, allowing it to do a proper error handling, while not
> breaking QEMU/phyp implementations that don't have this support.
>
> This patch introduces this idea by unisolating all CPU DRCs that failed
> to be removed by dlpar_cpu_remove_by_index(), when handling the
> PSERIES_HP_ELOG_ID_DRC_INDEX event. This is being done for this event
> only because its the only CPU removal event QEMU uses, and there's no
> need at this moment to add this mechanism for phyp only code.
>
> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
except...
> ---
> arch/powerpc/platforms/pseries/hotplug-cpu.c | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/platforms/pseries/hotplug-cpu.c b/arch/powerpc/platforms/pseries/hotplug-cpu.c
> index 12cbffd3c2e3..ed66895c2f51 100644
> --- a/arch/powerpc/platforms/pseries/hotplug-cpu.c
> +++ b/arch/powerpc/platforms/pseries/hotplug-cpu.c
> @@ -802,8 +802,15 @@ int dlpar_cpu(struct pseries_hp_errorlog *hp_elog)
> case PSERIES_HP_ELOG_ACTION_REMOVE:
> if (hp_elog->id_type == PSERIES_HP_ELOG_ID_DRC_COUNT)
> rc = dlpar_cpu_remove_by_count(count);
> - else if (hp_elog->id_type == PSERIES_HP_ELOG_ID_DRC_INDEX)
> + else if (hp_elog->id_type == PSERIES_HP_ELOG_ID_DRC_INDEX) {
> rc = dlpar_cpu_remove_by_index(drc_index);
> + /* Setting the isolation state of an UNISOLATED/CONFIGURED
> + * device to UNISOLATE is a no-op, but the hypervison can
typo here s/hypervison/hypervisor/
> + * use it as a hint that the cpu removal failed.
> + */
> + if (rc)
> + dlpar_unisolate_drc(drc_index);
> + }
> else
> rc = -EINVAL;
> break;
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] dlpar.c: introduce dlpar_unisolate_drc()
From: David Gibson @ 2021-04-19 4:01 UTC (permalink / raw)
To: Daniel Henrique Barboza; +Cc: linuxppc-dev
In-Reply-To: <20210416210216.380291-2-danielhb413@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2196 bytes --]
On Fri, Apr 16, 2021 at 06:02:15PM -0300, Daniel Henrique Barboza wrote:
> Next patch will execute a set-indicator call in hotplug-cpu.c.
>
> Create a dlpar_unisolate_drc() helper to avoid spreading more
> rtas_set_indicator() calls outside of dlpar.c.
>
> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
> ---
> arch/powerpc/platforms/pseries/dlpar.c | 14 ++++++++++++++
> arch/powerpc/platforms/pseries/pseries.h | 1 +
> 2 files changed, 15 insertions(+)
>
> diff --git a/arch/powerpc/platforms/pseries/dlpar.c b/arch/powerpc/platforms/pseries/dlpar.c
> index 233503fcf8f0..3ac70790ec7a 100644
> --- a/arch/powerpc/platforms/pseries/dlpar.c
> +++ b/arch/powerpc/platforms/pseries/dlpar.c
> @@ -329,6 +329,20 @@ int dlpar_release_drc(u32 drc_index)
> return 0;
> }
>
> +int dlpar_unisolate_drc(u32 drc_index)
> +{
> + int dr_status, rc;
> +
> + rc = rtas_call(rtas_token("get-sensor-state"), 2, 2, &dr_status,
> + DR_ENTITY_SENSE, drc_index);
> + if (rc || dr_status != DR_ENTITY_PRESENT)
> + return -1;
> +
> + rtas_set_indicator(ISOLATION_STATE, drc_index, UNISOLATE);
> +
> + return 0;
> +}
> +
> int handle_dlpar_errorlog(struct pseries_hp_errorlog *hp_elog)
> {
> int rc;
> diff --git a/arch/powerpc/platforms/pseries/pseries.h b/arch/powerpc/platforms/pseries/pseries.h
> index 4fe48c04c6c2..4ea12037c920 100644
> --- a/arch/powerpc/platforms/pseries/pseries.h
> +++ b/arch/powerpc/platforms/pseries/pseries.h
> @@ -55,6 +55,7 @@ extern int dlpar_attach_node(struct device_node *, struct device_node *);
> extern int dlpar_detach_node(struct device_node *);
> extern int dlpar_acquire_drc(u32 drc_index);
> extern int dlpar_release_drc(u32 drc_index);
> +extern int dlpar_unisolate_drc(u32 drc_index);
>
> void queue_hotplug_event(struct pseries_hp_errorlog *hp_errlog);
> int handle_dlpar_errorlog(struct pseries_hp_errorlog *hp_errlog);
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 0/2] pseries: UNISOLATE DRCs to signal device removal error
From: David Gibson @ 2021-04-19 3:59 UTC (permalink / raw)
To: Daniel Henrique Barboza; +Cc: linuxppc-dev
In-Reply-To: <20210416210216.380291-1-danielhb413@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4958 bytes --]
On Fri, Apr 16, 2021 at 06:02:14PM -0300, Daniel Henrique Barboza wrote:
> At this moment, PAPR [1] does not have a way to report errors during a device
> removal operation. This puts a strain in the hypervisor, which needs extra
> mechanisms to try to fallback and recover from an error that might have
> happened during the removal. The QEMU community has dealt with it during these
> years by either trying to preempt the error before sending the HP event or, in
> case of a guest side failure, reboot the guest to complete the removal process.
>
> This started to change with QEMU commit fe1831eff8a4 ("spapr_drc.c: use DRC
> reconfiguration to cleanup DIMM unplug state"), where a way to fallback from a
> memory removal error was introduced. In this case, when QEMU detects that the
> kernel is reconfiguring LMBs DRCs that were marked as pending removal, the
> entire process is reverted from the QEMU side as well. Around the same time,
> other discussions in the QEMU mailing discussed an alternative for other device
> as well.
>
> In [2] the idea of using RTAS set-indicator for this role was first introduced.
> The RTAS set-indicator call, when attempting to UNISOLATE a DRC that is already
> UNISOLATED or CONFIGURED, returns RTAS_OK and does nothing else for both QEMU
> and phyp. This gives us an opportunity to use this behavior to signal the
> hypervisor layer when a device removal happens, allowing it to do a
> proper
Nit: it's not when a device removal happens, but when it *fails* to happen.
> error handling knowing for sure that the removal failed in the kernel. Using
> set-indicator to report HP errors isn't strange to PAPR, as per R1-13.5.3.4-4.
> of table 13.7 of [1]:
> "For all DR options: If this is a DR operation that involves the user insert-
> ing a DR entity, then if the firmware can determine that the inserted entity
> would cause a system disturbance, then the set-indicator RTAS call must not
> unisolate the entity and must return an error status which is unique to the
> particular error."
>
> PAPR does not make any restrictions or considerations about setting an already
> Unisolated/Configured DRC to 'unisolate', meaning we have a chance to use it
> for this purpose - signal an OS side error when attempting to remove a DR
> entity. To validate the design, this is being implemented only for CPUs.
>
> QEMU will use this mechanism to rollback the device removal (hotunplug) state,
> allowing for a better error handling mechanism. A implementation of how QEMU
> can do it is in [3]. When using a kernel with this series applied, together
> with this QEMU build, this is what happens in a common CPU removal/hotunplug
> error scenario (trying to remove the last online CPU):
>
> ( QEMU command line: qemu-system-ppc64 -machine pseries,accel=kvm,usb=off
> -smp 1,maxcpus=2,threads=1,cores=2,sockets=1 ... )
>
> [root@localhost ~]# QEMU 5.2.92 monitor - type 'help' for more information
> (qemu) device_add host-spapr-cpu-core,core-id=1,id=core1
> (qemu)
>
> [root@localhost ~]# echo 0 > /sys/devices/system/cpu/cpu0/online
> [ 77.548442][ T13] IRQ 19: no longer affine to CPU0
> [ 77.548452][ T13] IRQ 20: no longer affine to CPU0
> [ 77.548458][ T13] IRQ 256: no longer affine to CPU0
> [ 77.548465][ T13] IRQ 258: no longer affine to CPU0
> [ 77.548472][ T13] IRQ 259: no longer affine to CPU0
> [ 77.548479][ T13] IRQ 260: no longer affine to CPU0
> [ 77.548485][ T13] IRQ 261: no longer affine to CPU0
> [ 77.548590][ T0] cpu 0 (hwid 0) Ready to die...
> [root@localhost ~]# (qemu)
> (qemu) device_del core1
> (qemu) [ 83.214073][ T100] pseries-hotplug-cpu: Failed to offline CPU PowerPC,POWER9, rc: -16
> qemu-system-ppc64: Device hotunplug rejected by the guest for device core1
>
> (qemu)
>
> As soon as the CPU removal fails in dlpar_cpu(), QEMU becames aware of
> it and is able to do error recovery.
>
> If this solution is well received, I'll push for an architecture change
> request internally at IBM to make this mechanism PAPR official.
>
>
> [1] https://openpowerfoundation.org/wp-content/uploads/2020/07/LoPAR-20200611.pdf
> [2] https://lists.gnu.org/archive/html/qemu-devel/2021-02/msg06395.html
> [3] https://github.com/danielhb/qemu/tree/unisolate_drc_callback_v1
>
> Daniel Henrique Barboza (2):
> dlpar.c: introduce dlpar_unisolate_drc()
> hotplug-cpu.c: set UNISOLATE on dlpar_cpu_remove() failure
>
> arch/powerpc/platforms/pseries/dlpar.c | 14 ++++++++++++++
> arch/powerpc/platforms/pseries/hotplug-cpu.c | 9 ++++++++-
> arch/powerpc/platforms/pseries/pseries.h | 1 +
> 3 files changed, 23 insertions(+), 1 deletion(-)
>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [powerpc:topic/ppc-kvm] BUILD SUCCESS 732f21a3053cf279eb6b85d19b7818a8f1dd2071
From: kernel test robot @ 2021-04-19 3:44 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git topic/ppc-kvm
branch HEAD: 732f21a3053cf279eb6b85d19b7818a8f1dd2071 KVM: PPC: Book3S HV: Ensure MSR[HV] is always clear in guest MSR
elapsed time: 727m
configs tested: 15
configs skipped: 95
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
mips loongson1c_defconfig
m68k m5275evb_defconfig
arc nsimosci_hs_defconfig
powerpc mpc837x_rdb_defconfig
powerpc motionpro_defconfig
powerpc katmai_defconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
x86_64 allyesconfig
x86_64 rhel-8.3-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 rhel-8.3-kbuiltin
x86_64 kexec
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* Re: [PATCH V2] mm/page_alloc: Ensure that HUGETLB_PAGE_ORDER is less than MAX_ORDER
From: Anshuman Khandual @ 2021-04-19 3:45 UTC (permalink / raw)
To: David Hildenbrand, linux-mm, akpm
Cc: linux-ia64@vger.kernel.org, linuxppc-dev @ lists . ozlabs . org,
linux-kernel, Michal Hocko, Christoph Lameter, Mel Gorman,
Vlastimil Babka
In-Reply-To: <162877dd-e6ba-d465-d301-2956bb034429@redhat.com>
On 4/12/21 2:17 PM, David Hildenbrand wrote:
> On 12.04.21 10:06, Anshuman Khandual wrote:
>> + linuxppc-dev@lists.ozlabs.org
>> + linux-ia64@vger.kernel.org
>>
>> On 4/12/21 9:18 AM, Anshuman Khandual wrote:
>>> pageblock_order must always be less than MAX_ORDER, otherwise it might lead
>>> to an warning during boot. A similar problem got fixed on arm64 platform
>>> with the commit 79cc2ed5a716 ("arm64/mm: Drop THP conditionality from
>>> FORCE_MAX_ZONEORDER"). Assert the above condition before HUGETLB_PAGE_ORDER
>>> gets assigned as pageblock_order. This will help detect the problem earlier
>>> on platforms where HUGETLB_PAGE_SIZE_VARIABLE is enabled.
>>>
>>> Cc: David Hildenbrand <david@redhat.com>
>>> Cc: Andrew Morton <akpm@linux-foundation.org>
>>> Cc: linux-mm@kvack.org
>>> Cc: linux-kernel@vger.kernel.org
>>> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
>>> ---
>>> Changes in V2:
>>>
>>> - Changed WARN_ON() to BUILD_BUG_ON() per David
>>>
>>> Changes in V1:
>>>
>>> https://patchwork.kernel.org/project/linux-mm/patch/1617947717-2424-1-git-send-email-anshuman.khandual@arm.com/
>>>
>>> mm/page_alloc.c | 11 +++++++++--
>>> 1 file changed, 9 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
>>> index cfc72873961d..19283bff4bec 100644
>>> --- a/mm/page_alloc.c
>>> +++ b/mm/page_alloc.c
>>> @@ -6875,10 +6875,17 @@ void __init set_pageblock_order(void)
>>> if (pageblock_order)
>>> return;
>>> - if (HPAGE_SHIFT > PAGE_SHIFT)
>>> + if (HPAGE_SHIFT > PAGE_SHIFT) {
>>> + /*
>>> + * pageblock_order must always be less than
>>> + * MAX_ORDER. So does HUGETLB_PAGE_ORDER if
>>> + * that is being assigned here.
>>> + */
>>> + BUILD_BUG_ON(HUGETLB_PAGE_ORDER >= MAX_ORDER);
>>
>> Unfortunately the build test fails on both the platforms (powerpc and ia64)
>> which subscribe HUGETLB_PAGE_SIZE_VARIABLE and where this check would make
>> sense. I some how overlooked the cross compile build failure that actually
>> detected this problem.
>>
>> But wondering why this assert is not holding true ? and how these platforms
>> do not see the warning during boot (or do they ?) at mm/vmscan.c:1092 like
>> arm64 did.
>>
>> static int __fragmentation_index(unsigned int order, struct contig_page_info *info)
>> {
>> unsigned long requested = 1UL << order;
>>
>> if (WARN_ON_ONCE(order >= MAX_ORDER))
>> return 0;
>> ....
>>
>> Can pageblock_order really exceed MAX_ORDER - 1 ?
>
> Ehm, for now I was under the impression that such configurations wouldn't exist.
>
> And originally, HUGETLB_PAGE_SIZE_VARIABLE was introduced to handle hugepage sizes that all *smaller* than MAX_ORDER - 1: See d9c234005227 ("Do not depend on MAX_ORDER when grouping pages by mobility")
Right.
>
>
> However, looking into init_cma_reserved_pageblock():
>
> if (pageblock_order >= MAX_ORDER) {
> i = pageblock_nr_pages;
> ...
> }
>
>
> But it's kind of weird, isn't it? Let's assume we have MAX_ORDER - 1 correspond to 4 MiB and pageblock_order correspond to 8 MiB.
>
> Sure, we'd be grouping pages in 8 MiB chunks, however, we cannot even allocate 8 MiB chunks via the buddy. So only alloc_contig_range() could really grab them (IOW: gigantic pages).
Right.
>
> Further, we have code like deferred_free_range(), where we end up calling __free_pages_core()->...->__free_one_page() with pageblock_order. Wouldn't we end up setting the buddy order to something > MAX_ORDER -1 on that path?
Agreed.
>
> Having pageblock_order > MAX_ORDER feels wrong and looks shaky.
>
Agreed, definitely does not look right. Lets see what other folks
might have to say on this.
+ Christoph Lameter <cl@linux.com>
^ permalink raw reply
* [powerpc:next-test] BUILD SUCCESS a7724a4bae77ecbda157f4ee04ca9333e1bca678
From: kernel test robot @ 2021-04-19 3:37 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next-test
branch HEAD: a7724a4bae77ecbda157f4ee04ca9333e1bca678 powerpc/pseries: Stop calling printk in rtas_stop_self()
elapsed time: 720m
configs tested: 94
configs skipped: 6
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
i386 allyesconfig
riscv allyesconfig
arm vt8500_v6_v7_defconfig
mips bigsur_defconfig
um i386_defconfig
arm stm32_defconfig
mips qi_lb60_defconfig
powerpc pseries_defconfig
arc vdk_hs38_defconfig
sh r7780mp_defconfig
mips malta_qemu_32r6_defconfig
m68k sun3x_defconfig
mips rt305x_defconfig
riscv nommu_k210_defconfig
arm pxa3xx_defconfig
alpha alldefconfig
arm lpc32xx_defconfig
sh polaris_defconfig
mips malta_kvm_defconfig
mips jmr3927_defconfig
arc tb10x_defconfig
um alldefconfig
xtensa defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
parisc defconfig
s390 allyesconfig
s390 allmodconfig
parisc allyesconfig
s390 defconfig
sparc allyesconfig
sparc defconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a003-20210418
i386 randconfig-a001-20210418
i386 randconfig-a006-20210418
i386 randconfig-a005-20210418
i386 randconfig-a004-20210418
i386 randconfig-a002-20210418
x86_64 randconfig-a014-20210418
x86_64 randconfig-a015-20210418
x86_64 randconfig-a013-20210418
x86_64 randconfig-a011-20210418
x86_64 randconfig-a012-20210418
x86_64 randconfig-a016-20210418
i386 randconfig-a015-20210418
i386 randconfig-a013-20210418
i386 randconfig-a014-20210418
i386 randconfig-a016-20210418
i386 randconfig-a012-20210418
i386 randconfig-a011-20210418
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
riscv allmodconfig
um allmodconfig
um allnoconfig
um allyesconfig
um defconfig
x86_64 allyesconfig
x86_64 rhel-8.3-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 rhel-8.3-kbuiltin
x86_64 kexec
clang tested configs:
x86_64 randconfig-a003-20210418
x86_64 randconfig-a001-20210418
x86_64 randconfig-a005-20210418
x86_64 randconfig-a002-20210418
x86_64 randconfig-a006-20210418
x86_64 randconfig-a004-20210418
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [powerpc:next] BUILD SUCCESS a38cb4171928f622c8c0ab7902971516540cacad
From: kernel test robot @ 2021-04-19 3:37 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
branch HEAD: a38cb4171928f622c8c0ab7902971516540cacad Merge branch 'topic/ppc-kvm' into next
elapsed time: 720m
configs tested: 114
configs skipped: 36
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
x86_64 allyesconfig
riscv allmodconfig
i386 allyesconfig
riscv allyesconfig
powerpc pasemi_defconfig
mips decstation_defconfig
riscv alldefconfig
arm versatile_defconfig
powerpc ksi8560_defconfig
sh se7751_defconfig
powerpc tqm5200_defconfig
sh sdk7780_defconfig
arm mmp2_defconfig
mips gpr_defconfig
powerpc akebono_defconfig
powerpc amigaone_defconfig
ia64 generic_defconfig
ia64 tiger_defconfig
arm mvebu_v7_defconfig
powerpc64 alldefconfig
s390 debug_defconfig
riscv nommu_k210_sdcard_defconfig
mips ci20_defconfig
mips cu1000-neo_defconfig
arm stm32_defconfig
arm pxa255-idp_defconfig
arm s5pv210_defconfig
powerpc icon_defconfig
arm pxa_defconfig
um x86_64_defconfig
arm u8500_defconfig
xtensa iss_defconfig
powerpc mpc834x_mds_defconfig
um kunit_defconfig
arm keystone_defconfig
arm palmz72_defconfig
powerpc gamecube_defconfig
arm h5000_defconfig
mips tb0226_defconfig
sh polaris_defconfig
sh sh7724_generic_defconfig
arm sama5_defconfig
sh se7712_defconfig
powerpc tqm8555_defconfig
mips vocore2_defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
xtensa allyesconfig
sparc allyesconfig
sparc defconfig
i386 defconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a003-20210418
i386 randconfig-a001-20210418
i386 randconfig-a006-20210418
i386 randconfig-a005-20210418
i386 randconfig-a004-20210418
i386 randconfig-a002-20210418
x86_64 randconfig-a014-20210418
x86_64 randconfig-a015-20210418
x86_64 randconfig-a013-20210418
x86_64 randconfig-a011-20210418
x86_64 randconfig-a012-20210418
x86_64 randconfig-a016-20210418
i386 randconfig-a015-20210418
i386 randconfig-a013-20210418
i386 randconfig-a014-20210418
i386 randconfig-a016-20210418
i386 randconfig-a012-20210418
i386 randconfig-a011-20210418
riscv nommu_k210_defconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
um allmodconfig
um allnoconfig
um allyesconfig
um defconfig
x86_64 rhel-8.3-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 rhel-8.3-kbuiltin
x86_64 kexec
clang tested configs:
x86_64 randconfig-a003-20210418
x86_64 randconfig-a001-20210418
x86_64 randconfig-a005-20210418
x86_64 randconfig-a002-20210418
x86_64 randconfig-a006-20210418
x86_64 randconfig-a004-20210418
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [powerpc:merge] BUILD SUCCESS e4361a664ee985c1f54ddecf80b93159750d93d3
From: kernel test robot @ 2021-04-19 3:37 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git merge
branch HEAD: e4361a664ee985c1f54ddecf80b93159750d93d3 Automatic merge of 'next' into merge (2021-04-19 00:04)
elapsed time: 720m
configs tested: 99
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
riscv allmodconfig
i386 allyesconfig
riscv allyesconfig
arm pxa255-idp_defconfig
xtensa audio_kc705_defconfig
mips nlm_xlr_defconfig
m68k sun3_defconfig
sh sh7785lcr_defconfig
sh se7751_defconfig
mips xway_defconfig
powerpc sbc8548_defconfig
powerpc tqm8548_defconfig
mips decstation_r4k_defconfig
arm lpd270_defconfig
m68k apollo_defconfig
powerpc asp8347_defconfig
m68k mvme147_defconfig
riscv allnoconfig
powerpc mpc7448_hpc2_defconfig
powerpc ep88xc_defconfig
sh rsk7264_defconfig
sh sdk7786_defconfig
mips rb532_defconfig
sh se7619_defconfig
arm trizeps4_defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
s390 allmodconfig
parisc allyesconfig
s390 defconfig
sparc allyesconfig
sparc defconfig
i386 defconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a003-20210418
i386 randconfig-a001-20210418
i386 randconfig-a006-20210418
i386 randconfig-a005-20210418
i386 randconfig-a004-20210418
i386 randconfig-a002-20210418
x86_64 randconfig-a014-20210418
x86_64 randconfig-a015-20210418
x86_64 randconfig-a013-20210418
x86_64 randconfig-a011-20210418
x86_64 randconfig-a012-20210418
x86_64 randconfig-a016-20210418
i386 randconfig-a015-20210418
i386 randconfig-a013-20210418
i386 randconfig-a014-20210418
i386 randconfig-a016-20210418
i386 randconfig-a012-20210418
i386 randconfig-a011-20210418
riscv nommu_k210_defconfig
riscv nommu_virt_defconfig
riscv defconfig
riscv rv32_defconfig
um allmodconfig
um allnoconfig
um allyesconfig
um defconfig
x86_64 allyesconfig
x86_64 rhel-8.3-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 rhel-8.3-kbuiltin
x86_64 kexec
clang tested configs:
x86_64 randconfig-a003-20210418
x86_64 randconfig-a001-20210418
x86_64 randconfig-a005-20210418
x86_64 randconfig-a002-20210418
x86_64 randconfig-a006-20210418
x86_64 randconfig-a004-20210418
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* Re: [PATCH 3/3] powerpc/smp: Cache CPU to chip lookup
From: David Gibson @ 2021-04-19 1:19 UTC (permalink / raw)
To: Gautham R Shenoy
Cc: Nathan Lynch, Srikar Dronamraju, Peter Zijlstra,
Daniel Henrique Barboza, Valentin Schneider, qemu-ppc,
Cedric Le Goater, linuxppc-dev, Ingo Molnar
In-Reply-To: <20210416155748.GA26496@in.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 2832 bytes --]
On Fri, Apr 16, 2021 at 09:27:48PM +0530, Gautham R Shenoy wrote:
> On Thu, Apr 15, 2021 at 11:21:10PM +0530, Srikar Dronamraju wrote:
> > * Gautham R Shenoy <ego@linux.vnet.ibm.com> [2021-04-15 22:49:21]:
> >
> > > >
> > > > +int *chip_id_lookup_table;
> > > > +
> > > > #ifdef CONFIG_PPC64
> > > > int __initdata iommu_is_off;
> > > > int __initdata iommu_force_on;
> > > > @@ -914,13 +916,22 @@ EXPORT_SYMBOL(of_get_ibm_chip_id);
> > > > int cpu_to_chip_id(int cpu)
> > > > {
> > > > struct device_node *np;
> > > > + int ret = -1, idx;
> > > > +
> > > > + idx = cpu / threads_per_core;
> > > > + if (chip_id_lookup_table && chip_id_lookup_table[idx] != -1)
> > >
> >
> > > The value -1 is ambiguous since we won't be able to determine if
> > > it is because we haven't yet made a of_get_ibm_chip_id() call
> > > or if of_get_ibm_chip_id() call was made and it returned a -1.
> > >
> >
> > We don't allocate chip_id_lookup_table unless cpu_to_chip_id() return
> > !-1 value for the boot-cpuid. So this ensures that we dont
> > unnecessarily allocate chip_id_lookup_table. Also I check for
> > chip_id_lookup_table before calling cpu_to_chip_id() for other CPUs.
> > So this avoids overhead of calling cpu_to_chip_id() for platforms that
> > dont support it. Also its most likely that if the
> > chip_id_lookup_table is initialized then of_get_ibm_chip_id() call
> > would return a valid value.
> >
> > + Below we are only populating the lookup table, only when the
> > of_get_cpu_node is valid.
> >
> > So I dont see any drawbacks of initializing it to -1. Do you see
> any?
>
>
> Only if other callers of cpu_to_chip_id() don't check for whether the
> chip_id_lookup_table() has been allocated or not. From a code
> readability point of view, it is easier to have that check this inside
> cpu_to_chip_id() instead of requiring all its callers to make that
> check.
Even if they do, and the bad invalid value should never be read, I
think it's worth initializing that way. If means if there's a mistake
and we do accidentally read the value, then the error is likely to be
much clearer. Likewise if someone looks at this value from a
debugger, it will be clearer what's going on.
>
> >
> > > Thus, perhaps we can initialize chip_id_lookup_table[idx] with a
> > > different unique negative value. How about S32_MIN ? and check
> > > chip_id_lookup_table[idx] is different here ?
> > >
> >
> > I had initially initialized to -2, But then I thought we adding in
> > more confusion than necessary and it was not solving any issues.
> >
> >
>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 1/3] powerpc/smp: Reintroduce cpu_core_mask
From: David Gibson @ 2021-04-19 1:17 UTC (permalink / raw)
To: Srikar Dronamraju
Cc: Nathan Lynch, Gautham R Shenoy, Peter Zijlstra,
Daniel Henrique Barboza, Valentin Schneider, hegdevasant,
qemu-ppc, Cedric Le Goater, linuxppc-dev, Ingo Molnar
In-Reply-To: <20210416054549.GF2633526@linux.vnet.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 3670 bytes --]
On Fri, Apr 16, 2021 at 11:15:49AM +0530, Srikar Dronamraju wrote:
> * David Gibson <david@gibson.dropbear.id.au> [2021-04-16 13:21:34]:
>
> Thanks for having a look at the patches.
>
> > On Thu, Apr 15, 2021 at 05:39:32PM +0530, Srikar Dronamraju wrote:
> > > Daniel reported that with Commit 4ca234a9cbd7 ("powerpc/smp: Stop
> > > updating cpu_core_mask") QEMU was unable to set single NUMA node SMP
> > > topologies such as:
> > > -smp 8,maxcpus=8,cores=2,threads=2,sockets=2
> > > i.e he expected 2 sockets in one NUMA node.
> >
> > Well, strictly speaking, you can still set that toplogy in qemu but a
> > PAPR guest with that commit will show as having 1 socket in lscpu and
> > similar things.
> >
>
> Right, I did mention the o/p of lscpu in QEMU with the said commit and
> with the new patches in the cover letter. Somehow I goofed up the cc
> list for the cover letter.
>
> Reference for the cover letter:
> https://lore.kernel.org/linuxppc-dev/20210415120934.232271-1-srikar@linux.vnet.ibm.com/t/#u
>
> > Basically, this is because PAPR has no meaningful distinction between
> > cores and sockets. So it's kind of a cosmetic problem, but it is a
> > user-unexpected behaviour that it would be nice to avoid if it's not
> > excessively difficult.
> >
> > > The above commit helped to reduce boot time on Large Systems for
> > > example 4096 vCPU single socket QEMU instance. PAPR is silent on
> > > having more than one socket within a NUMA node.
> > >
> > > cpu_core_mask and cpu_cpu_mask for any CPU would be same unless the
> > > number of sockets is different from the number of NUMA nodes.
> >
> > Number of sockets being different from number of NUMA nodes is routine
> > in qemu, and I don't think it's something we should enforce.
> >
> > > One option is to reintroduce cpu_core_mask but use a slightly
> > > different method to arrive at the cpu_core_mask. Previously each CPU's
> > > chip-id would be compared with all other CPU's chip-id to verify if
> > > both the CPUs were related at the chip level. Now if a CPU 'A' is
> > > found related / (unrelated) to another CPU 'B', all the thread
> > > siblings of 'A' and thread siblings of 'B' are automatically marked as
> > > related / (unrelated).
> > >
> > > Also if a platform doesn't support ibm,chip-id property, i.e its
> > > cpu_to_chip_id returns -1, cpu_core_map holds a copy of
> > > cpu_cpu_mask().
> >
> > Yeah, the other weirdness here is that ibm,chip-id isn't a PAPR
> > property at all - it was added for powernv. We then added it to qemu
> > for PAPR guests because that was the way at the time to get the guest
> > to advertise the expected number of sockets. It therefore basically
> > *only* exists on PAPR/qemu for that purpose, so if it's not serving it
> > we need to come up with something else.
> >
>
> Do you have ideas on what that something could be like?
Not really, sorry.
> So if that's
> more beneficial then we could move over to that scheme. Also apart
> from ibm,chip-id being not a PAPR property, do you have any other
> concerns with it.
I think if we can keep ibm,chip-id doing this job, that would be
simplest - as long as our PAPR usage isn't implying semantics which
contradict what it does on powernv. AIUI Cédric thought it did that,
but with further discussion it seems like that might have been a
misunderstanding incorrectly conflating chip-id with NUMA nodes.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH] perf vendor events: Initial json/events list for power10 platform
From: Paul A. Clarke @ 2021-04-18 21:08 UTC (permalink / raw)
To: Kajol Jain
Cc: ravi.bangoria, atrajeev, linuxppc-dev, linux-kernel, acme,
linux-perf-users, maddy, jolsa
In-Reply-To: <20210417091850.596023-1-kjain@linux.ibm.com>
On Sat, Apr 17, 2021 at 02:48:50PM +0530, Kajol Jain wrote:
> Patch adds initial json/events for POWER10.
I was able to apply, build, and run perf with these changes,
and every new event at least ran successfully with
`perf stat`.
Pedantically, there is a lot of inconsistency as to whether
the `BriefDescription` ends with a period or not, and whether
there is an extra space at the end.
Regardless, LGTM.
Tested-by: Paul A. Clarke <pc@us.ibm.com>
Reviewed-by: Paul A. Clarke <pc@us.ibm.com>
PC
^ permalink raw reply
* [PATCH 2/2] powerpc: add ALTIVEC support to lib/ when PPC_FPU not set
From: Randy Dunlap @ 2021-04-18 20:17 UTC (permalink / raw)
To: linux-kernel; +Cc: kernel test robot, Randy Dunlap, linuxppc-dev
In-Reply-To: <20210418201726.32130-1-rdunlap@infradead.org>
When PPC_FPU is not set and ALTIVEC=y, arch/powerpc/lib/ldstfp.c is not
being built, but it is also needed when ALTIVEC=y for get_vr() and
put_vr().
../arch/powerpc/lib/sstep.c: In function 'do_vec_load':
../arch/powerpc/lib/sstep.c:637:3: error: implicit declaration of function 'put_vr' [-Werror=implicit-function-declaration]
637 | put_vr(rn, &u.v);
| ^~~~~~
../arch/powerpc/lib/sstep.c: In function 'do_vec_store':
../arch/powerpc/lib/sstep.c:660:3: error: implicit declaration of function 'get_vr'; did you mean 'get_oc'? [-Werror=implicit-function-declaration]
660 | get_vr(rn, &u.v);
| ^~~~~~
Add ldstfp.o to the Makefile for CONFIG_ALTIVEC and add
externs for get_vr() and put_vr() in lib/sstep.c to fix the
build errors.
This was seen in a kernel config from kernel test robot <lkp@intel.com>
that reported a different build issue (for pmac32-cpufreq.c).
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: Segher Boessenkool <segher@kernel.crashing.org>
Cc: lkp@intel.com
---
arch/powerpc/lib/Makefile | 1 +
arch/powerpc/lib/sstep.c | 5 +++++
2 files changed, 6 insertions(+)
--- linux-next-20210416.orig/arch/powerpc/lib/Makefile
+++ linux-next-20210416/arch/powerpc/lib/Makefile
@@ -54,6 +54,7 @@ obj-y += checksum_$(BITS).o checksum_w
obj-y += sstep.o
obj-$(CONFIG_PPC_FPU) += ldstfp.o
+obj-$(CONFIG_ALTIVEC) += ldstfp.o
obj64-y += quad.o
obj-$(CONFIG_PPC_LIB_RHEAP) += rheap.o
--- linux-next-20210416.orig/arch/powerpc/lib/sstep.c
+++ linux-next-20210416/arch/powerpc/lib/sstep.c
@@ -50,6 +50,11 @@ extern void conv_sp_to_dp(const float *s
extern void conv_dp_to_sp(const double *dp, float *sp);
#endif
+#ifdef CONFIG_ALTIVEC
+extern void get_vr(int rn, __vector128 *p);
+extern void put_vr(int rn, __vector128 *p);
+#endif /* CONFIG_ALTIVEC */
+
#ifdef __powerpc64__
/*
* Functions in quad.S
^ permalink raw reply
* [PATCH 1/2] powerpc: add enable_kernel_fp() stub for ALTIVEC without PPC_FPU
From: Randy Dunlap @ 2021-04-18 20:17 UTC (permalink / raw)
To: linux-kernel; +Cc: kernel test robot, Randy Dunlap, linuxppc-dev
On a kernel config with ALTIVEC=y and PPC_FPU not set/enabled,
there is a build error:
drivers/cpufreq/pmac32-cpufreq.c:262:2: error: implicit declaration of function 'enable_kernel_fp' [-Werror,-Wimplicit-function-declaration]
enable_kernel_fp();
so add a stub function for that when PPC_FPU is not set.
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Reported-by: kernel test robot <lkp@intel.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: Segher Boessenkool <segher@kernel.crashing.org>
Cc: lkp@intel.com
---
arch/powerpc/include/asm/switch_to.h | 1 +
1 file changed, 1 insertion(+)
--- linux-next-20210416.orig/arch/powerpc/include/asm/switch_to.h
+++ linux-next-20210416/arch/powerpc/include/asm/switch_to.h
@@ -48,6 +48,7 @@ static inline void disable_kernel_fp(voi
#else
static inline void save_fpu(struct task_struct *t) { }
static inline void flush_fp_to_thread(struct task_struct *t) { }
+static inline void enable_kernel_fp(void) { }
#endif
#ifdef CONFIG_ALTIVEC
^ permalink raw reply
* [PATCH] Documentation/powerpc: Add proper links for manual and tests
From: Haren Myneni @ 2021-04-18 19:29 UTC (permalink / raw)
To: linuxppc-dev, mpe; +Cc: abali
The links that are mentioned in this document are no longer
valid. So changed the proper links for NXGZIP user manual and
test cases.
Signed-off-by: Haren Myneni <haren@linux.ibm.com>
Reported-by: Bulent Abali <abali@us.ibm.com>
---
Documentation/powerpc/vas-api.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/powerpc/vas-api.rst b/Documentation/powerpc/vas-api.rst
index 90c50ed839f3..bdb50fed903e 100644
--- a/Documentation/powerpc/vas-api.rst
+++ b/Documentation/powerpc/vas-api.rst
@@ -254,7 +254,7 @@ using this window. the signal will be issued to the thread group leader
signals.
NX-GZIP User's Manual:
-https://github.com/libnxz/power-gzip/blob/master/power_nx_gzip_um.pdf
+https://github.com/libnxz/power-gzip/blob/master/doc/power_nx_gzip_um.pdf
Simple example
==============
@@ -301,5 +301,5 @@ Simple example
close(fd) or window can be closed upon process exit
}
- Refer https://github.com/abalib/power-gzip for tests or more
+ Refer https://github.com/libnxz/power-gzip for tests or more
use cases.
--
2.26.2
^ permalink raw reply related
* Re: mmu.c:undefined reference to `patch__hash_page_A0'
From: Christophe Leroy @ 2021-04-18 18:35 UTC (permalink / raw)
To: Randy Dunlap, kernel test robot; +Cc: PowerPC, kbuild-all, linux-kernel
In-Reply-To: <0a301d17-136c-df65-17cc-3c9ddbe06de8@infradead.org>
Le 18/04/2021 à 19:15, Randy Dunlap a écrit :
> On 4/18/21 3:43 AM, Christophe Leroy wrote:
>>
>>
>> Le 18/04/2021 à 02:02, Randy Dunlap a écrit :
>>> HI--
>>>
>>> I no longer see this build error.
>>
>> Fixed by https://github.com/torvalds/linux/commit/acdad8fb4a1574323db88f98a38b630691574e16
>>
>>> However:
>>>
>>> On 2/27/21 2:24 AM, kernel test robot wrote:
>>>> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
>>>> head: 3fb6d0e00efc958d01c2f109c8453033a2d96796
>>>> commit: 259149cf7c3c6195e6199e045ca988c31d081cab powerpc/32s: Only build hash code when CONFIG_PPC_BOOK3S_604 is selected
>>>> date: 4 weeks ago
>>>> config: powerpc64-randconfig-r013-20210227 (attached as .config)
>>>
>>> ktr/lkp, this is a PPC32 .config file that is attached, not PPC64.
>>>
>>> Also:
>>>
>>>> compiler: powerpc-linux-gcc (GCC) 9.3.0
>>
>> ...
>>
>>>
>>> I do see this build error:
>>>
>>> powerpc-linux-ld: arch/powerpc/boot/wrapper.a(decompress.o): in function `partial_decompress':
>>> decompress.c:(.text+0x1f0): undefined reference to `__decompress'
>>>
>>> when either
>>> CONFIG_KERNEL_LZO=y
>>> or
>>> CONFIG_KERNEL_LZMA=y
>>>
>>> but the build succeeds when either
>>> CONFIG_KERNEL_GZIP=y
>>> or
>>> CONFIG_KERNEL_XZ=y
>>>
>>> I guess that is due to arch/powerpc/boot/decompress.c doing this:
>>>
>>> #ifdef CONFIG_KERNEL_GZIP
>>> # include "decompress_inflate.c"
>>> #endif
>>>
>>> #ifdef CONFIG_KERNEL_XZ
>>> # include "xz_config.h"
>>> # include "../../../lib/decompress_unxz.c"
>>> #endif
>>>
>>>
>>> It would be nice to require one of KERNEL_GZIP or KERNEL_XZ
>>> to be set/enabled (maybe unless a uImage is being built?).
>>
>>
>> Can you test by https://patchwork.ozlabs.org/project/linuxppc-dev/patch/a74fce4dfc9fa32da6ce3470bbedcecf795de1ec.1591189069.git.christophe.leroy@csgroup.eu/ ?
>
> Hi Christophe,
>
> I get build errors for both LZO and LZMA:
Ok, the patch is almost 1 year old, I guess there has been changes that break it. Will see if I can
find some time to look at it.
Christophe
^ permalink raw reply
* Re: PPC_FPU, ALTIVEC: enable_kernel_fp, put_vr, get_vr
From: Randy Dunlap @ 2021-04-18 17:59 UTC (permalink / raw)
To: Segher Boessenkool, Christophe Leroy; +Cc: PowerPC, LKML
In-Reply-To: <20210418174648.GN26583@gate.crashing.org>
On 4/18/21 10:46 AM, Segher Boessenkool wrote:
> On Sun, Apr 18, 2021 at 06:24:29PM +0200, Christophe Leroy wrote:
>> Le 17/04/2021 à 22:17, Randy Dunlap a écrit :
>>> Should the code + Kconfigs/Makefiles handle that kind of
>>> kernel config or should ALTIVEC always mean PPC_FPU as well?
>>
>> As far as I understand, Altivec is completely independant of FPU in Theory.
>
> And, as far as the hardware is concerned, in practice as well.
>
>> So it should be possible to use Altivec without using FPU.
>
> Yup.
>
>> However, until recently, it was not possible to de-activate FPU support on
>> book3s/32. I made it possible in order to reduce unneccessary processing on
>> processors like the 832x that has no FPU.
>
> The processor has to implement FP to be compliant to any version of
> PowerPC, as far as I know? So that is all done by emulation, including
> all the registers? Wow painful.
>
>> As far as I can see in cputable.h/.c, 832x is the only book3s/32 without
>> FPU, and it doesn't have ALTIVEC either.
>
> 602 doesn't have double-precision hardware, also no 64-bit FP registers.
> But that CPU was never any widely used :-)
>
>> So we can in the future ensure that Altivec can be used without FPU
>> support, but for the time being I think it is OK to force selection of FPU
>> when selecting ALTIVEC in order to avoid build failures.
>
> It is useful to allow MSR[VEC,FP]=1,0 but yeah there are no CPUs that
> have VMX (aka AltiVec) but that do not have FP. I don't see how making
> that artificial dependency buys anything, but maybe it does?
>
>>> I have patches to fix the build errors with the config as
>>> reported but I don't know if that's the right thing to do...
>
> Neither do we, we cannot see those patches :-)
Sure. I'll post them later today.
They keep FPU and ALTIVEC as independent (build) features.
--
~Randy
^ permalink raw reply
* Re: PPC_FPU, ALTIVEC: enable_kernel_fp, put_vr, get_vr
From: Segher Boessenkool @ 2021-04-18 17:46 UTC (permalink / raw)
To: Christophe Leroy; +Cc: Randy Dunlap, PowerPC, LKML
In-Reply-To: <8b1cb0a2-ed3a-7da0-a73a-febbda528703@csgroup.eu>
On Sun, Apr 18, 2021 at 06:24:29PM +0200, Christophe Leroy wrote:
> Le 17/04/2021 à 22:17, Randy Dunlap a écrit :
> >Should the code + Kconfigs/Makefiles handle that kind of
> >kernel config or should ALTIVEC always mean PPC_FPU as well?
>
> As far as I understand, Altivec is completely independant of FPU in Theory.
And, as far as the hardware is concerned, in practice as well.
> So it should be possible to use Altivec without using FPU.
Yup.
> However, until recently, it was not possible to de-activate FPU support on
> book3s/32. I made it possible in order to reduce unneccessary processing on
> processors like the 832x that has no FPU.
The processor has to implement FP to be compliant to any version of
PowerPC, as far as I know? So that is all done by emulation, including
all the registers? Wow painful.
> As far as I can see in cputable.h/.c, 832x is the only book3s/32 without
> FPU, and it doesn't have ALTIVEC either.
602 doesn't have double-precision hardware, also no 64-bit FP registers.
But that CPU was never any widely used :-)
> So we can in the future ensure that Altivec can be used without FPU
> support, but for the time being I think it is OK to force selection of FPU
> when selecting ALTIVEC in order to avoid build failures.
It is useful to allow MSR[VEC,FP]=1,0 but yeah there are no CPUs that
have VMX (aka AltiVec) but that do not have FP. I don't see how making
that artificial dependency buys anything, but maybe it does?
> >I have patches to fix the build errors with the config as
> >reported but I don't know if that's the right thing to do...
Neither do we, we cannot see those patches :-)
Segher
^ permalink raw reply
* Re: mmu.c:undefined reference to `patch__hash_page_A0'
From: Randy Dunlap @ 2021-04-18 17:15 UTC (permalink / raw)
To: Christophe Leroy, kernel test robot; +Cc: PowerPC, kbuild-all, linux-kernel
In-Reply-To: <ab9d4f9e-add6-900b-9fa7-83d5f7d1108b@csgroup.eu>
On 4/18/21 3:43 AM, Christophe Leroy wrote:
>
>
> Le 18/04/2021 à 02:02, Randy Dunlap a écrit :
>> HI--
>>
>> I no longer see this build error.
>
> Fixed by https://github.com/torvalds/linux/commit/acdad8fb4a1574323db88f98a38b630691574e16
>
>> However:
>>
>> On 2/27/21 2:24 AM, kernel test robot wrote:
>>> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
>>> head: 3fb6d0e00efc958d01c2f109c8453033a2d96796
>>> commit: 259149cf7c3c6195e6199e045ca988c31d081cab powerpc/32s: Only build hash code when CONFIG_PPC_BOOK3S_604 is selected
>>> date: 4 weeks ago
>>> config: powerpc64-randconfig-r013-20210227 (attached as .config)
>>
>> ktr/lkp, this is a PPC32 .config file that is attached, not PPC64.
>>
>> Also:
>>
>>> compiler: powerpc-linux-gcc (GCC) 9.3.0
>
> ...
>
>>
>> I do see this build error:
>>
>> powerpc-linux-ld: arch/powerpc/boot/wrapper.a(decompress.o): in function `partial_decompress':
>> decompress.c:(.text+0x1f0): undefined reference to `__decompress'
>>
>> when either
>> CONFIG_KERNEL_LZO=y
>> or
>> CONFIG_KERNEL_LZMA=y
>>
>> but the build succeeds when either
>> CONFIG_KERNEL_GZIP=y
>> or
>> CONFIG_KERNEL_XZ=y
>>
>> I guess that is due to arch/powerpc/boot/decompress.c doing this:
>>
>> #ifdef CONFIG_KERNEL_GZIP
>> # include "decompress_inflate.c"
>> #endif
>>
>> #ifdef CONFIG_KERNEL_XZ
>> # include "xz_config.h"
>> # include "../../../lib/decompress_unxz.c"
>> #endif
>>
>>
>> It would be nice to require one of KERNEL_GZIP or KERNEL_XZ
>> to be set/enabled (maybe unless a uImage is being built?).
>
>
> Can you test by https://patchwork.ozlabs.org/project/linuxppc-dev/patch/a74fce4dfc9fa32da6ce3470bbedcecf795de1ec.1591189069.git.christophe.leroy@csgroup.eu/ ?
Hi Christophe,
I get build errors for both LZO and LZMA:
for CONFIG_KERNEL_LZO=y:
In file included from ../lib/decompress_unlzo.c:26:
../include/linux/lzo.h:24:48: error: unknown type name 'size_t'
24 | int lzo1x_1_compress(const unsigned char *src, size_t src_len,
| ^~~~~~
../include/linux/lzo.h:1:1: note: 'size_t' is defined in header '<stddef.h>'; did you forget to '#include <stddef.h>'?
+++ |+#include <stddef.h>
1 | /* SPDX-License-Identifier: GPL-2.0 */
../include/linux/lzo.h:25:28: error: unknown type name 'size_t'
25 | unsigned char *dst, size_t *dst_len, void *wrkmem);
| ^~~~~~
../include/linux/lzo.h:25:28: note: 'size_t' is defined in header '<stddef.h>'; did you forget to '#include <stddef.h>'?
../include/linux/lzo.h:28:51: error: unknown type name 'size_t'
28 | int lzorle1x_1_compress(const unsigned char *src, size_t src_len,
| ^~~~~~
../include/linux/lzo.h:28:51: note: 'size_t' is defined in header '<stddef.h>'; did you forget to '#include <stddef.h>'?
../include/linux/lzo.h:29:28: error: unknown type name 'size_t'
29 | unsigned char *dst, size_t *dst_len, void *wrkmem);
| ^~~~~~
../include/linux/lzo.h:29:28: note: 'size_t' is defined in header '<stddef.h>'; did you forget to '#include <stddef.h>'?
../include/linux/lzo.h:32:53: error: unknown type name 'size_t'
32 | int lzo1x_decompress_safe(const unsigned char *src, size_t src_len,
| ^~~~~~
../include/linux/lzo.h:32:53: note: 'size_t' is defined in header '<stddef.h>'; did you forget to '#include <stddef.h>'?
../include/linux/lzo.h:33:26: error: unknown type name 'size_t'
33 | unsigned char *dst, size_t *dst_len);
| ^~~~~~
../include/linux/lzo.h:33:26: note: 'size_t' is defined in header '<stddef.h>'; did you forget to '#include <stddef.h>'?
CC drivers/char/tpm/tpm2-space.o
CC [M] drivers/regulator/da9121-regulator.o
AR drivers/iommu/built-in.a
../lib/decompress_unlzo.c: In function 'unlzo':
../lib/decompress_unlzo.c:237:8: error: implicit declaration of function 'lzo1x_decompress_safe' [-Werror=implicit-function-declaration]
237 | r = lzo1x_decompress_safe((u8 *) in_buf, src_len,
| ^~~~~~~~~~~~~~~~~~~~~
In file included from ../arch/powerpc/boot/ops.h:15,
from ../arch/powerpc/boot/decompress.c:12:
../arch/powerpc/boot/types.h:50:15: error: expected identifier before numeric constant
50 | #define false 0
| ^
../include/linux/stddef.h:11:2: note: in expansion of macro 'false'
11 | false = 0,
| ^~~~~
In file included from ../include/linux/kasan-checks.h:5,
from ../include/asm-generic/rwonce.h:26,
from ./arch/powerpc/include/generated/asm/rwonce.h:1,
from ../include/linux/compiler.h:248,
from ../arch/powerpc/boot/../../../lib/decompress_unlzo.c:32,
from ../arch/powerpc/boot/decompress.c:43:
../include/linux/types.h:30:17: error: conflicting types for 'bool'
30 | typedef _Bool bool;
| ^~~~
In file included from ../arch/powerpc/boot/ops.h:15,
from ../arch/powerpc/boot/decompress.c:12:
../arch/powerpc/boot/types.h:43:13: note: previous declaration of 'bool' was here
43 | typedef int bool;
| ^~~~
In file included from ./arch/powerpc/include/generated/asm/rwonce.h:1,
from ../include/linux/compiler.h:248,
from ../arch/powerpc/boot/../../../lib/decompress_unlzo.c:32,
from ../arch/powerpc/boot/decompress.c:43:
../include/asm-generic/rwonce.h:64:31: error: expected ';' before 'unsigned'
64 | static __no_sanitize_or_inline
| ^
| ;
65 | unsigned long __read_once_word_nocheck(const void *addr)
| ~~~~~~~~
../include/asm-generic/rwonce.h:82:28: error: expected ';' before 'unsigned'
82 | static __no_kasan_or_inline
| ^
| ;
83 | unsigned long read_word_at_a_time(const void *addr)
| ~~~~~~~~
In file included from ../arch/powerpc/boot/decompress.c:43:
../arch/powerpc/boot/../../../lib/decompress_unlzo.c: In function 'parse_header':
../arch/powerpc/boot/../../../lib/decompress_unlzo.c:48:5: warning: variable 'level' set but not used [-Wunused-but-set-variable]
48 | u8 level = 0;
| ^~~~~
and for CONFIG_KERNEL_LZMA=y:
(this looks odd to me since it says "unlzo", but I repeated it
after a 'make clean' and got the same errors.)
In file included from ../lib/decompress_unlzo.c:26:
../include/linux/lzo.h:24:48: error: unknown type name 'size_t'
24 | int lzo1x_1_compress(const unsigned char *src, size_t src_len,
| ^~~~~~
../include/linux/lzo.h:1:1: note: 'size_t' is defined in header '<stddef.h>'; did you forget to '#include <stddef.h>'?
+++ |+#include <stddef.h>
1 | /* SPDX-License-Identifier: GPL-2.0 */
../include/linux/lzo.h:25:28: error: unknown type name 'size_t'
25 | unsigned char *dst, size_t *dst_len, void *wrkmem);
| ^~~~~~
../include/linux/lzo.h:25:28: note: 'size_t' is defined in header '<stddef.h>'; did you forget to '#include <stddef.h>'?
../include/linux/lzo.h:28:51: error: unknown type name 'size_t'
28 | int lzorle1x_1_compress(const unsigned char *src, size_t src_len,
| ^~~~~~
../include/linux/lzo.h:28:51: note: 'size_t' is defined in header '<stddef.h>'; did you forget to '#include <stddef.h>'?
../include/linux/lzo.h:29:28: error: unknown type name 'size_t'
29 | unsigned char *dst, size_t *dst_len, void *wrkmem);
| ^~~~~~
../include/linux/lzo.h:29:28: note: 'size_t' is defined in header '<stddef.h>'; did you forget to '#include <stddef.h>'?
../include/linux/lzo.h:32:53: error: unknown type name 'size_t'
32 | int lzo1x_decompress_safe(const unsigned char *src, size_t src_len,
| ^~~~~~
../include/linux/lzo.h:32:53: note: 'size_t' is defined in header '<stddef.h>'; did you forget to '#include <stddef.h>'?
../include/linux/lzo.h:33:26: error: unknown type name 'size_t'
33 | unsigned char *dst, size_t *dst_len);
| ^~~~~~
../include/linux/lzo.h:33:26: note: 'size_t' is defined in header '<stddef.h>'; did you forget to '#include <stddef.h>'?
../lib/decompress_unlzo.c: In function 'unlzo':
../lib/decompress_unlzo.c:237:8: error: implicit declaration of function 'lzo1x_decompress_safe' [-Werror=implicit-function-declaration]
237 | r = lzo1x_decompress_safe((u8 *) in_buf, src_len,
| ^~~~~~~~~~~~~~~~~~~~~
--
~Randy
^ permalink raw reply
* Re: PPC_FPU, ALTIVEC: enable_kernel_fp, put_vr, get_vr
From: Christophe Leroy @ 2021-04-18 16:24 UTC (permalink / raw)
To: Randy Dunlap, PowerPC; +Cc: LKML
In-Reply-To: <7107fcae-5c7a-ac94-8d89-326f2cd4cd33@infradead.org>
Le 17/04/2021 à 22:17, Randy Dunlap a écrit :
> Hi,
>
> kernel test robot reports:
>
>>> drivers/cpufreq/pmac32-cpufreq.c:262:2: error: implicit declaration of function 'enable_kernel_fp' [-Werror,-Wimplicit-function-declaration]
> enable_kernel_fp();
> ^
>
> when
> # CONFIG_PPC_FPU is not set
> CONFIG_ALTIVEC=y
>
> I see at least one other place that does not handle that
> combination well, here:
>
> ../arch/powerpc/lib/sstep.c: In function 'do_vec_load':
> ../arch/powerpc/lib/sstep.c:637:3: error: implicit declaration of function 'put_vr' [-Werror=implicit-function-declaration]
> 637 | put_vr(rn, &u.v);
> | ^~~~~~
> ../arch/powerpc/lib/sstep.c: In function 'do_vec_store':
> ../arch/powerpc/lib/sstep.c:660:3: error: implicit declaration of function 'get_vr'; did you mean 'get_oc'? [-Werror=implicit-function-declaration]
> 660 | get_vr(rn, &u.v);
> | ^~~~~~
>
>
> Should the code + Kconfigs/Makefiles handle that kind of
> kernel config or should ALTIVEC always mean PPC_FPU as well?
As far as I understand, Altivec is completely independant of FPU in Theory. So it should be possible
to use Altivec without using FPU.
However, until recently, it was not possible to de-activate FPU support on book3s/32. I made it
possible in order to reduce unneccessary processing on processors like the 832x that has no FPU.
As far as I can see in cputable.h/.c, 832x is the only book3s/32 without FPU, and it doesn't have
ALTIVEC either.
So we can in the future ensure that Altivec can be used without FPU support, but for the time being
I think it is OK to force selection of FPU when selecting ALTIVEC in order to avoid build failures.
>
> I have patches to fix the build errors with the config as
> reported but I don't know if that's the right thing to do...
>
Lets see them.
Christophe
^ permalink raw reply
* [PATCH] powerpc/pseries: Stop calling printk in rtas_stop_self()
From: Michael Ellerman @ 2021-04-18 13:54 UTC (permalink / raw)
To: linuxppc-dev
RCU complains about us calling printk() from an offline CPU:
=============================
WARNING: suspicious RCU usage
5.12.0-rc7-02874-g7cf90e481cb8 #1 Not tainted
-----------------------------
kernel/locking/lockdep.c:3568 RCU-list traversed in non-reader section!!
other info that might help us debug this:
RCU used illegally from offline CPU!
rcu_scheduler_active = 2, debug_locks = 1
no locks held by swapper/0/0.
stack backtrace:
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.12.0-rc7-02874-g7cf90e481cb8 #1
Call Trace:
dump_stack+0xec/0x144 (unreliable)
lockdep_rcu_suspicious+0x124/0x144
__lock_acquire+0x1098/0x28b0
lock_acquire+0x128/0x600
_raw_spin_lock_irqsave+0x6c/0xc0
down_trylock+0x2c/0x70
__down_trylock_console_sem+0x60/0x140
vprintk_emit+0x1a8/0x4b0
vprintk_func+0xcc/0x200
printk+0x40/0x54
pseries_cpu_offline_self+0xc0/0x120
arch_cpu_idle_dead+0x54/0x70
do_idle+0x174/0x4a0
cpu_startup_entry+0x38/0x40
rest_init+0x268/0x388
start_kernel+0x748/0x790
start_here_common+0x1c/0x614
Which happens because by the time we get to rtas_stop_self() we are
already offline. In addition the message can be spammy, and is not that
helpful for users, so remove it.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/platforms/pseries/hotplug-cpu.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/hotplug-cpu.c b/arch/powerpc/platforms/pseries/hotplug-cpu.c
index ec478f8a98ff..48d9dfc3fad1 100644
--- a/arch/powerpc/platforms/pseries/hotplug-cpu.c
+++ b/arch/powerpc/platforms/pseries/hotplug-cpu.c
@@ -47,9 +47,6 @@ static void rtas_stop_self(void)
BUG_ON(rtas_stop_self_token == RTAS_UNKNOWN_SERVICE);
- printk("cpu %u (hwid %u) Ready to die...\n",
- smp_processor_id(), hard_smp_processor_id());
-
rtas_call_unlocked(&args, rtas_stop_self_token, 0, 1, NULL);
panic("Alas, I survived.\n");
--
2.25.1
^ 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