* [PATCH v2 1/2] selftests/powerpc: Add missing clobbered register to to ptrace TM tests
From: Jordan Niethe @ 2021-07-29 4:13 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Jordan Niethe, mikey
ISA v3.1 removes TM but includes a synthetic implementation for
backwards compatibility. With this implementation, the tests
ptrace-tm-spd-gpr and ptrace-tm-gpr should never be able to make any
forward progress and eventually should be killed by the timeout.
Instead on a P10 running in P9 mode, ptrace_tm_gpr fails like so:
test: ptrace_tm_gpr
tags: git_version:unknown
Starting the child
...
...
GPR[27]: 1 Expected: 2
GPR[28]: 1 Expected: 2
GPR[29]: 1 Expected: 2
GPR[30]: 1 Expected: 2
GPR[31]: 1 Expected: 2
[FAIL] Test FAILED on line 98
failure: ptrace_tm_gpr
selftests: ptrace-tm-gpr [FAIL]
The problem is in the inline assembly of the child. r0 is loaded with a
value in the child's transaction abort handler but this register is not
included in the clobbers list. This means it is possible that this
statement:
cptr[1] = 0;
which is meant to signal the parent to wait may actually use the value
placed into r0 by the inline assembly incorrectly signal the parent to
continue.
By inspection the same problem is present in ptrace-tm-spd-gpr.
Adding r0 to the clobbbers list makes the test fail correctly via a
timeout on a P10 running in P8/P9 compatibility mode.
Suggested-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Jordan Niethe <jniethe5@gmail.com>
---
tools/testing/selftests/powerpc/ptrace/ptrace-tm-gpr.c | 2 +-
tools/testing/selftests/powerpc/ptrace/ptrace-tm-spd-gpr.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/powerpc/ptrace/ptrace-tm-gpr.c b/tools/testing/selftests/powerpc/ptrace/ptrace-tm-gpr.c
index 82f7bdc2e5e6..7df7100a29be 100644
--- a/tools/testing/selftests/powerpc/ptrace/ptrace-tm-gpr.c
+++ b/tools/testing/selftests/powerpc/ptrace/ptrace-tm-gpr.c
@@ -57,7 +57,7 @@ void tm_gpr(void)
: [gpr_1]"i"(GPR_1), [gpr_2]"i"(GPR_2),
[sprn_texasr] "i" (SPRN_TEXASR), [flt_1] "b" (&a),
[flt_2] "b" (&b), [cptr1] "b" (&cptr[1])
- : "memory", "r7", "r8", "r9", "r10",
+ : "memory", "r0", "r7", "r8", "r9", "r10",
"r11", "r12", "r13", "r14", "r15", "r16",
"r17", "r18", "r19", "r20", "r21", "r22",
"r23", "r24", "r25", "r26", "r27", "r28",
diff --git a/tools/testing/selftests/powerpc/ptrace/ptrace-tm-spd-gpr.c b/tools/testing/selftests/powerpc/ptrace/ptrace-tm-spd-gpr.c
index ad65be6e8e85..8706bea5d015 100644
--- a/tools/testing/selftests/powerpc/ptrace/ptrace-tm-spd-gpr.c
+++ b/tools/testing/selftests/powerpc/ptrace/ptrace-tm-spd-gpr.c
@@ -65,7 +65,7 @@ void tm_spd_gpr(void)
: [gpr_1]"i"(GPR_1), [gpr_2]"i"(GPR_2), [gpr_4]"i"(GPR_4),
[sprn_texasr] "i" (SPRN_TEXASR), [flt_1] "b" (&a),
[flt_4] "b" (&d)
- : "memory", "r5", "r6", "r7",
+ : "memory", "r0", "r5", "r6", "r7",
"r8", "r9", "r10", "r11", "r12", "r13", "r14", "r15",
"r16", "r17", "r18", "r19", "r20", "r21", "r22", "r23",
"r24", "r25", "r26", "r27", "r28", "r29", "r30", "r31"
--
2.25.1
^ permalink raw reply related
* Re: [powerpc][next-20210727] Boot failure - kernel BUG at arch/powerpc/kernel/interrupt.c:98!
From: Nicholas Piggin @ 2021-07-29 4:08 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk, Nathan Chancellor, Sachin Sant,
Will Deacon
Cc: linuxppc-dev, iommu, linux-next, Claire Chang, Robin Murphy,
Christoph Hellwig, Anshuman Khandual
In-Reply-To: <YQGVZnMe9hFieF8D@Ryzen-9-3900X.localdomain>
Excerpts from Nathan Chancellor's message of July 29, 2021 3:35 am:
> On Wed, Jul 28, 2021 at 01:31:06PM +0530, Sachin Sant wrote:
>> linux-next fails to boot on Power server (POWER8/POWER9). Following traces
>> are seen during boot
>>
>> [ 0.010799] software IO TLB: tearing down default memory pool
>> [ 0.010805] ------------[ cut here ]------------
>> [ 0.010808] kernel BUG at arch/powerpc/kernel/interrupt.c:98!
>> [ 0.010812] Oops: Exception in kernel mode, sig: 5 [#1]
>> [ 0.010816] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
>> [ 0.010820] Modules linked in:
>> [ 0.010824] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.14.0-rc3-next-20210727 #1
>> [ 0.010830] NIP: c000000000032cfc LR: c00000000000c764 CTR: c00000000000c670
>> [ 0.010834] REGS: c000000003603b10 TRAP: 0700 Not tainted (5.14.0-rc3-next-20210727)
>> [ 0.010838] MSR: 8000000000029033 <SF,EE,ME,IR,DR,RI,LE> CR: 28000222 XER: 00000002
>> [ 0.010848] CFAR: c00000000000c760 IRQMASK: 3
>> [ 0.010848] GPR00: c00000000000c764 c000000003603db0 c0000000029bd000 0000000000000001
>> [ 0.010848] GPR04: 0000000000000a68 0000000000000400 c000000003603868 ffffffffffffffff
>> [ 0.010848] GPR08: 0000000000000000 0000000000000000 0000000000000000 0000000000000003
>> [ 0.010848] GPR12: ffffffffffffffff c00000001ec9ee80 c000000000012a28 0000000000000000
>> [ 0.010848] GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
>> [ 0.010848] GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
>> [ 0.010848] GPR24: 000000000000f134 0000000000000000 ffffffffffffffff c000000003603868
>> [ 0.010848] GPR28: 0000000000000400 0000000000000a68 c00000000202e9c0 c000000003603e80
>> [ 0.010896] NIP [c000000000032cfc] system_call_exception+0x8c/0x2e0
>> [ 0.010901] LR [c00000000000c764] system_call_common+0xf4/0x258
>> [ 0.010907] Call Trace:
>> [ 0.010909] [c000000003603db0] [c00000000016a6dc] calculate_sigpending+0x4c/0xe0 (unreliable)
>> [ 0.010915] [c000000003603e10] [c00000000000c764] system_call_common+0xf4/0x258
>> [ 0.010921] --- interrupt: c00 at kvm_template_end+0x4/0x8
>> [ 0.010926] NIP: c000000000092dec LR: c000000000114fc8 CTR: 0000000000000000
>> [ 0.010930] REGS: c000000003603e80 TRAP: 0c00 Not tainted (5.14.0-rc3-next-20210727)
>> [ 0.010934] MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 28000222 XER: 00000000
>> [ 0.010943] IRQMASK: 0
>> [ 0.010943] GPR00: c00000000202e9c0 c000000003603b00 c0000000029bd000 000000000000f134
>> [ 0.010943] GPR04: 0000000000000a68 0000000000000400 c000000003603868 ffffffffffffffff
>> [ 0.010943] GPR08: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
>> [ 0.010943] GPR12: 0000000000000000 c00000001ec9ee80 c000000000012a28 0000000000000000
>> [ 0.010943] GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
>> [ 0.010943] GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
>> [ 0.010943] GPR24: c0000000020033c4 c00000000110afc0 c000000002081950 c000000003277d40
>> [ 0.010943] GPR28: 0000000000000000 c00000000a680000 0000000004000000 00000000000d0000
>> [ 0.010989] NIP [c000000000092dec] kvm_template_end+0x4/0x8
>> [ 0.010993] LR [c000000000114fc8] set_memory_encrypted+0x38/0x60
>> [ 0.010999] --- interrupt: c00
>> [ 0.011001] [c000000003603b00] [c00000000000c764] system_call_common+0xf4/0x258 (unreliable)
>> [ 0.011008] Instruction dump:
>> [ 0.011011] 694a0003 312affff 7d495110 0b0a0000 60000000 60000000 e87f0108 68690002
>> [ 0.011019] 7929ffe2 0b090000 68634000 786397e2 <0b030000> e93f0138 792907e0 0b090000
>> [ 0.011029] ---[ end trace a20ad55589efcb10 ]---
>> [ 0.012297]
>> [ 1.012304] Kernel panic - not syncing: Fatal exception
>>
>> next-20210723 was good. The boot failure seems to have been introduced with next-20210726.
>>
>> I have attached the boot log.
>
> I noticed this with OpenSUSE's ppc64le config [1] and my bisect landed on
> commit ad6c00283163 ("swiotlb: Free tbl memory in swiotlb_exit()"). That
> series just keeps on giving... Adding some people from that thread to
> this one. Original thread:
> https://lore.kernel.org/r/1905CD70-7656-42AE-99E2-A31FC3812EAC@linux.vnet.ibm.com/
This is because powerpc's set_memory_encrypted makes an ultracall but it
does not exist on that processor.
x86's set_memory_encrypted/decrypted have
/* Nothing to do if memory encryption is not active */
if (!mem_encrypt_active())
return 0;
Probably powerpc should just do that too.
Thanks,
Nick
^ permalink raw reply
* Re: [PATCH v2 5/7] kallsyms: Rename is_kernel() and is_kernel_text()
From: Steven Rostedt @ 2021-07-29 4:05 UTC (permalink / raw)
To: Kefeng Wang
Cc: linux-arch, ryabinin.a.a, Daniel Borkmann, arnd, linux-kernel,
ast, Nathan Chancellor, mingo, paulus, Sami Tolvanen, bpf,
linuxppc-dev, davem
In-Reply-To: <1551f9cc-eaf8-efef-0590-e2549eebe4ae@huawei.com>
On Thu, 29 Jul 2021 10:00:51 +0800
Kefeng Wang <wangkefeng.wang@huawei.com> wrote:
> On 2021/7/28 23:28, Steven Rostedt wrote:
> > On Wed, 28 Jul 2021 16:13:18 +0800
> > Kefeng Wang <wangkefeng.wang@huawei.com> wrote:
> >
> >> The is_kernel[_text]() function check the address whether or not
> >> in kernel[_text] ranges, also they will check the address whether
> >> or not in gate area, so use better name.
> > Do you know what a gate area is?
> >
> > Because I believe gate area is kernel text, so the rename just makes it
> > redundant and more confusing.
>
> Yes, the gate area(eg, vectors part on ARM32, similar on x86/ia64) is
> kernel text.
>
> I want to keep the 'basic' section boundaries check, which only check
> the start/end
>
> of sections, all in section.h, could we use 'generic' or 'basic' or
> 'core' in the naming?
>
> * is_kernel_generic_data() --- come from core_kernel_data() in kernel.h
> * is_kernel_generic_text()
>
> The old helper could remain unchanged, any suggestion, thanks.
Because it looks like the check of just being in the range of "_stext"
to "_end" is just an internal helper, why not do what we do all over
the kernel, and just prefix the function with a couple of underscores,
that denote that it's internal?
__is_kernel_text()
Then you have:
static inline int is_kernel_text(unsigned long addr)
{
if (__is_kernel_text(addr))
return 1;
return in_gate_area_no_mm(addr);
}
-- Steve
^ permalink raw reply
* Re: [PATCH v5 2/2] KVM: PPC: Book3S HV: Stop forwarding all HFUs to L1
From: Nicholas Piggin @ 2021-07-29 3:52 UTC (permalink / raw)
To: Fabiano Rosas, kvm-ppc; +Cc: linuxppc-dev
In-Reply-To: <87o8anddsr.fsf@linux.ibm.com>
Excerpts from Fabiano Rosas's message of July 28, 2021 12:36 am:
> Nicholas Piggin <npiggin@gmail.com> writes:
>
>> Excerpts from Fabiano Rosas's message of July 27, 2021 6:17 am:
>>> If the nested hypervisor has no access to a facility because it has
>>> been disabled by the host, it should also not be able to see the
>>> Hypervisor Facility Unavailable that arises from one of its guests
>>> trying to access the facility.
>>>
>>> This patch turns a HFU that happened in L2 into a Hypervisor Emulation
>>> Assistance interrupt and forwards it to L1 for handling. The ones that
>>> happened because L1 explicitly disabled the facility for L2 are still
>>> let through, along with the corresponding Cause bits in the HFSCR.
>>>
>>> Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com>
>>> Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
>>> ---
>>> arch/powerpc/kvm/book3s_hv_nested.c | 32 +++++++++++++++++++++++------
>>> 1 file changed, 26 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/arch/powerpc/kvm/book3s_hv_nested.c b/arch/powerpc/kvm/book3s_hv_nested.c
>>> index 8215dbd4be9a..d544b092b49a 100644
>>> --- a/arch/powerpc/kvm/book3s_hv_nested.c
>>> +++ b/arch/powerpc/kvm/book3s_hv_nested.c
>>> @@ -99,7 +99,7 @@ static void byteswap_hv_regs(struct hv_guest_state *hr)
>>> hr->dawrx1 = swab64(hr->dawrx1);
>>> }
>>>
>>> -static void save_hv_return_state(struct kvm_vcpu *vcpu, int trap,
>>> +static void save_hv_return_state(struct kvm_vcpu *vcpu,
>>> struct hv_guest_state *hr)
>>> {
>>> struct kvmppc_vcore *vc = vcpu->arch.vcore;
>>> @@ -118,7 +118,7 @@ static void save_hv_return_state(struct kvm_vcpu *vcpu, int trap,
>>> hr->pidr = vcpu->arch.pid;
>>> hr->cfar = vcpu->arch.cfar;
>>> hr->ppr = vcpu->arch.ppr;
>>> - switch (trap) {
>>> + switch (vcpu->arch.trap) {
>>> case BOOK3S_INTERRUPT_H_DATA_STORAGE:
>>> hr->hdar = vcpu->arch.fault_dar;
>>> hr->hdsisr = vcpu->arch.fault_dsisr;
>>> @@ -128,9 +128,29 @@ static void save_hv_return_state(struct kvm_vcpu *vcpu, int trap,
>>> hr->asdr = vcpu->arch.fault_gpa;
>>> break;
>>> case BOOK3S_INTERRUPT_H_FAC_UNAVAIL:
>>> - hr->hfscr = ((~HFSCR_INTR_CAUSE & hr->hfscr) |
>>> - (HFSCR_INTR_CAUSE & vcpu->arch.hfscr));
>>> - break;
>>> + {
>>> + u8 cause = vcpu->arch.hfscr >> 56;
>>
>> Can this be u64 just to help gcc?
>>
>
> Yes.
>
>>> +
>>> + WARN_ON_ONCE(cause >= BITS_PER_LONG);
>>> +
>>> + if (!(hr->hfscr & (1UL << cause))) {
>>> + hr->hfscr = ((~HFSCR_INTR_CAUSE & hr->hfscr) |
>>> + (HFSCR_INTR_CAUSE & vcpu->arch.hfscr));
>>> + break;
>>> + }
>>> +
>>> + /*
>>> + * We have disabled this facility, so it does not
>>> + * exist from L1's perspective. Turn it into a HEAI.
>>> + */
>>> + vcpu->arch.trap = BOOK3S_INTERRUPT_H_EMUL_ASSIST;
>>> + kvmppc_load_last_inst(vcpu, INST_GENERIC, &vcpu->arch.emul_inst);
>>
>> Hmm, this doesn't handle kvmpc_load_last_inst failure. Other code tends
>> to just resume guest and retry in this case. Can we do that here?
>>
>
> Not at this point. The other code does that inside
> kvmppc_handle_exit_hv, which is called from kvmhv_run_single_vcpu. And
> since we're changing the interrupt, I cannot load the last instruction
> at kvmppc_handle_nested_exit because at that point this is still an HFU.
>
> Unless I do it anyway at the HFU handler and put a comment explaining
> the situation.
Yeah I think it would be better to move this logic to the nested exit
handler.
Thanks,
Nick
^ permalink raw reply
* Re: [PATCH] ibmvfc: fix command state accounting and stale response detection
From: Martin K. Petersen @ 2021-07-29 3:37 UTC (permalink / raw)
To: james.bottomley, Tyrel Datwyler
Cc: linux-scsi, Martin K . Petersen, linux-kernel, stable, brking,
linuxppc-dev
In-Reply-To: <20210716205220.1101150-1-tyreld@linux.ibm.com>
On Fri, 16 Jul 2021 14:52:20 -0600, Tyrel Datwyler wrote:
> Prior to commit 1f4a4a19508d ("scsi: ibmvfc: Complete commands outside
> the host/queue lock") responses to commands were completed sequentially
> with the host lock held such that a command had a basic binary state of
> active or free. It was therefore a simple affair of ensuring the
> assocaiated ibmvfc_event to a VIOS response was valid by testing that it
> was not already free. The lock relexation work to complete commands
> outside the lock inadverdently made it a trinary command state such that
> a command is either in flight, received and being completed, or
> completed and now free. This breaks the stale command detection logic as
> a command may be still marked active and been placed on the delayed
> completion list when a second stale response for the same command
> arrives. This can lead to double completions and list corruption. This
> issue was exposed by a recent VIOS regression were a missing memory
> barrier could occasionally result in the ibmvfc client receiveing a
> duplicate response for the same command.
>
> [...]
Applied to 5.14/scsi-fixes, thanks!
[1/1] ibmvfc: fix command state accounting and stale response detection
https://git.kernel.org/mkp/scsi/c/73bfdf707d01
--
Martin K. Petersen Oracle Linux Engineering
^ permalink raw reply
* Re: [PATCH v2 2/7] kallsyms: Fix address-checks for kernel related range
From: Kefeng Wang @ 2021-07-29 2:03 UTC (permalink / raw)
To: Steven Rostedt
Cc: linux-arch, Petr Mladek, ryabinin.a.a, arnd, Sergey Senozhatsky,
linux-kernel, ast, Sergey Senozhatsky, mingo, paulus,
linuxppc-dev, davem
In-Reply-To: <20210728104642.7ae75442@oasis.local.home>
On 2021/7/28 22:46, Steven Rostedt wrote:
> On Wed, 28 Jul 2021 16:13:15 +0800
> Kefeng Wang <wangkefeng.wang@huawei.com> wrote:
>
>> The is_kernel_inittext/is_kernel_text/is_kernel function should not
>> include the end address(the labels _einittext, _etext and _end) when
>> check the address range, the issue exists since Linux v2.6.12.
>>
>> Cc: Arnd Bergmann <arnd@arndb.de>
>> Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
>> Cc: Petr Mladek <pmladek@suse.com>
>> Acked-by: Sergey Senozhatsky <senozhatsky@chromium.org>
>> Reviewed-by: Petr Mladek <pmladek@suse.com>
>> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
> Reviewed-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Thanks.
>
> -- Steve
>
^ permalink raw reply
* Re: [PATCH v2 6/7] sections: Add new is_kernel() and is_kernel_text()
From: Kefeng Wang @ 2021-07-29 2:02 UTC (permalink / raw)
To: Steven Rostedt
Cc: linux-arch, ryabinin.a.a, arnd, linux-kernel, ast, mingo, paulus,
linuxppc-dev, davem
In-Reply-To: <20210728113204.67fa6dfc@oasis.local.home>
On 2021/7/28 23:32, Steven Rostedt wrote:
> On Wed, 28 Jul 2021 16:13:19 +0800
> Kefeng Wang <wangkefeng.wang@huawei.com> wrote:
>
>> @@ -64,8 +64,7 @@ const struct exception_table_entry *search_exception_tables(unsigned long addr)
>>
>> int notrace core_kernel_text(unsigned long addr)
>> {
>> - if (addr >= (unsigned long)_stext &&
>> - addr < (unsigned long)_etext)
>> + if (is_kernel_text(addr))
> Perhaps this was a bug, and these functions should be checking the gate
> area as well, as that is part of kernel text.
Ok, I would fix this if patch5 is reviewed well.
>
> -- Steve
>
>
>> return 1;
>>
>> if (system_state < SYSTEM_RUNNING &&
>> diff --git a/mm/kasan/report.c b/mm/kasan/report.c
>> index 884a950c7026..88f5b0c058b7 100644
>> --- a/mm/kasan/report.c
>> +++ b/mm/kasan/report.c
>> @@ -235,7 +235,7 @@ static void describe_object(struct kmem_cache *cache, void *object,
>>
>> static inline bool kernel_or_module_addr(const void *addr)
>> {
>> - if (addr >= (void *)_stext && addr < (void *)_end)
>> + if (is_kernel((unsigned long)addr))
>> return true;
>> if (is_module_address((unsigned long)addr))
>> return true;
>> --
> .
>
^ permalink raw reply
* Re: [PATCH v2 5/7] kallsyms: Rename is_kernel() and is_kernel_text()
From: Kefeng Wang @ 2021-07-29 2:00 UTC (permalink / raw)
To: Steven Rostedt
Cc: linux-arch, ryabinin.a.a, Daniel Borkmann, arnd, linux-kernel,
ast, Nathan Chancellor, mingo, paulus, Sami Tolvanen, bpf,
linuxppc-dev, davem
In-Reply-To: <20210728112836.289865f5@oasis.local.home>
On 2021/7/28 23:28, Steven Rostedt wrote:
> On Wed, 28 Jul 2021 16:13:18 +0800
> Kefeng Wang <wangkefeng.wang@huawei.com> wrote:
>
>> The is_kernel[_text]() function check the address whether or not
>> in kernel[_text] ranges, also they will check the address whether
>> or not in gate area, so use better name.
> Do you know what a gate area is?
>
> Because I believe gate area is kernel text, so the rename just makes it
> redundant and more confusing.
Yes, the gate area(eg, vectors part on ARM32, similar on x86/ia64) is
kernel text.
I want to keep the 'basic' section boundaries check, which only check
the start/end
of sections, all in section.h, could we use 'generic' or 'basic' or
'core' in the naming?
* is_kernel_generic_data() --- come from core_kernel_data() in kernel.h
* is_kernel_generic_text()
The old helper could remain unchanged, any suggestion, thanks.
>
> -- Steve
> .
>
^ permalink raw reply
* Re: [PATCH] arch: Kconfig: clean up obsolete use of HAVE_IDE
From: Jens Axboe @ 2021-07-28 19:59 UTC (permalink / raw)
To: Lukas Bulwahn, Christoph Hellwig, Randy Dunlap
Cc: uclinux-h8-devel, linux-xtensa, linux-ia64, linux-parisc,
linux-sh, x86, kernel-janitors, linux-mips, linux-kernel,
linux-m68k, linux-alpha, sparclinux, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <20210728182115.4401-1-lukas.bulwahn@gmail.com>
On 7/28/21 12:21 PM, Lukas Bulwahn wrote:
> The arch-specific Kconfig files use HAVE_IDE to indicate if IDE is
> supported.
>
> As IDE support and the HAVE_IDE config vanishes with commit b7fb14d3ac63
> ("ide: remove the legacy ide driver"), there is no need to mention
> HAVE_IDE in all those arch-specific Kconfig files.
>
> The issue was identified with ./scripts/checkkconfigsymbols.py.
Thanks, let's queue this for 5.14 to avoid any future conflicts with
it.
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH] arch: Kconfig: clean up obsolete use of HAVE_IDE
From: Randy Dunlap @ 2021-07-28 19:53 UTC (permalink / raw)
To: Lukas Bulwahn, Christoph Hellwig, Jens Axboe
Cc: uclinux-h8-devel, linux-xtensa, linux-ia64, linux-parisc,
linux-sh, x86, kernel-janitors, linux-mips, linux-kernel,
linux-m68k, linux-alpha, sparclinux, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <20210728182115.4401-1-lukas.bulwahn@gmail.com>
On 7/28/21 11:21 AM, Lukas Bulwahn wrote:
> The arch-specific Kconfig files use HAVE_IDE to indicate if IDE is
> supported.
>
> As IDE support and the HAVE_IDE config vanishes with commit b7fb14d3ac63
> ("ide: remove the legacy ide driver"), there is no need to mention
> HAVE_IDE in all those arch-specific Kconfig files.
>
> The issue was identified with ./scripts/checkkconfigsymbols.py.
>
> Fixes: b7fb14d3ac63 ("ide: remove the legacy ide driver")
> Suggested-by: Randy Dunlap <rdunlap@infradead.org>
> Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Thanks.
> ---
> arch/alpha/Kconfig | 1 -
> arch/arm/Kconfig | 6 ------
> arch/arm/mach-davinci/Kconfig | 1 -
> arch/h8300/Kconfig.cpu | 1 -
> arch/ia64/Kconfig | 1 -
> arch/m68k/Kconfig | 1 -
> arch/mips/Kconfig | 1 -
> arch/parisc/Kconfig | 1 -
> arch/powerpc/Kconfig | 1 -
> arch/sh/Kconfig | 1 -
> arch/sparc/Kconfig | 1 -
> arch/x86/Kconfig | 1 -
> arch/xtensa/Kconfig | 1 -
> 13 files changed, 18 deletions(-)
>
--
~Randy
^ permalink raw reply
* [PATCH] arch: Kconfig: clean up obsolete use of HAVE_IDE
From: Lukas Bulwahn @ 2021-07-28 18:21 UTC (permalink / raw)
To: Christoph Hellwig, Jens Axboe, Randy Dunlap
Cc: uclinux-h8-devel, linux-xtensa, linux-ia64, linux-parisc,
linux-sh, x86, kernel-janitors, linux-mips, linux-kernel,
linux-m68k, linux-alpha, sparclinux, Lukas Bulwahn, linuxppc-dev,
linux-arm-kernel
The arch-specific Kconfig files use HAVE_IDE to indicate if IDE is
supported.
As IDE support and the HAVE_IDE config vanishes with commit b7fb14d3ac63
("ide: remove the legacy ide driver"), there is no need to mention
HAVE_IDE in all those arch-specific Kconfig files.
The issue was identified with ./scripts/checkkconfigsymbols.py.
Fixes: b7fb14d3ac63 ("ide: remove the legacy ide driver")
Suggested-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
---
arch/alpha/Kconfig | 1 -
arch/arm/Kconfig | 6 ------
arch/arm/mach-davinci/Kconfig | 1 -
arch/h8300/Kconfig.cpu | 1 -
arch/ia64/Kconfig | 1 -
arch/m68k/Kconfig | 1 -
arch/mips/Kconfig | 1 -
arch/parisc/Kconfig | 1 -
arch/powerpc/Kconfig | 1 -
arch/sh/Kconfig | 1 -
arch/sparc/Kconfig | 1 -
arch/x86/Kconfig | 1 -
arch/xtensa/Kconfig | 1 -
13 files changed, 18 deletions(-)
diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig
index 77d3280dc678..a6d4c2f744e3 100644
--- a/arch/alpha/Kconfig
+++ b/arch/alpha/Kconfig
@@ -14,7 +14,6 @@ config ALPHA
select PCI_SYSCALL if PCI
select HAVE_AOUT
select HAVE_ASM_MODVERSIONS
- select HAVE_IDE
select HAVE_PCSPKR_PLATFORM
select HAVE_PERF_EVENTS
select NEED_DMA_MAP_STATE
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 82f908fa5676..2fb7012c3246 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -95,7 +95,6 @@ config ARM
select HAVE_FUNCTION_TRACER if !XIP_KERNEL
select HAVE_GCC_PLUGINS
select HAVE_HW_BREAKPOINT if PERF_EVENTS && (CPU_V6 || CPU_V6K || CPU_V7)
- select HAVE_IDE if PCI || ISA || PCMCIA
select HAVE_IRQ_TIME_ACCOUNTING
select HAVE_KERNEL_GZIP
select HAVE_KERNEL_LZ4
@@ -361,7 +360,6 @@ config ARCH_FOOTBRIDGE
bool "FootBridge"
select CPU_SA110
select FOOTBRIDGE
- select HAVE_IDE
select NEED_MACH_IO_H if !MMU
select NEED_MACH_MEMORY_H
help
@@ -430,7 +428,6 @@ config ARCH_PXA
select GENERIC_IRQ_MULTI_HANDLER
select GPIO_PXA
select GPIOLIB
- select HAVE_IDE
select IRQ_DOMAIN
select PLAT_PXA
select SPARSE_IRQ
@@ -446,7 +443,6 @@ config ARCH_RPC
select ARM_HAS_SG_CHAIN
select CPU_SA110
select FIQ
- select HAVE_IDE
select HAVE_PATA_PLATFORM
select ISA_DMA_API
select LEGACY_TIMER_TICK
@@ -469,7 +465,6 @@ config ARCH_SA1100
select CPU_SA1100
select GENERIC_IRQ_MULTI_HANDLER
select GPIOLIB
- select HAVE_IDE
select IRQ_DOMAIN
select ISA
select NEED_MACH_MEMORY_H
@@ -505,7 +500,6 @@ config ARCH_OMAP1
select GENERIC_IRQ_CHIP
select GENERIC_IRQ_MULTI_HANDLER
select GPIOLIB
- select HAVE_IDE
select HAVE_LEGACY_CLK
select IRQ_DOMAIN
select NEED_MACH_IO_H if PCCARD
diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
index de11030748d0..1d3aef84287d 100644
--- a/arch/arm/mach-davinci/Kconfig
+++ b/arch/arm/mach-davinci/Kconfig
@@ -9,7 +9,6 @@ menuconfig ARCH_DAVINCI
select PM_GENERIC_DOMAINS_OF if PM && OF
select REGMAP_MMIO
select RESET_CONTROLLER
- select HAVE_IDE
select PINCTRL_SINGLE
if ARCH_DAVINCI
diff --git a/arch/h8300/Kconfig.cpu b/arch/h8300/Kconfig.cpu
index 2b9cbaf41cd0..e4467d40107d 100644
--- a/arch/h8300/Kconfig.cpu
+++ b/arch/h8300/Kconfig.cpu
@@ -44,7 +44,6 @@ config H8300_H8MAX
bool "H8MAX"
select H83069
select RAMKERNEL
- select HAVE_IDE
help
H8MAX Evaluation Board Support
More Information. (Japanese Only)
diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig
index cf425c2c63af..4993c7ac7ff6 100644
--- a/arch/ia64/Kconfig
+++ b/arch/ia64/Kconfig
@@ -25,7 +25,6 @@ config IA64
select HAVE_ASM_MODVERSIONS
select HAVE_UNSTABLE_SCHED_CLOCK
select HAVE_EXIT_THREAD
- select HAVE_IDE
select HAVE_KPROBES
select HAVE_KRETPROBES
select HAVE_FTRACE_MCOUNT_RECORD
diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig
index 96989ad46f66..d632a1d576f9 100644
--- a/arch/m68k/Kconfig
+++ b/arch/m68k/Kconfig
@@ -23,7 +23,6 @@ config M68K
select HAVE_DEBUG_BUGVERBOSE
select HAVE_EFFICIENT_UNALIGNED_ACCESS if !CPU_HAS_NO_UNALIGNED
select HAVE_FUTEX_CMPXCHG if MMU && FUTEX
- select HAVE_IDE
select HAVE_MOD_ARCH_SPECIFIC
select HAVE_UID16
select MMU_GATHER_NO_RANGE if MMU
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index cee6087cd686..6dfb27d531dd 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -71,7 +71,6 @@ config MIPS
select HAVE_FUNCTION_TRACER
select HAVE_GCC_PLUGINS
select HAVE_GENERIC_VDSO
- select HAVE_IDE
select HAVE_IOREMAP_PROT
select HAVE_IRQ_EXIT_ON_IRQ_STACK
select HAVE_IRQ_TIME_ACCOUNTING
diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig
index bde9907bc5b2..4f8c1fbf8f2f 100644
--- a/arch/parisc/Kconfig
+++ b/arch/parisc/Kconfig
@@ -3,7 +3,6 @@ config PARISC
def_bool y
select ARCH_32BIT_OFF_T if !64BIT
select ARCH_MIGHT_HAVE_PC_PARPORT
- select HAVE_IDE
select HAVE_FUNCTION_TRACER
select HAVE_FUNCTION_GRAPH_TRACER
select HAVE_SYSCALL_TRACEPOINTS
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 53db06ba4223..2e213ec6ec05 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -220,7 +220,6 @@ config PPC
select HAVE_HARDLOCKUP_DETECTOR_ARCH if PPC_BOOK3S_64 && SMP
select HAVE_HARDLOCKUP_DETECTOR_PERF if PERF_EVENTS && HAVE_PERF_EVENTS_NMI && !HAVE_HARDLOCKUP_DETECTOR_ARCH
select HAVE_HW_BREAKPOINT if PERF_EVENTS && (PPC_BOOK3S || PPC_8xx)
- select HAVE_IDE
select HAVE_IOREMAP_PROT
select HAVE_IRQ_EXIT_ON_IRQ_STACK
select HAVE_IRQ_TIME_ACCOUNTING
diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig
index 45a0549421cd..b683b69a4556 100644
--- a/arch/sh/Kconfig
+++ b/arch/sh/Kconfig
@@ -39,7 +39,6 @@ config SUPERH
select HAVE_FUTEX_CMPXCHG if FUTEX
select HAVE_FTRACE_MCOUNT_RECORD
select HAVE_HW_BREAKPOINT
- select HAVE_IDE if HAS_IOPORT_MAP
select HAVE_IOREMAP_PROT if MMU && !X2TLB
select HAVE_KERNEL_BZIP2
select HAVE_KERNEL_GZIP
diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig
index c5fa7932b550..f0c0f955e169 100644
--- a/arch/sparc/Kconfig
+++ b/arch/sparc/Kconfig
@@ -19,7 +19,6 @@ config SPARC
select OF
select OF_PROMTREE
select HAVE_ASM_MODVERSIONS
- select HAVE_IDE
select HAVE_ARCH_KGDB if !SMP || SPARC64
select HAVE_ARCH_TRACEHOOK
select HAVE_ARCH_SECCOMP if SPARC64
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 89a286d5e4b9..ff0769cd4b31 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -202,7 +202,6 @@ config X86
select HAVE_FUNCTION_TRACER
select HAVE_GCC_PLUGINS
select HAVE_HW_BREAKPOINT
- select HAVE_IDE
select HAVE_IOREMAP_PROT
select HAVE_IRQ_EXIT_ON_IRQ_STACK if X86_64
select HAVE_IRQ_TIME_ACCOUNTING
diff --git a/arch/xtensa/Kconfig b/arch/xtensa/Kconfig
index 1bdb55c2d0c1..b843902ad9fd 100644
--- a/arch/xtensa/Kconfig
+++ b/arch/xtensa/Kconfig
@@ -327,7 +327,6 @@ config XTENSA_PLATFORM_ISS
config XTENSA_PLATFORM_XT2000
bool "XT2000"
- select HAVE_IDE
help
XT2000 is the name of Tensilica's feature-rich emulation platform.
This hardware is capable of running a full Linux distribution.
--
2.17.1
^ permalink raw reply related
* [PATCHv2 3/3] powerpc/smp: Use existing L2 cache_map cpumask to find L3 cache siblings
From: Parth Shah @ 2021-07-28 17:56 UTC (permalink / raw)
To: linuxppc-dev; +Cc: ego, mikey, srikar, parths1229, svaidy
In-Reply-To: <20210728175607.591679-1-parth@linux.ibm.com>
On POWER10 systems, the "ibm,thread-groups" property "2" indicates the cpus
in thread-group share both L2 and L3 caches. Hence, use cache_property = 2
itself to find both the L2 and L3 cache siblings.
Hence, create a new thread_group_l3_cache_map to keep list of L3 siblings,
but fill the mask using same property "2" array.
Signed-off-by: Parth Shah <parth@linux.ibm.com>
---
arch/powerpc/include/asm/smp.h | 3 ++
arch/powerpc/kernel/cacheinfo.c | 3 ++
arch/powerpc/kernel/smp.c | 66 ++++++++++++++++++++++-----------
3 files changed, 51 insertions(+), 21 deletions(-)
diff --git a/arch/powerpc/include/asm/smp.h b/arch/powerpc/include/asm/smp.h
index 1259040cc3a4..7ef1cd8168a0 100644
--- a/arch/powerpc/include/asm/smp.h
+++ b/arch/powerpc/include/asm/smp.h
@@ -35,6 +35,7 @@ extern int *chip_id_lookup_table;
DECLARE_PER_CPU(cpumask_var_t, thread_group_l1_cache_map);
DECLARE_PER_CPU(cpumask_var_t, thread_group_l2_cache_map);
+DECLARE_PER_CPU(cpumask_var_t, thread_group_l3_cache_map);
#ifdef CONFIG_SMP
@@ -144,6 +145,7 @@ extern int cpu_to_core_id(int cpu);
extern bool has_big_cores;
extern bool thread_group_shares_l2;
+extern bool thread_group_shares_l3;
#define cpu_smt_mask cpu_smt_mask
#ifdef CONFIG_SCHED_SMT
@@ -198,6 +200,7 @@ extern void __cpu_die(unsigned int cpu);
#define hard_smp_processor_id() get_hard_smp_processor_id(0)
#define smp_setup_cpu_maps()
#define thread_group_shares_l2 0
+#define thread_group_shares_l3 0
static inline void inhibit_secondary_onlining(void) {}
static inline void uninhibit_secondary_onlining(void) {}
static inline const struct cpumask *cpu_sibling_mask(int cpu)
diff --git a/arch/powerpc/kernel/cacheinfo.c b/arch/powerpc/kernel/cacheinfo.c
index 20d91693eac1..cf1be75b7833 100644
--- a/arch/powerpc/kernel/cacheinfo.c
+++ b/arch/powerpc/kernel/cacheinfo.c
@@ -469,6 +469,9 @@ static int get_group_id(unsigned int cpu_id, int level)
else if (thread_group_shares_l2 && level == 2)
return cpumask_first(per_cpu(thread_group_l2_cache_map,
cpu_id));
+ else if (thread_group_shares_l3 && level == 3)
+ return cpumask_first(per_cpu(thread_group_l3_cache_map,
+ cpu_id));
return -1;
}
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index a7fcac44a8e2..f2abd88e0c25 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -78,6 +78,7 @@ struct task_struct *secondary_current;
bool has_big_cores;
bool coregroup_enabled;
bool thread_group_shares_l2;
+bool thread_group_shares_l3;
DEFINE_PER_CPU(cpumask_var_t, cpu_sibling_map);
DEFINE_PER_CPU(cpumask_var_t, cpu_smallcore_map);
@@ -101,7 +102,7 @@ enum {
#define MAX_THREAD_LIST_SIZE 8
#define THREAD_GROUP_SHARE_L1 1
-#define THREAD_GROUP_SHARE_L2 2
+#define THREAD_GROUP_SHARE_L2_L3 2
struct thread_groups {
unsigned int property;
unsigned int nr_groups;
@@ -131,6 +132,12 @@ DEFINE_PER_CPU(cpumask_var_t, thread_group_l1_cache_map);
*/
DEFINE_PER_CPU(cpumask_var_t, thread_group_l2_cache_map);
+/*
+ * On P10, thread_group_l3_cache_map for each CPU is equal to the
+ * thread_group_l2_cache_map
+ */
+DEFINE_PER_CPU(cpumask_var_t, thread_group_l3_cache_map);
+
/* SMP operations for this machine */
struct smp_ops_t *smp_ops;
@@ -889,19 +896,41 @@ static struct thread_groups *__init get_thread_groups(int cpu,
return tg;
}
+static int update_mask_from_threadgroup(cpumask_var_t *mask, struct thread_groups *tg, int cpu, int cpu_group_start)
+{
+ int first_thread = cpu_first_thread_sibling(cpu);
+ int i;
+
+ zalloc_cpumask_var_node(mask, GFP_KERNEL, cpu_to_node(cpu));
+
+ for (i = first_thread; i < first_thread + threads_per_core; i++) {
+ int i_group_start = get_cpu_thread_group_start(i, tg);
+
+ if (unlikely(i_group_start == -1)) {
+ WARN_ON_ONCE(1);
+ return -ENODATA;
+ }
+
+ if (i_group_start == cpu_group_start)
+ cpumask_set_cpu(i, *mask);
+ }
+
+ return 0;
+}
+
static int __init init_thread_group_cache_map(int cpu, int cache_property)
{
- int first_thread = cpu_first_thread_sibling(cpu);
- int i, cpu_group_start = -1, err = 0;
+ int cpu_group_start = -1, err = 0;
struct thread_groups *tg = NULL;
cpumask_var_t *mask = NULL;
if (cache_property != THREAD_GROUP_SHARE_L1 &&
- cache_property != THREAD_GROUP_SHARE_L2)
+ cache_property != THREAD_GROUP_SHARE_L2_L3)
return -EINVAL;
tg = get_thread_groups(cpu, cache_property, &err);
+
if (!tg)
return err;
@@ -912,25 +941,18 @@ static int __init init_thread_group_cache_map(int cpu, int cache_property)
return -ENODATA;
}
- if (cache_property == THREAD_GROUP_SHARE_L1)
+ if (cache_property == THREAD_GROUP_SHARE_L1) {
mask = &per_cpu(thread_group_l1_cache_map, cpu);
- else if (cache_property == THREAD_GROUP_SHARE_L2)
+ update_mask_from_threadgroup(mask, tg, cpu, cpu_group_start);
+ }
+ else if (cache_property == THREAD_GROUP_SHARE_L2_L3) {
mask = &per_cpu(thread_group_l2_cache_map, cpu);
-
- zalloc_cpumask_var_node(mask, GFP_KERNEL, cpu_to_node(cpu));
-
- for (i = first_thread; i < first_thread + threads_per_core; i++) {
- int i_group_start = get_cpu_thread_group_start(i, tg);
-
- if (unlikely(i_group_start == -1)) {
- WARN_ON_ONCE(1);
- return -ENODATA;
- }
-
- if (i_group_start == cpu_group_start)
- cpumask_set_cpu(i, *mask);
+ update_mask_from_threadgroup(mask, tg, cpu, cpu_group_start);
+ mask = &per_cpu(thread_group_l3_cache_map, cpu);
+ update_mask_from_threadgroup(mask, tg, cpu, cpu_group_start);
}
+
return 0;
}
@@ -1020,14 +1042,16 @@ static int __init init_big_cores(void)
has_big_cores = true;
for_each_possible_cpu(cpu) {
- int err = init_thread_group_cache_map(cpu, THREAD_GROUP_SHARE_L2);
+ int err = init_thread_group_cache_map(cpu, THREAD_GROUP_SHARE_L2_L3);
if (err)
return err;
}
thread_group_shares_l2 = true;
- pr_debug("L2 cache only shared by the threads in the small core\n");
+ thread_group_shares_l3 = true;
+ pr_debug("L2/L3 cache only shared by the threads in the small core\n");
+
return 0;
}
--
2.26.3
^ permalink raw reply related
* [PATCHv2 2/3] powerpc/cacheinfo: Remove the redundant get_shared_cpu_map()
From: Parth Shah @ 2021-07-28 17:56 UTC (permalink / raw)
To: linuxppc-dev; +Cc: ego, mikey, srikar, parths1229, svaidy
In-Reply-To: <20210728175607.591679-1-parth@linux.ibm.com>
From: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>
The helper function get_shared_cpu_map() was added in
'commit 500fe5f550ec ("powerpc/cacheinfo: Report the correct
shared_cpu_map on big-cores")'
and subsequently expanded upon in
'commit 0be47634db0b ("powerpc/cacheinfo: Print correct cache-sibling
map/list for L2 cache")'
in order to help report the correct groups of threads sharing these caches
on big-core systems where groups of threads within a core can share
different sets of caches.
Now that powerpc/cacheinfo is aware of "ibm,thread-groups" property,
cache->shared_cpu_map contains the correct set of thread-siblings
sharing the cache. Hence we no longer need the functions
get_shared_cpu_map(). This patch removes this function. We also remove
the helper function index_dir_to_cpu() which was only called by
get_shared_cpu_map().
With these functions removed, we can still see the correct
cache-sibling map/list for L1 and L2 caches on systems with L1 and L2
caches distributed among groups of threads in a core.
With this patch, on a SMT8 POWER10 system where the L1 and L2 caches
are split between the two groups of threads in a core, for CPUs 8,9,
the L1-Data, L1-Instruction, L2, L3 cache CPU sibling list is as
follows:
$ grep . /sys/devices/system/cpu/cpu[89]/cache/index[0123]/shared_cpu_list
/sys/devices/system/cpu/cpu8/cache/index0/shared_cpu_list:8,10,12,14
/sys/devices/system/cpu/cpu8/cache/index1/shared_cpu_list:8,10,12,14
/sys/devices/system/cpu/cpu8/cache/index2/shared_cpu_list:8,10,12,14
/sys/devices/system/cpu/cpu8/cache/index3/shared_cpu_list:8-15
/sys/devices/system/cpu/cpu9/cache/index0/shared_cpu_list:9,11,13,15
/sys/devices/system/cpu/cpu9/cache/index1/shared_cpu_list:9,11,13,15
/sys/devices/system/cpu/cpu9/cache/index2/shared_cpu_list:9,11,13,15
/sys/devices/system/cpu/cpu9/cache/index3/shared_cpu_list:8-15
$ ppc64_cpu --smt=4
$ grep . /sys/devices/system/cpu/cpu[89]/cache/index[0123]/shared_cpu_list
/sys/devices/system/cpu/cpu8/cache/index0/shared_cpu_list:8,10
/sys/devices/system/cpu/cpu8/cache/index1/shared_cpu_list:8,10
/sys/devices/system/cpu/cpu8/cache/index2/shared_cpu_list:8,10
/sys/devices/system/cpu/cpu8/cache/index3/shared_cpu_list:8-11
/sys/devices/system/cpu/cpu9/cache/index0/shared_cpu_list:9,11
/sys/devices/system/cpu/cpu9/cache/index1/shared_cpu_list:9,11
/sys/devices/system/cpu/cpu9/cache/index2/shared_cpu_list:9,11
/sys/devices/system/cpu/cpu9/cache/index3/shared_cpu_list:8-11
$ ppc64_cpu --smt=2
$ grep . /sys/devices/system/cpu/cpu[89]/cache/index[0123]/shared_cpu_list
/sys/devices/system/cpu/cpu8/cache/index0/shared_cpu_list:8
/sys/devices/system/cpu/cpu8/cache/index1/shared_cpu_list:8
/sys/devices/system/cpu/cpu8/cache/index2/shared_cpu_list:8
/sys/devices/system/cpu/cpu8/cache/index3/shared_cpu_list:8-9
/sys/devices/system/cpu/cpu9/cache/index0/shared_cpu_list:9
/sys/devices/system/cpu/cpu9/cache/index1/shared_cpu_list:9
/sys/devices/system/cpu/cpu9/cache/index2/shared_cpu_list:9
/sys/devices/system/cpu/cpu9/cache/index3/shared_cpu_list:8-9
$ ppc64_cpu --smt=1
$ grep . /sys/devices/system/cpu/cpu[89]/cache/index[0123]/shared_cpu_list
/sys/devices/system/cpu/cpu8/cache/index0/shared_cpu_list:8
/sys/devices/system/cpu/cpu8/cache/index1/shared_cpu_list:8
/sys/devices/system/cpu/cpu8/cache/index2/shared_cpu_list:8
/sys/devices/system/cpu/cpu8/cache/index3/shared_cpu_list:8
Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
---
arch/powerpc/kernel/cacheinfo.c | 41 +--------------------------------
1 file changed, 1 insertion(+), 40 deletions(-)
diff --git a/arch/powerpc/kernel/cacheinfo.c b/arch/powerpc/kernel/cacheinfo.c
index 5a6925d87424..20d91693eac1 100644
--- a/arch/powerpc/kernel/cacheinfo.c
+++ b/arch/powerpc/kernel/cacheinfo.c
@@ -675,45 +675,6 @@ static ssize_t level_show(struct kobject *k, struct kobj_attribute *attr, char *
static struct kobj_attribute cache_level_attr =
__ATTR(level, 0444, level_show, NULL);
-static unsigned int index_dir_to_cpu(struct cache_index_dir *index)
-{
- struct kobject *index_dir_kobj = &index->kobj;
- struct kobject *cache_dir_kobj = index_dir_kobj->parent;
- struct kobject *cpu_dev_kobj = cache_dir_kobj->parent;
- struct device *dev = kobj_to_dev(cpu_dev_kobj);
-
- return dev->id;
-}
-
-/*
- * On big-core systems, each core has two groups of CPUs each of which
- * has its own L1-cache. The thread-siblings which share l1-cache with
- * @cpu can be obtained via cpu_smallcore_mask().
- *
- * On some big-core systems, the L2 cache is shared only between some
- * groups of siblings. This is already parsed and encoded in
- * cpu_l2_cache_mask().
- *
- * TODO: cache_lookup_or_instantiate() needs to be made aware of the
- * "ibm,thread-groups" property so that cache->shared_cpu_map
- * reflects the correct siblings on platforms that have this
- * device-tree property. This helper function is only a stop-gap
- * solution so that we report the correct siblings to the
- * userspace via sysfs.
- */
-static const struct cpumask *get_shared_cpu_map(struct cache_index_dir *index, struct cache *cache)
-{
- if (has_big_cores) {
- int cpu = index_dir_to_cpu(index);
- if (cache->level == 1)
- return cpu_smallcore_mask(cpu);
- if (cache->level == 2 && thread_group_shares_l2)
- return cpu_l2_cache_mask(cpu);
- }
-
- return &cache->shared_cpu_map;
-}
-
static ssize_t
show_shared_cpumap(struct kobject *k, struct kobj_attribute *attr, char *buf, bool list)
{
@@ -724,7 +685,7 @@ show_shared_cpumap(struct kobject *k, struct kobj_attribute *attr, char *buf, bo
index = kobj_to_cache_index_dir(k);
cache = index->cache;
- mask = get_shared_cpu_map(index, cache);
+ mask = &cache->shared_cpu_map;
return cpumap_print_to_pagebuf(list, buf, mask);
}
--
2.26.3
^ permalink raw reply related
* [PATCHv2 1/3] powerpc/cacheinfo: Lookup cache by dt node and thread-group id
From: Parth Shah @ 2021-07-28 17:56 UTC (permalink / raw)
To: linuxppc-dev; +Cc: ego, mikey, srikar, parths1229, svaidy
In-Reply-To: <20210728175607.591679-1-parth@linux.ibm.com>
From: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>
Currently the cacheinfo code on powerpc indexes the "cache" objects
(modelling the L1/L2/L3 caches) where the key is device-tree node
corresponding to that cache. On some of the POWER server platforms
thread-groups within the core share different sets of caches (Eg: On
SMT8 POWER9 systems, threads 0,2,4,6 of a core share L1 cache and
threads 1,3,5,7 of the same core share another L1 cache). On such
platforms, there is a single device-tree node corresponding to that
cache and the cache-configuration within the threads of the core is
indicated via "ibm,thread-groups" device-tree property.
Since the current code is not aware of the "ibm,thread-groups"
property, on the aforementoined systems, cacheinfo code still treats
all the threads in the core to be sharing the cache because of the
single device-tree node (In the earlier example, the cacheinfo code
would says CPUs 0-7 share L1 cache).
In this patch, we make the powerpc cacheinfo code aware of the
"ibm,thread-groups" property. We indexe the "cache" objects by the
key-pair (device-tree node, thread-group id). For any CPUX, for a
given level of cache, the thread-group id is defined to be the first
CPU in the "ibm,thread-groups" cache-group containing CPUX. For levels
of cache which are not represented in "ibm,thread-groups" property,
the thread-group id is -1.
Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
[parth: Remove "static" keyword for the definition of "thread_group_l1_cache_map"
and "thread_group_l2_cache_map" to get rid of the compile error.]
Signed-off-by: Parth Shah <parth@linux.ibm.com>
---
arch/powerpc/include/asm/smp.h | 3 ++
arch/powerpc/kernel/cacheinfo.c | 80 ++++++++++++++++++++++++---------
arch/powerpc/kernel/smp.c | 4 +-
3 files changed, 63 insertions(+), 24 deletions(-)
diff --git a/arch/powerpc/include/asm/smp.h b/arch/powerpc/include/asm/smp.h
index 03b3d010cbab..1259040cc3a4 100644
--- a/arch/powerpc/include/asm/smp.h
+++ b/arch/powerpc/include/asm/smp.h
@@ -33,6 +33,9 @@ extern bool coregroup_enabled;
extern int cpu_to_chip_id(int cpu);
extern int *chip_id_lookup_table;
+DECLARE_PER_CPU(cpumask_var_t, thread_group_l1_cache_map);
+DECLARE_PER_CPU(cpumask_var_t, thread_group_l2_cache_map);
+
#ifdef CONFIG_SMP
struct smp_ops_t {
diff --git a/arch/powerpc/kernel/cacheinfo.c b/arch/powerpc/kernel/cacheinfo.c
index 6f903e9aa20b..5a6925d87424 100644
--- a/arch/powerpc/kernel/cacheinfo.c
+++ b/arch/powerpc/kernel/cacheinfo.c
@@ -120,6 +120,7 @@ struct cache {
struct cpumask shared_cpu_map; /* online CPUs using this cache */
int type; /* split cache disambiguation */
int level; /* level not explicit in device tree */
+ int group_id; /* id of the group of threads that share this cache */
struct list_head list; /* global list of cache objects */
struct cache *next_local; /* next cache of >= level */
};
@@ -142,22 +143,24 @@ static const char *cache_type_string(const struct cache *cache)
}
static void cache_init(struct cache *cache, int type, int level,
- struct device_node *ofnode)
+ struct device_node *ofnode, int group_id)
{
cache->type = type;
cache->level = level;
cache->ofnode = of_node_get(ofnode);
+ cache->group_id = group_id;
INIT_LIST_HEAD(&cache->list);
list_add(&cache->list, &cache_list);
}
-static struct cache *new_cache(int type, int level, struct device_node *ofnode)
+static struct cache *new_cache(int type, int level,
+ struct device_node *ofnode, int group_id)
{
struct cache *cache;
cache = kzalloc(sizeof(*cache), GFP_KERNEL);
if (cache)
- cache_init(cache, type, level, ofnode);
+ cache_init(cache, type, level, ofnode, group_id);
return cache;
}
@@ -309,20 +312,24 @@ static struct cache *cache_find_first_sibling(struct cache *cache)
return cache;
list_for_each_entry(iter, &cache_list, list)
- if (iter->ofnode == cache->ofnode && iter->next_local == cache)
+ if (iter->ofnode == cache->ofnode &&
+ iter->group_id == cache->group_id &&
+ iter->next_local == cache)
return iter;
return cache;
}
-/* return the first cache on a local list matching node */
-static struct cache *cache_lookup_by_node(const struct device_node *node)
+/* return the first cache on a local list matching node and thread-group id */
+static struct cache *cache_lookup_by_node_group(const struct device_node *node,
+ int group_id)
{
struct cache *cache = NULL;
struct cache *iter;
list_for_each_entry(iter, &cache_list, list) {
- if (iter->ofnode != node)
+ if (iter->ofnode != node ||
+ iter->group_id != group_id)
continue;
cache = cache_find_first_sibling(iter);
break;
@@ -352,14 +359,15 @@ static int cache_is_unified_d(const struct device_node *np)
CACHE_TYPE_UNIFIED_D : CACHE_TYPE_UNIFIED;
}
-static struct cache *cache_do_one_devnode_unified(struct device_node *node, int level)
+static struct cache *cache_do_one_devnode_unified(struct device_node *node, int group_id,
+ int level)
{
pr_debug("creating L%d ucache for %pOFP\n", level, node);
- return new_cache(cache_is_unified_d(node), level, node);
+ return new_cache(cache_is_unified_d(node), level, node, group_id);
}
-static struct cache *cache_do_one_devnode_split(struct device_node *node,
+static struct cache *cache_do_one_devnode_split(struct device_node *node, int group_id,
int level)
{
struct cache *dcache, *icache;
@@ -367,8 +375,8 @@ static struct cache *cache_do_one_devnode_split(struct device_node *node,
pr_debug("creating L%d dcache and icache for %pOFP\n", level,
node);
- dcache = new_cache(CACHE_TYPE_DATA, level, node);
- icache = new_cache(CACHE_TYPE_INSTRUCTION, level, node);
+ dcache = new_cache(CACHE_TYPE_DATA, level, node, group_id);
+ icache = new_cache(CACHE_TYPE_INSTRUCTION, level, node, group_id);
if (!dcache || !icache)
goto err;
@@ -382,31 +390,32 @@ static struct cache *cache_do_one_devnode_split(struct device_node *node,
return NULL;
}
-static struct cache *cache_do_one_devnode(struct device_node *node, int level)
+static struct cache *cache_do_one_devnode(struct device_node *node, int group_id, int level)
{
struct cache *cache;
if (cache_node_is_unified(node))
- cache = cache_do_one_devnode_unified(node, level);
+ cache = cache_do_one_devnode_unified(node, group_id, level);
else
- cache = cache_do_one_devnode_split(node, level);
+ cache = cache_do_one_devnode_split(node, group_id, level);
return cache;
}
static struct cache *cache_lookup_or_instantiate(struct device_node *node,
+ int group_id,
int level)
{
struct cache *cache;
- cache = cache_lookup_by_node(node);
+ cache = cache_lookup_by_node_group(node, group_id);
WARN_ONCE(cache && cache->level != level,
"cache level mismatch on lookup (got %d, expected %d)\n",
cache->level, level);
if (!cache)
- cache = cache_do_one_devnode(node, level);
+ cache = cache_do_one_devnode(node, group_id, level);
return cache;
}
@@ -443,7 +452,27 @@ static void do_subsidiary_caches_debugcheck(struct cache *cache)
of_node_get_device_type(cache->ofnode));
}
-static void do_subsidiary_caches(struct cache *cache)
+/*
+ * If sub-groups of threads in a core containing @cpu_id share the
+ * L@level-cache (information obtained via "ibm,thread-groups"
+ * device-tree property), then we identify the group by the first
+ * thread-sibling in the group. We define this to be the group-id.
+ *
+ * In the absence of any thread-group information for L@level-cache,
+ * this function returns -1.
+ */
+static int get_group_id(unsigned int cpu_id, int level)
+{
+ if (has_big_cores && level == 1)
+ return cpumask_first(per_cpu(thread_group_l1_cache_map,
+ cpu_id));
+ else if (thread_group_shares_l2 && level == 2)
+ return cpumask_first(per_cpu(thread_group_l2_cache_map,
+ cpu_id));
+ return -1;
+}
+
+static void do_subsidiary_caches(struct cache *cache, unsigned int cpu_id)
{
struct device_node *subcache_node;
int level = cache->level;
@@ -452,9 +481,11 @@ static void do_subsidiary_caches(struct cache *cache)
while ((subcache_node = of_find_next_cache_node(cache->ofnode))) {
struct cache *subcache;
+ int group_id;
level++;
- subcache = cache_lookup_or_instantiate(subcache_node, level);
+ group_id = get_group_id(cpu_id, level);
+ subcache = cache_lookup_or_instantiate(subcache_node, group_id, level);
of_node_put(subcache_node);
if (!subcache)
break;
@@ -468,6 +499,7 @@ static struct cache *cache_chain_instantiate(unsigned int cpu_id)
{
struct device_node *cpu_node;
struct cache *cpu_cache = NULL;
+ int group_id;
pr_debug("creating cache object(s) for CPU %i\n", cpu_id);
@@ -476,11 +508,13 @@ static struct cache *cache_chain_instantiate(unsigned int cpu_id)
if (!cpu_node)
goto out;
- cpu_cache = cache_lookup_or_instantiate(cpu_node, 1);
+ group_id = get_group_id(cpu_id, 1);
+
+ cpu_cache = cache_lookup_or_instantiate(cpu_node, group_id, 1);
if (!cpu_cache)
goto out;
- do_subsidiary_caches(cpu_cache);
+ do_subsidiary_caches(cpu_cache, cpu_id);
cache_cpu_set(cpu_cache, cpu_id);
out:
@@ -848,13 +882,15 @@ static struct cache *cache_lookup_by_cpu(unsigned int cpu_id)
{
struct device_node *cpu_node;
struct cache *cache;
+ int group_id;
cpu_node = of_get_cpu_node(cpu_id, NULL);
WARN_ONCE(!cpu_node, "no OF node found for CPU %i\n", cpu_id);
if (!cpu_node)
return NULL;
- cache = cache_lookup_by_node(cpu_node);
+ group_id = get_group_id(cpu_id, 1);
+ cache = cache_lookup_by_node_group(cpu_node, group_id);
of_node_put(cpu_node);
return cache;
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index 447b78a87c8f..a7fcac44a8e2 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -122,14 +122,14 @@ static struct thread_groups_list tgl[NR_CPUS] __initdata;
* On big-cores system, thread_group_l1_cache_map for each CPU corresponds to
* the set its siblings that share the L1-cache.
*/
-static DEFINE_PER_CPU(cpumask_var_t, thread_group_l1_cache_map);
+DEFINE_PER_CPU(cpumask_var_t, thread_group_l1_cache_map);
/*
* On some big-cores system, thread_group_l2_cache_map for each CPU
* corresponds to the set its siblings within the core that share the
* L2-cache.
*/
-static DEFINE_PER_CPU(cpumask_var_t, thread_group_l2_cache_map);
+DEFINE_PER_CPU(cpumask_var_t, thread_group_l2_cache_map);
/* SMP operations for this machine */
struct smp_ops_t *smp_ops;
--
2.26.3
^ permalink raw reply related
* [PATCHv2 0/3] Subject: [PATCHv2 0/3] Make cache-object aware of L3 siblings by parsing "ibm, thread-groups" property
From: Parth Shah @ 2021-07-28 17:56 UTC (permalink / raw)
To: linuxppc-dev; +Cc: ego, mikey, srikar, parths1229, svaidy
Changes from v1 -> v2:
- Based on Gautham's comments, use a separate thread_group_l3_cache_map
and modify parsing code to build cache_map for L3. This makes the
cache_map building code isolated from the parsing code.
v1 can be found at:
https://lists.ozlabs.org/pipermail/linuxppc-dev/2021-June/230680.html
On POWER10 big-core system, the L3 cache reflected by sysfs contains all
the CPUs in the big-core.
grep . /sys/devices/system/cpu/cpu0/cache/index*/shared_cpu_list
/sys/devices/system/cpu/cpu0/cache/index0/shared_cpu_list:0,2,4,6
/sys/devices/system/cpu/cpu0/cache/index1/shared_cpu_list:0,2,4,6
/sys/devices/system/cpu/cpu0/cache/index2/shared_cpu_list:0,2,4,6
/sys/devices/system/cpu/cpu0/cache/index3/shared_cpu_list:0-7
In the above example, CPU-0 observes CPU 0-7 in L3 (index3) cache, which
is not correct as only the CPUs in small core share the L3 cache.
The "ibm,thread-groups" contains property "2" to indicate that the CPUs
share both the L2 and L3 caches. This patch-set uses this property to
reflect correct L3 topology to a cache-object.
After applying this patch-set, the topology looks like:
$> ppc64_cpu --smt=8
$> grep . /sys/devices/system/cpu/cpu[89]/cache/*/shared_cpu_list
/sys/devices/system/cpu/cpu8/cache/index0/shared_cpu_list:8,10,12,14
/sys/devices/system/cpu/cpu8/cache/index1/shared_cpu_list:8,10,12,14
/sys/devices/system/cpu/cpu8/cache/index2/shared_cpu_list:8,10,12,14
/sys/devices/system/cpu/cpu8/cache/index3/shared_cpu_list:8,10,12,14
/sys/devices/system/cpu/cpu9/cache/index0/shared_cpu_list:9,11,13,15
/sys/devices/system/cpu/cpu9/cache/index1/shared_cpu_list:9,11,13,15
/sys/devices/system/cpu/cpu9/cache/index2/shared_cpu_list:9,11,13,15
/sys/devices/system/cpu/cpu9/cache/index3/shared_cpu_list:9,11,13,15
$> ppc64_cpu --smt=4
$> grep . /sys/devices/system/cpu/cpu[89]/cache/*/shared_cpu_list
/sys/devices/system/cpu/cpu8/cache/index0/shared_cpu_list:8,10
/sys/devices/system/cpu/cpu8/cache/index1/shared_cpu_list:8,10
/sys/devices/system/cpu/cpu8/cache/index2/shared_cpu_list:8,10
/sys/devices/system/cpu/cpu8/cache/index3/shared_cpu_list:8,10
/sys/devices/system/cpu/cpu9/cache/index0/shared_cpu_list:9,11
/sys/devices/system/cpu/cpu9/cache/index1/shared_cpu_list:9,11
/sys/devices/system/cpu/cpu9/cache/index2/shared_cpu_list:9,11
/sys/devices/system/cpu/cpu9/cache/index3/shared_cpu_list:9,11
$> ppc64_cpu --smt=2
$> grep . /sys/devices/system/cpu/cpu[89]/cache/*/shared_cpu_list
/sys/devices/system/cpu/cpu8/cache/index0/shared_cpu_list:8
/sys/devices/system/cpu/cpu8/cache/index1/shared_cpu_list:8
/sys/devices/system/cpu/cpu8/cache/index2/shared_cpu_list:8
/sys/devices/system/cpu/cpu8/cache/index3/shared_cpu_list:8
/sys/devices/system/cpu/cpu9/cache/index0/shared_cpu_list:9
/sys/devices/system/cpu/cpu9/cache/index1/shared_cpu_list:9
/sys/devices/system/cpu/cpu9/cache/index2/shared_cpu_list:9
/sys/devices/system/cpu/cpu9/cache/index3/shared_cpu_list:9
$> ppc64_cpu --smt=1
grep . /sys/devices/system/cpu/cpu[89]/cache/*/shared_cpu_list
/sys/devices/system/cpu/cpu8/cache/index0/shared_cpu_list:8
/sys/devices/system/cpu/cpu8/cache/index1/shared_cpu_list:8
/sys/devices/system/cpu/cpu8/cache/index2/shared_cpu_list:8
/sys/devices/system/cpu/cpu8/cache/index3/shared_cpu_list:8
Patches Organization:
=====================
This patch-set series is based on top of v5.14-rc2
- Patch 1-2: Add functionality to introduce awareness for
"ibm,thread-groups". Original (not merged) posted version can be found at:
https://lore.kernel.org/linuxppc-dev/1611041780-8640-1-git-send-email-ego@linux.vnet.ibm.co
- Patch 3: Use existing L2 cache_map to detect L3 cache siblings
Gautham R. Shenoy (2):
powerpc/cacheinfo: Lookup cache by dt node and thread-group id
powerpc/cacheinfo: Remove the redundant get_shared_cpu_map()
Parth Shah (1):
powerpc/smp: Use existing L2 cache_map cpumask to find L3 cache
siblings
arch/powerpc/include/asm/smp.h | 6 ++
arch/powerpc/kernel/cacheinfo.c | 124 ++++++++++++++++----------------
arch/powerpc/kernel/smp.c | 70 ++++++++++++------
3 files changed, 115 insertions(+), 85 deletions(-)
--
2.26.3
^ permalink raw reply
* Re: [powerpc][next-20210727] Boot failure - kernel BUG at arch/powerpc/kernel/interrupt.c:98!
From: Nathan Chancellor @ 2021-07-28 17:35 UTC (permalink / raw)
To: Sachin Sant, Will Deacon, Konrad Rzeszutek Wilk
Cc: Robin Murphy, iommu, linux-next, Claire Chang, linuxppc-dev,
Christoph Hellwig
In-Reply-To: <1905CD70-7656-42AE-99E2-A31FC3812EAC@linux.vnet.ibm.com>
On Wed, Jul 28, 2021 at 01:31:06PM +0530, Sachin Sant wrote:
> linux-next fails to boot on Power server (POWER8/POWER9). Following traces
> are seen during boot
>
> [ 0.010799] software IO TLB: tearing down default memory pool
> [ 0.010805] ------------[ cut here ]------------
> [ 0.010808] kernel BUG at arch/powerpc/kernel/interrupt.c:98!
> [ 0.010812] Oops: Exception in kernel mode, sig: 5 [#1]
> [ 0.010816] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
> [ 0.010820] Modules linked in:
> [ 0.010824] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.14.0-rc3-next-20210727 #1
> [ 0.010830] NIP: c000000000032cfc LR: c00000000000c764 CTR: c00000000000c670
> [ 0.010834] REGS: c000000003603b10 TRAP: 0700 Not tainted (5.14.0-rc3-next-20210727)
> [ 0.010838] MSR: 8000000000029033 <SF,EE,ME,IR,DR,RI,LE> CR: 28000222 XER: 00000002
> [ 0.010848] CFAR: c00000000000c760 IRQMASK: 3
> [ 0.010848] GPR00: c00000000000c764 c000000003603db0 c0000000029bd000 0000000000000001
> [ 0.010848] GPR04: 0000000000000a68 0000000000000400 c000000003603868 ffffffffffffffff
> [ 0.010848] GPR08: 0000000000000000 0000000000000000 0000000000000000 0000000000000003
> [ 0.010848] GPR12: ffffffffffffffff c00000001ec9ee80 c000000000012a28 0000000000000000
> [ 0.010848] GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> [ 0.010848] GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> [ 0.010848] GPR24: 000000000000f134 0000000000000000 ffffffffffffffff c000000003603868
> [ 0.010848] GPR28: 0000000000000400 0000000000000a68 c00000000202e9c0 c000000003603e80
> [ 0.010896] NIP [c000000000032cfc] system_call_exception+0x8c/0x2e0
> [ 0.010901] LR [c00000000000c764] system_call_common+0xf4/0x258
> [ 0.010907] Call Trace:
> [ 0.010909] [c000000003603db0] [c00000000016a6dc] calculate_sigpending+0x4c/0xe0 (unreliable)
> [ 0.010915] [c000000003603e10] [c00000000000c764] system_call_common+0xf4/0x258
> [ 0.010921] --- interrupt: c00 at kvm_template_end+0x4/0x8
> [ 0.010926] NIP: c000000000092dec LR: c000000000114fc8 CTR: 0000000000000000
> [ 0.010930] REGS: c000000003603e80 TRAP: 0c00 Not tainted (5.14.0-rc3-next-20210727)
> [ 0.010934] MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 28000222 XER: 00000000
> [ 0.010943] IRQMASK: 0
> [ 0.010943] GPR00: c00000000202e9c0 c000000003603b00 c0000000029bd000 000000000000f134
> [ 0.010943] GPR04: 0000000000000a68 0000000000000400 c000000003603868 ffffffffffffffff
> [ 0.010943] GPR08: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> [ 0.010943] GPR12: 0000000000000000 c00000001ec9ee80 c000000000012a28 0000000000000000
> [ 0.010943] GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> [ 0.010943] GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> [ 0.010943] GPR24: c0000000020033c4 c00000000110afc0 c000000002081950 c000000003277d40
> [ 0.010943] GPR28: 0000000000000000 c00000000a680000 0000000004000000 00000000000d0000
> [ 0.010989] NIP [c000000000092dec] kvm_template_end+0x4/0x8
> [ 0.010993] LR [c000000000114fc8] set_memory_encrypted+0x38/0x60
> [ 0.010999] --- interrupt: c00
> [ 0.011001] [c000000003603b00] [c00000000000c764] system_call_common+0xf4/0x258 (unreliable)
> [ 0.011008] Instruction dump:
> [ 0.011011] 694a0003 312affff 7d495110 0b0a0000 60000000 60000000 e87f0108 68690002
> [ 0.011019] 7929ffe2 0b090000 68634000 786397e2 <0b030000> e93f0138 792907e0 0b090000
> [ 0.011029] ---[ end trace a20ad55589efcb10 ]---
> [ 0.012297]
> [ 1.012304] Kernel panic - not syncing: Fatal exception
>
> next-20210723 was good. The boot failure seems to have been introduced with next-20210726.
>
> I have attached the boot log.
I noticed this with OpenSUSE's ppc64le config [1] and my bisect landed on
commit ad6c00283163 ("swiotlb: Free tbl memory in swiotlb_exit()"). That
series just keeps on giving... Adding some people from that thread to
this one. Original thread:
https://lore.kernel.org/r/1905CD70-7656-42AE-99E2-A31FC3812EAC@linux.vnet.ibm.com/
[1]: https://github.com/openSUSE/kernel-source/raw/master/config/ppc64le/default
Cheers,
Nathan
^ permalink raw reply
* Re: [PATCH v5 1/6] kexec: move locking into do_kexec_load
From: Eric W. Biederman @ 2021-07-28 16:09 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Feng Tang, linux-mips, James E.J. Bottomley, linux-mm,
Paul Mackerras, H. Peter Anvin, sparclinux, Will Deacon,
linux-arch, linux-s390, Arnd Bergmann, Helge Deller, x86,
Christoph Hellwig, Christian Borntraeger, Ingo Molnar,
Catalin Marinas, Vasily Gorbik, Heiko Carstens, Borislav Petkov,
Al Viro, Thomas Gleixner, linux-arm-kernel, Thomas Bogendoerfer,
linux-parisc, linux-api, linux-kernel, Andrew Morton,
linuxppc-dev, David S. Miller
In-Reply-To: <20210727144859.4150043-2-arnd@kernel.org>
Arnd Bergmann <arnd@kernel.org> writes:
> From: Arnd Bergmann <arnd@arndb.de>
>
> The locking is the same between the native and compat version of
> sys_kexec_load(), so it can be done in the common implementation
> to reduce duplication.
Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>
>
> Co-developed-by: Eric Biederman <ebiederm@xmission.com>
> Co-developed-by: Christoph Hellwig <hch@infradead.org>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> kernel/kexec.c | 44 ++++++++++++++++----------------------------
> 1 file changed, 16 insertions(+), 28 deletions(-)
>
> diff --git a/kernel/kexec.c b/kernel/kexec.c
> index c82c6c06f051..9c7aef8f4bb6 100644
> --- a/kernel/kexec.c
> +++ b/kernel/kexec.c
> @@ -110,6 +110,17 @@ static int do_kexec_load(unsigned long entry, unsigned long nr_segments,
> unsigned long i;
> int ret;
>
> + /*
> + * Because we write directly to the reserved memory region when loading
> + * crash kernels we need a mutex here to prevent multiple crash kernels
> + * from attempting to load simultaneously, and to prevent a crash kernel
> + * from loading over the top of a in use crash kernel.
> + *
> + * KISS: always take the mutex.
> + */
> + if (!mutex_trylock(&kexec_mutex))
> + return -EBUSY;
> +
> if (flags & KEXEC_ON_CRASH) {
> dest_image = &kexec_crash_image;
> if (kexec_crash_image)
> @@ -121,7 +132,8 @@ static int do_kexec_load(unsigned long entry, unsigned long nr_segments,
> if (nr_segments == 0) {
> /* Uninstall image */
> kimage_free(xchg(dest_image, NULL));
> - return 0;
> + ret = 0;
> + goto out_unlock;
> }
> if (flags & KEXEC_ON_CRASH) {
> /*
> @@ -134,7 +146,7 @@ static int do_kexec_load(unsigned long entry, unsigned long nr_segments,
>
> ret = kimage_alloc_init(&image, entry, nr_segments, segments, flags);
> if (ret)
> - return ret;
> + goto out_unlock;
>
> if (flags & KEXEC_PRESERVE_CONTEXT)
> image->preserve_context = 1;
> @@ -171,6 +183,8 @@ static int do_kexec_load(unsigned long entry, unsigned long nr_segments,
> arch_kexec_protect_crashkres();
>
> kimage_free(image);
> +out_unlock:
> + mutex_unlock(&kexec_mutex);
> return ret;
> }
>
> @@ -247,21 +261,8 @@ SYSCALL_DEFINE4(kexec_load, unsigned long, entry, unsigned long, nr_segments,
> ((flags & KEXEC_ARCH_MASK) != KEXEC_ARCH_DEFAULT))
> return -EINVAL;
>
> - /* Because we write directly to the reserved memory
> - * region when loading crash kernels we need a mutex here to
> - * prevent multiple crash kernels from attempting to load
> - * simultaneously, and to prevent a crash kernel from loading
> - * over the top of a in use crash kernel.
> - *
> - * KISS: always take the mutex.
> - */
> - if (!mutex_trylock(&kexec_mutex))
> - return -EBUSY;
> -
> result = do_kexec_load(entry, nr_segments, segments, flags);
>
> - mutex_unlock(&kexec_mutex);
> -
> return result;
> }
>
> @@ -301,21 +302,8 @@ COMPAT_SYSCALL_DEFINE4(kexec_load, compat_ulong_t, entry,
> return -EFAULT;
> }
>
> - /* Because we write directly to the reserved memory
> - * region when loading crash kernels we need a mutex here to
> - * prevent multiple crash kernels from attempting to load
> - * simultaneously, and to prevent a crash kernel from loading
> - * over the top of a in use crash kernel.
> - *
> - * KISS: always take the mutex.
> - */
> - if (!mutex_trylock(&kexec_mutex))
> - return -EBUSY;
> -
> result = do_kexec_load(entry, nr_segments, ksegments, flags);
>
> - mutex_unlock(&kexec_mutex);
> -
> return result;
> }
> #endif
^ permalink raw reply
* Re: [PATCH 01/11] mm: Introduce a function to check for virtualization protection features
From: Borislav Petkov @ 2021-07-28 16:28 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Tom Lendacky, linux-efi, Tianyu Lan, kvm, linux-s390, x86, kexec,
linux-kernel, amd-gfx, platform-driver-x86, iommu, Andi Kleen,
linux-graphics-maintainer, dri-devel, linux-fsdevel,
Brijesh Singh, linuxppc-dev
In-Reply-To: <YQFY5/cq2thyHzUe@infradead.org>
On Wed, Jul 28, 2021 at 02:17:27PM +0100, Christoph Hellwig wrote:
> So common checks obviously make sense, but I really hate the stupid
> multiplexer. Having one well-documented helper per feature is much
> easier to follow.
We had that in x86 - it was called cpu_has_<xxx> where xxx is the
feature bit. It didn't scale with the sheer amount of feature bits that
kept getting added so we do cpu_feature_enabled(X86_FEATURE_XXX) now.
The idea behind this is very similar - those protected guest flags
will only grow in the couple of tens range - at least - so having a
multiplexer is a lot simpler, I'd say, than having a couple of tens of
helpers. And those PATTR flags should have good, readable names, btw.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
^ permalink raw reply
* Re: [PATCH v5 2/6] kexec: avoid compat_alloc_user_space
From: Eric W. Biederman @ 2021-07-28 16:10 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Feng Tang, linux-mips, James E.J. Bottomley, linux-mm,
Paul Mackerras, H. Peter Anvin, sparclinux, Will Deacon,
linux-arch, linux-s390, Arnd Bergmann, Helge Deller, x86,
Christoph Hellwig, Christian Borntraeger, Ingo Molnar,
Catalin Marinas, Vasily Gorbik, Heiko Carstens, Borislav Petkov,
Al Viro, Thomas Gleixner, linux-arm-kernel, Thomas Bogendoerfer,
linux-parisc, linux-api, linux-kernel, Andrew Morton,
linuxppc-dev, David S. Miller
In-Reply-To: <20210727144859.4150043-3-arnd@kernel.org>
Arnd Bergmann <arnd@kernel.org> writes:
> From: Arnd Bergmann <arnd@arndb.de>
>
> kimage_alloc_init() expects a __user pointer, so compat_sys_kexec_load()
> uses compat_alloc_user_space() to convert the layout and put it back
> onto the user space caller stack.
>
> Moving the user space access into the syscall handler directly actually
> makes the code simpler, as the conversion for compat mode can now be
> done on kernel memory.
Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>
>
> Co-developed-by: Eric Biederman <ebiederm@xmission.com>
> Co-developed-by: Christoph Hellwig <hch@infradead.org>
> Link: https://lore.kernel.org/lkml/YPbtsU4GX6PL7%2F42@infradead.org/
> Link: https://lore.kernel.org/lkml/m1y2cbzmnw.fsf@fess.ebiederm.org/
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> kernel/kexec.c | 61 +++++++++++++++++++++-----------------------------
> 1 file changed, 25 insertions(+), 36 deletions(-)
>
> diff --git a/kernel/kexec.c b/kernel/kexec.c
> index 9c7aef8f4bb6..b5e40f069768 100644
> --- a/kernel/kexec.c
> +++ b/kernel/kexec.c
> @@ -19,26 +19,9 @@
>
> #include "kexec_internal.h"
>
> -static int copy_user_segment_list(struct kimage *image,
> - unsigned long nr_segments,
> - struct kexec_segment __user *segments)
> -{
> - int ret;
> - size_t segment_bytes;
> -
> - /* Read in the segments */
> - image->nr_segments = nr_segments;
> - segment_bytes = nr_segments * sizeof(*segments);
> - ret = copy_from_user(image->segment, segments, segment_bytes);
> - if (ret)
> - ret = -EFAULT;
> -
> - return ret;
> -}
> -
> static int kimage_alloc_init(struct kimage **rimage, unsigned long entry,
> unsigned long nr_segments,
> - struct kexec_segment __user *segments,
> + struct kexec_segment *segments,
> unsigned long flags)
> {
> int ret;
> @@ -58,10 +41,8 @@ static int kimage_alloc_init(struct kimage **rimage, unsigned long entry,
> return -ENOMEM;
>
> image->start = entry;
> -
> - ret = copy_user_segment_list(image, nr_segments, segments);
> - if (ret)
> - goto out_free_image;
> + image->nr_segments = nr_segments;
> + memcpy(image->segment, segments, nr_segments * sizeof(*segments));
>
> if (kexec_on_panic) {
> /* Enable special crash kernel control page alloc policy. */
> @@ -104,7 +85,7 @@ static int kimage_alloc_init(struct kimage **rimage, unsigned long entry,
> }
>
> static int do_kexec_load(unsigned long entry, unsigned long nr_segments,
> - struct kexec_segment __user *segments, unsigned long flags)
> + struct kexec_segment *segments, unsigned long flags)
> {
> struct kimage **dest_image, *image;
> unsigned long i;
> @@ -250,7 +231,8 @@ static inline int kexec_load_check(unsigned long nr_segments,
> SYSCALL_DEFINE4(kexec_load, unsigned long, entry, unsigned long, nr_segments,
> struct kexec_segment __user *, segments, unsigned long, flags)
> {
> - int result;
> + struct kexec_segment *ksegments;
> + unsigned long result;
>
> result = kexec_load_check(nr_segments, flags);
> if (result)
> @@ -261,7 +243,12 @@ SYSCALL_DEFINE4(kexec_load, unsigned long, entry, unsigned long, nr_segments,
> ((flags & KEXEC_ARCH_MASK) != KEXEC_ARCH_DEFAULT))
> return -EINVAL;
>
> - result = do_kexec_load(entry, nr_segments, segments, flags);
> + ksegments = memdup_user(segments, nr_segments * sizeof(ksegments[0]));
> + if (IS_ERR(ksegments))
> + return PTR_ERR(ksegments);
> +
> + result = do_kexec_load(entry, nr_segments, ksegments, flags);
> + kfree(ksegments);
>
> return result;
> }
> @@ -273,7 +260,7 @@ COMPAT_SYSCALL_DEFINE4(kexec_load, compat_ulong_t, entry,
> compat_ulong_t, flags)
> {
> struct compat_kexec_segment in;
> - struct kexec_segment out, __user *ksegments;
> + struct kexec_segment *ksegments;
> unsigned long i, result;
>
> result = kexec_load_check(nr_segments, flags);
> @@ -286,24 +273,26 @@ COMPAT_SYSCALL_DEFINE4(kexec_load, compat_ulong_t, entry,
> if ((flags & KEXEC_ARCH_MASK) == KEXEC_ARCH_DEFAULT)
> return -EINVAL;
>
> - ksegments = compat_alloc_user_space(nr_segments * sizeof(out));
> + ksegments = kmalloc_array(nr_segments, sizeof(ksegments[0]),
> + GFP_KERNEL);
> + if (!ksegments)
> + return -ENOMEM;
> +
> for (i = 0; i < nr_segments; i++) {
> result = copy_from_user(&in, &segments[i], sizeof(in));
> if (result)
> - return -EFAULT;
> + goto fail;
>
> - out.buf = compat_ptr(in.buf);
> - out.bufsz = in.bufsz;
> - out.mem = in.mem;
> - out.memsz = in.memsz;
> -
> - result = copy_to_user(&ksegments[i], &out, sizeof(out));
> - if (result)
> - return -EFAULT;
> + ksegments[i].buf = compat_ptr(in.buf);
> + ksegments[i].bufsz = in.bufsz;
> + ksegments[i].mem = in.mem;
> + ksegments[i].memsz = in.memsz;
> }
>
> result = do_kexec_load(entry, nr_segments, ksegments, flags);
>
> +fail:
> + kfree(ksegments);
> return result;
> }
> #endif
^ permalink raw reply
* Re: [PATCH v2 6/7] sections: Add new is_kernel() and is_kernel_text()
From: Steven Rostedt @ 2021-07-28 15:32 UTC (permalink / raw)
To: Kefeng Wang
Cc: linux-arch, ryabinin.a.a, arnd, linux-kernel, ast, mingo, paulus,
linuxppc-dev, davem
In-Reply-To: <20210728081320.20394-7-wangkefeng.wang@huawei.com>
On Wed, 28 Jul 2021 16:13:19 +0800
Kefeng Wang <wangkefeng.wang@huawei.com> wrote:
> @@ -64,8 +64,7 @@ const struct exception_table_entry *search_exception_tables(unsigned long addr)
>
> int notrace core_kernel_text(unsigned long addr)
> {
> - if (addr >= (unsigned long)_stext &&
> - addr < (unsigned long)_etext)
> + if (is_kernel_text(addr))
Perhaps this was a bug, and these functions should be checking the gate
area as well, as that is part of kernel text.
-- Steve
> return 1;
>
> if (system_state < SYSTEM_RUNNING &&
> diff --git a/mm/kasan/report.c b/mm/kasan/report.c
> index 884a950c7026..88f5b0c058b7 100644
> --- a/mm/kasan/report.c
> +++ b/mm/kasan/report.c
> @@ -235,7 +235,7 @@ static void describe_object(struct kmem_cache *cache, void *object,
>
> static inline bool kernel_or_module_addr(const void *addr)
> {
> - if (addr >= (void *)_stext && addr < (void *)_end)
> + if (is_kernel((unsigned long)addr))
> return true;
> if (is_module_address((unsigned long)addr))
> return true;
> --
^ permalink raw reply
* Re: [PATCH v2 5/7] kallsyms: Rename is_kernel() and is_kernel_text()
From: Steven Rostedt @ 2021-07-28 15:28 UTC (permalink / raw)
To: Kefeng Wang
Cc: linux-arch, ryabinin.a.a, Daniel Borkmann, arnd, linux-kernel,
ast, Nathan Chancellor, mingo, paulus, Sami Tolvanen, bpf,
linuxppc-dev, davem
In-Reply-To: <20210728081320.20394-6-wangkefeng.wang@huawei.com>
On Wed, 28 Jul 2021 16:13:18 +0800
Kefeng Wang <wangkefeng.wang@huawei.com> wrote:
> The is_kernel[_text]() function check the address whether or not
> in kernel[_text] ranges, also they will check the address whether
> or not in gate area, so use better name.
Do you know what a gate area is?
Because I believe gate area is kernel text, so the rename just makes it
redundant and more confusing.
-- Steve
^ permalink raw reply
* Re: [PATCH v2 2/7] kallsyms: Fix address-checks for kernel related range
From: Steven Rostedt @ 2021-07-28 14:46 UTC (permalink / raw)
To: Kefeng Wang
Cc: linux-arch, Petr Mladek, ryabinin.a.a, arnd, Sergey Senozhatsky,
linux-kernel, ast, Sergey Senozhatsky, mingo, paulus,
linuxppc-dev, davem
In-Reply-To: <20210728081320.20394-3-wangkefeng.wang@huawei.com>
On Wed, 28 Jul 2021 16:13:15 +0800
Kefeng Wang <wangkefeng.wang@huawei.com> wrote:
> The is_kernel_inittext/is_kernel_text/is_kernel function should not
> include the end address(the labels _einittext, _etext and _end) when
> check the address range, the issue exists since Linux v2.6.12.
>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
> Cc: Petr Mladek <pmladek@suse.com>
> Acked-by: Sergey Senozhatsky <senozhatsky@chromium.org>
> Reviewed-by: Petr Mladek <pmladek@suse.com>
> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Reviewed-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
-- Steve
> ---
> include/linux/kallsyms.h | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/kallsyms.h b/include/linux/kallsyms.h
> index 2a241e3f063f..b016c62f30a6 100644
> --- a/include/linux/kallsyms.h
> +++ b/include/linux/kallsyms.h
> @@ -27,21 +27,21 @@ struct module;
> static inline int is_kernel_inittext(unsigned long addr)
> {
> if (addr >= (unsigned long)_sinittext
> - && addr <= (unsigned long)_einittext)
> + && addr < (unsigned long)_einittext)
> return 1;
> return 0;
> }
>
> static inline int is_kernel_text(unsigned long addr)
> {
> - if ((addr >= (unsigned long)_stext && addr <= (unsigned long)_etext))
> + if ((addr >= (unsigned long)_stext && addr < (unsigned long)_etext))
> return 1;
> return in_gate_area_no_mm(addr);
> }
>
> static inline int is_kernel(unsigned long addr)
> {
> - if (addr >= (unsigned long)_stext && addr <= (unsigned long)_end)
> + if (addr >= (unsigned long)_stext && addr < (unsigned long)_end)
> return 1;
> return in_gate_area_no_mm(addr);
> }
^ permalink raw reply
* Re: [PATCH 02/11] x86/sev: Add an x86 version of prot_guest_has()
From: Christoph Hellwig @ 2021-07-28 13:22 UTC (permalink / raw)
To: Tom Lendacky
Cc: linux-efi, Brijesh Singh, kvm, Peter Zijlstra, Dave Hansen,
dri-devel, platform-driver-x86, linux-s390, Andi Kleen, x86,
amd-gfx, Ingo Molnar, linux-graphics-maintainer, Tianyu Lan,
Borislav Petkov, Andy Lutomirski, Thomas Gleixner, kexec,
linux-kernel, iommu, linux-fsdevel, linuxppc-dev
In-Reply-To: <b3e929a77303dd47fd2adc2a1011009d3bfcee20.1627424774.git.thomas.lendacky@amd.com>
On Tue, Jul 27, 2021 at 05:26:05PM -0500, Tom Lendacky via iommu wrote:
> Introduce an x86 version of the prot_guest_has() function. This will be
> used in the more generic x86 code to replace vendor specific calls like
> sev_active(), etc.
>
> While the name suggests this is intended mainly for guests, it will
> also be used for host memory encryption checks in place of sme_active().
>
> The amd_prot_guest_has() function does not use EXPORT_SYMBOL_GPL for the
> same reasons previously stated when changing sme_active(), sev_active and
None of that applies here as none of the callers get pulled into
random macros. The only case of that is sme_me_mask through
sme_mask, but that's not something this series replaces as far as I can
tell.
^ permalink raw reply
* Re: [PATCH 01/11] mm: Introduce a function to check for virtualization protection features
From: Christoph Hellwig @ 2021-07-28 13:17 UTC (permalink / raw)
To: Tom Lendacky
Cc: linux-s390, linux-efi, Tianyu Lan, kvm, x86, kexec, linux-kernel,
amd-gfx, platform-driver-x86, iommu, Andi Kleen,
linux-graphics-maintainer, dri-devel, Brijesh Singh,
linux-fsdevel, Borislav Petkov, linuxppc-dev
In-Reply-To: <cbc875b1d2113225c2b44a2384d5b303d0453cf7.1627424774.git.thomas.lendacky@amd.com>
On Tue, Jul 27, 2021 at 05:26:04PM -0500, Tom Lendacky via iommu wrote:
> In prep for other protected virtualization technologies, introduce a
> generic helper function, prot_guest_has(), that can be used to check
> for specific protection attributes, like memory encryption. This is
> intended to eliminate having to add multiple technology-specific checks
> to the code (e.g. if (sev_active() || tdx_active())).
So common checks obviously make sense, but I really hate the stupid
multiplexer. Having one well-documented helper per feature is much
easier to follow.
> +#define PATTR_MEM_ENCRYPT 0 /* Encrypted memory */
> +#define PATTR_HOST_MEM_ENCRYPT 1 /* Host encrypted memory */
> +#define PATTR_GUEST_MEM_ENCRYPT 2 /* Guest encrypted memory */
> +#define PATTR_GUEST_PROT_STATE 3 /* Guest encrypted state */
The kerneldoc comments on these individual helpers will give you plenty
of space to properly document what they indicate and what a (potential)
caller should do based on them. Something the above comments completely
fail to.
^ permalink raw reply
* Re: Possible regression by ab037dd87a2f (powerpc/vdso: Switch VDSO to generic C implementation.)
From: Paul Menzel @ 2021-07-28 12:53 UTC (permalink / raw)
To: Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
Christophe Leroy
Cc: Derek Parker, Dmitrii Okunev, murp, linuxppc-dev, laboger
In-Reply-To: <878s1q1udj.fsf@mpe.ellerman.id.au>
Dear Michael,
Am 28.07.21 um 14:43 schrieb Michael Ellerman:
> Paul Menzel <pmenzel@molgen.mpg.de> writes:
>> Am 28.07.21 um 01:14 schrieb Benjamin Herrenschmidt:
>>> On Tue, 2021-07-27 at 10:45 +0200, Paul Menzel wrote:
>>
>>>> On ppc64le Go 1.16.2 from Ubuntu 21.04 terminates with a segmentation
>>>> fault [1], and it might be related to *[release-branch.go1.16] runtime:
>>>> fix crash during VDSO calls on PowerPC* [2], conjecturing that commit
>>>> ab037dd87a2f (powerpc/vdso: Switch VDSO to generic C implementation.)
>>>> added in Linux 5.11 causes this.
>>>>
>>>> If this is indeed the case, this would be a regression in userspace. Is
>>>> there a generic fix or should the change be reverted?
>>>
>>> From the look at the links you posted, this appears to be completely
>>> broken assumptions by Go that some registers don't change while calling
>>> what essentially are external library functions *while inside those
>>> functions* (ie in this case from a signal handler).
>>>
>>> I suppose it would be possible to build the VDSO with gcc arguments to
>>> make it not use r30, but that's just gross...
>>
>> Thank you for looking into this. No idea, if it falls under Linux’ no
>> regression policy or not.
>
> Reluctantly yes, I think it does. Though it would have been good if it
> had been reported to us sooner.
>
> It looks like that Go fix is only committed to master, and neither of
> the latest Go 1.16 or 1.15 releases contain the fix? ie. there's no way
> for a user to get a working version of Go other than building master?
I heard it is going to be in Go 1.16.7, but I do not know much about Go.
Maybe the folks in Cc can chime in.
> I'll see if we can work around it in the kernel. Are you able to test a
> kernel patch if I send you one?
Yes, I could test a Linux kernel patch on ppc64le (POWER 8) running
Ubuntu 21.04.
Kind regards,
Paul
^ 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