* Re: [PATCH v4 4/5] KVM: PPC: mmio: Return to guest after emulation failure
From: Nicholas Piggin @ 2022-01-25 3:26 UTC (permalink / raw)
To: Fabiano Rosas, kvm-ppc; +Cc: aik, linuxppc-dev
In-Reply-To: <20220121222626.972495-5-farosas@linux.ibm.com>
Excerpts from Fabiano Rosas's message of January 22, 2022 8:26 am:
> If MMIO emulation fails we don't want to crash the whole guest by
> returning to userspace.
>
> The original commit bbf45ba57eae ("KVM: ppc: PowerPC 440 KVM
> implementation") added a todo:
>
> /* XXX Deliver Program interrupt to guest. */
>
> and later the commit d69614a295ae ("KVM: PPC: Separate loadstore
> emulation from priv emulation") added the Program interrupt injection
> but in another file, so I'm assuming it was missed that this block
> needed to be altered.
>
> Also change the message to a ratelimited one since we're letting the
> guest run and it could flood the host logs.
>
> Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com>
Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
One small thing...
> ---
> arch/powerpc/kvm/powerpc.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
> index 27fb2b70f631..214602c58f13 100644
> --- a/arch/powerpc/kvm/powerpc.c
> +++ b/arch/powerpc/kvm/powerpc.c
> @@ -307,9 +307,9 @@ int kvmppc_emulate_mmio(struct kvm_vcpu *vcpu)
> u32 last_inst;
>
> kvmppc_get_last_inst(vcpu, INST_GENERIC, &last_inst);
> - /* XXX Deliver Program interrupt to guest. */
> - pr_emerg("%s: emulation failed (%08x)\n", __func__, last_inst);
> - r = RESUME_HOST;
> + pr_info_ratelimited("KVM: guest access to device memory using unsupported instruction (PID: %d opcode: %#08x)\n",
> + current->pid, last_inst);
Minor thing but KVM now has some particular printing helpers so I wonder
if we should start moving to them in general with our messages.
vcpu_debug_ratelimited() maybe?
Thanks,
Nick
^ permalink raw reply
* Re: [PATCH v4 5/5] KVM: PPC: mmio: Deliver DSI after emulation failure
From: Nicholas Piggin @ 2022-01-25 3:39 UTC (permalink / raw)
To: Fabiano Rosas, kvm-ppc; +Cc: aik, linuxppc-dev
In-Reply-To: <20220121222626.972495-6-farosas@linux.ibm.com>
Excerpts from Fabiano Rosas's message of January 22, 2022 8:26 am:
> MMIO emulation can fail if the guest uses an instruction that we are
> not prepared to emulate. Since these instructions can be and most
> likely are valid ones, this is (slightly) closer to an access fault
> than to an illegal instruction, so deliver a Data Storage interrupt
> instead of a Program interrupt.
>
> Suggested-by: Nicholas Piggin <npiggin@gmail.com>
> Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com>
> ---
> arch/powerpc/kvm/emulate_loadstore.c | 10 +++-------
> arch/powerpc/kvm/powerpc.c | 12 ++++++++++++
> 2 files changed, 15 insertions(+), 7 deletions(-)
>
> diff --git a/arch/powerpc/kvm/emulate_loadstore.c b/arch/powerpc/kvm/emulate_loadstore.c
> index 48272a9b9c30..cfc9114b87d0 100644
> --- a/arch/powerpc/kvm/emulate_loadstore.c
> +++ b/arch/powerpc/kvm/emulate_loadstore.c
> @@ -73,7 +73,6 @@ int kvmppc_emulate_loadstore(struct kvm_vcpu *vcpu)
> {
> u32 inst;
> enum emulation_result emulated = EMULATE_FAIL;
> - int advance = 1;
> struct instruction_op op;
>
> /* this default type might be overwritten by subcategories */
> @@ -98,6 +97,8 @@ int kvmppc_emulate_loadstore(struct kvm_vcpu *vcpu)
> int type = op.type & INSTR_TYPE_MASK;
> int size = GETSIZE(op.type);
>
> + vcpu->mmio_is_write = OP_IS_STORE(type);
> +
> switch (type) {
> case LOAD: {
> int instr_byte_swap = op.type & BYTEREV;
> @@ -355,15 +356,10 @@ int kvmppc_emulate_loadstore(struct kvm_vcpu *vcpu)
> }
> }
>
> - if (emulated == EMULATE_FAIL) {
> - advance = 0;
> - kvmppc_core_queue_program(vcpu, 0);
> - }
> -
> trace_kvm_ppc_instr(inst, kvmppc_get_pc(vcpu), emulated);
>
> /* Advance past emulated instruction. */
> - if (advance)
> + if (emulated != EMULATE_FAIL)
> kvmppc_set_pc(vcpu, kvmppc_get_pc(vcpu) + 4);
>
> return emulated;
> diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
> index 214602c58f13..9befb121dddb 100644
> --- a/arch/powerpc/kvm/powerpc.c
> +++ b/arch/powerpc/kvm/powerpc.c
> @@ -305,10 +305,22 @@ int kvmppc_emulate_mmio(struct kvm_vcpu *vcpu)
> case EMULATE_FAIL:
> {
> u32 last_inst;
> + ulong store_bit = DSISR_ISSTORE;
> + ulong cause = DSISR_BADACCESS;
>
> +#ifdef CONFIG_BOOKE
> + store_bit = ESR_ST;
> + cause = 0;
> +#endif
BookE can not cause a bad page fault in the guest with ESR bits AFAIKS,
so it would cause an infinite fault loop here. Maybe stick with the
program interrupt for BookE with a comment about that here.
And if it could use if (IS_ENABLED()) would be good?
Otherwise looks good, it should do the right thing on BookS.
Thanks,
Nick
> kvmppc_get_last_inst(vcpu, INST_GENERIC, &last_inst);
> pr_info_ratelimited("KVM: guest access to device memory using unsupported instruction (PID: %d opcode: %#08x)\n",
> current->pid, last_inst);
> +
> + if (vcpu->mmio_is_write)
> + cause |= store_bit;
> +
> + kvmppc_core_queue_data_storage(vcpu, vcpu->arch.vaddr_accessed,
> + cause);
> r = RESUME_GUEST;
> break;
> }
> --
> 2.34.1
>
>
^ permalink raw reply
* Re: [PATCH v2 4/4] KVM: PPC: Decrement module refcount if init_vm fails
From: Nicholas Piggin @ 2022-01-25 3:46 UTC (permalink / raw)
To: Fabiano Rosas, kvm-ppc; +Cc: aik, linuxppc-dev
In-Reply-To: <20220124220803.1011673-5-farosas@linux.ibm.com>
Excerpts from Fabiano Rosas's message of January 25, 2022 8:08 am:
> We increment the reference count for KVM-HV/PR before the call to
> kvmppc_core_init_vm. If that function fails we need to decrement the
> refcount.
>
> Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com>
> ---
> Caught this while testing Nick's LPID patches by looking at
> /sys/module/kvm_hv/refcnt
Nice catch. Is this the only change in the series?
You can just use kvm_ops->owner like try_module_get() does I think? Also
try_module_get works on a NULL module same as module_put by the looks,
so you could adjust that in this patch to remove the NULL check so it
is consistent with the put.
Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
Thanks,
Nick
> ---
> arch/powerpc/kvm/powerpc.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
> index 2ad0ccd202d5..4285d0eac900 100644
> --- a/arch/powerpc/kvm/powerpc.c
> +++ b/arch/powerpc/kvm/powerpc.c
> @@ -431,6 +431,8 @@ int kvm_arch_check_processor_compat(void *opaque)
> int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
> {
> struct kvmppc_ops *kvm_ops = NULL;
> + int r;
> +
> /*
> * if we have both HV and PR enabled, default is HV
> */
> @@ -456,7 +458,10 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
> return -ENOENT;
>
> kvm->arch.kvm_ops = kvm_ops;
> - return kvmppc_core_init_vm(kvm);
> + r = kvmppc_core_init_vm(kvm);
> + if (r)
> + module_put(kvm->arch.kvm_ops->owner);
> + return r;
> err_out:
> return -EINVAL;
> }
> --
> 2.34.1
>
>
^ permalink raw reply
* Re: [PATCH 1/2] KVM: PPC: Book3S PR: Disable SCV when running AIL is disabled
From: Nicholas Piggin @ 2022-01-25 3:55 UTC (permalink / raw)
To: Fabiano Rosas, linuxppc-dev
In-Reply-To: <877daoeol4.fsf@linux.ibm.com>
Excerpts from Fabiano Rosas's message of January 25, 2022 8:49 am:
> Nicholas Piggin <npiggin@gmail.com> writes:
>
>> PR KVM does not support running with AIL enabled, and SCV does is not
>> supported with AIL disabled.
>>
>> Fix this by ensuring the SCV facility is disabled with FSCR while a
>> CPU can be running with AIL=0. PowerNV host supports disabling AIL on a
>> per-CPU basis, so SCV just needs to be disabled when a vCPU is run.
>>
>> The pSeries machine can only switch AIL on a system-wide basis, so it
>> must disable SCV support at boot if the configuration can potentially
>> run a PR KVM guest.
>>
>> SCV is not emulated for the PR guest at the moment, this just fixes the
>> host crashes.
>>
>> Alternatives considered and rejected:
>> - SCV support can not be disabled by PR KVM after boot, because it is
>> advertised to userspace with HWCAP.
>> - AIL can not be disabled on a per-CPU basis. At least when running on
>> pseries it is a per-LPAR setting.
>> - Support for real-mode SCV vectors will not be added because they are
>> at 0x17000 so making such a large fixed head space causes immediate
>> value limits to be exceeded, requiring a lot rework and more code.
>> - Disabling SCV for any PR KVM possible kernel will cause a slowdown
>> when not using PR KVM.
>> - A boot time option to disable SCV to use PR KVM is user-hostile.
>> - System call instruction emulation for SCV facility unavailable
>> instructions is too complex and old emulation code was subtly broken
>> and removed.
>>
>> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
>> ---
>> arch/powerpc/kernel/exceptions-64s.S | 4 ++++
>> arch/powerpc/kernel/setup_64.c | 15 +++++++++++++++
>> arch/powerpc/kvm/book3s_pr.c | 20 ++++++++++++++------
>> 3 files changed, 33 insertions(+), 6 deletions(-)
>>
>> diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
>> index 55caeee37c08..b66dd6f775a4 100644
>> --- a/arch/powerpc/kernel/exceptions-64s.S
>> +++ b/arch/powerpc/kernel/exceptions-64s.S
>> @@ -809,6 +809,10 @@ __start_interrupts:
>> * - MSR_EE|MSR_RI is clear (no reentrant exceptions)
>> * - Standard kernel environment is set up (stack, paca, etc)
>> *
>> + * KVM:
>> + * These interrupts do not elevate HV 0->1, so HV is not involved. PR KVM
>> + * ensures that FSCR[SCV] is disabled whenever it has to force AIL off.
>> + *
>> * Call convention:
>> *
>> * syscall register convention is in Documentation/powerpc/syscall64-abi.rst
>> diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
>> index be8577ac9397..ac52c69a3811 100644
>> --- a/arch/powerpc/kernel/setup_64.c
>> +++ b/arch/powerpc/kernel/setup_64.c
>> @@ -197,6 +197,21 @@ static void __init configure_exceptions(void)
>>
>> /* Under a PAPR hypervisor, we need hypercalls */
>> if (firmware_has_feature(FW_FEATURE_SET_MODE)) {
>> + /*
>> + * PR KVM does not support AIL mode interrupts in the host, and
>> + * SCV system call interrupt vectors are only implemented for
>> + * AIL mode. Under pseries, AIL mode can only be enabled and
>> + * disabled system-wide so when PR KVM is loaded, all CPUs in
>> + * the host are set to AIL=0 mode. SCV can not be disabled
>> + * dynamically because the feature is advertised to host
>> + * userspace, so SCV support must not be enabled if PR KVM can
>> + * possibly be run.
>> + */
>> + if (IS_ENABLED(CONFIG_KVM_BOOK3S_PR_POSSIBLE) && !radix_enabled()) {
>> + init_task.thread.fscr &= ~FSCR_SCV;
>> + cur_cpu_spec->cpu_user_features2 &= ~PPC_FEATURE2_SCV;
>> + }
>> +
>
> "Under pseries, AIL mode can only be enabled and disabled system-wide so
> when PR KVM is loaded, all CPUs in the host are set to AIL=0 mode."
>
> Loaded as in 'modprobe kvm_pr'?
In kvmppc_core_init_vm_pr(), so while there is a PR guest running in the
system.
> And host as in "nested host"
> surely. Unless I completely misunderstood the patch (likely).
Yes the PR KVM host. I didn't want to say nested because it runs in
supervisor mode so is basically no difference whether under a HV or
not so I'm not sure if that's the right term for PR KVM or could
confused with nested HV.
I will see if I can make it a bit clearer.
> Is there a way to make this less unexpected to users? Maybe a few words
> in the Kconfig entry for PR_POSSIBLE saying "if you enable this and run
> a Hash MMU guest, you lose SCV"?
That's not a bad idea, also if you run a PR guest under it you lose
AIL in the host which also slows down interrupts and system calls.
Thanks,
Nick
>
>> /* Enable AIL if possible */
>> if (!pseries_enable_reloc_on_exc()) {
>> init_task.thread.fscr &= ~FSCR_SCV;
>> diff --git a/arch/powerpc/kvm/book3s_pr.c b/arch/powerpc/kvm/book3s_pr.c
>> index 34a801c3604a..4d1c84b94b77 100644
>> --- a/arch/powerpc/kvm/book3s_pr.c
>> +++ b/arch/powerpc/kvm/book3s_pr.c
>> @@ -140,9 +140,12 @@ static void kvmppc_core_vcpu_load_pr(struct kvm_vcpu *vcpu, int cpu)
>> #endif
>>
>> /* Disable AIL if supported */
>> - if (cpu_has_feature(CPU_FTR_HVMODE) &&
>> - cpu_has_feature(CPU_FTR_ARCH_207S))
>> - mtspr(SPRN_LPCR, mfspr(SPRN_LPCR) & ~LPCR_AIL);
>> + if (cpu_has_feature(CPU_FTR_HVMODE)) {
>> + if (cpu_has_feature(CPU_FTR_ARCH_207S))
>> + mtspr(SPRN_LPCR, mfspr(SPRN_LPCR) & ~LPCR_AIL);
>> + if (cpu_has_feature(CPU_FTR_ARCH_300) && (current->thread.fscr & FSCR_SCV))
>> + mtspr(SPRN_FSCR, mfspr(SPRN_FSCR) & ~FSCR_SCV);
>> + }
>>
>> vcpu->cpu = smp_processor_id();
>> #ifdef CONFIG_PPC_BOOK3S_32
>> @@ -175,9 +178,12 @@ static void kvmppc_core_vcpu_put_pr(struct kvm_vcpu *vcpu)
>> kvmppc_save_tm_pr(vcpu);
>>
>> /* Enable AIL if supported */
>> - if (cpu_has_feature(CPU_FTR_HVMODE) &&
>> - cpu_has_feature(CPU_FTR_ARCH_207S))
>> - mtspr(SPRN_LPCR, mfspr(SPRN_LPCR) | LPCR_AIL_3);
>> + if (cpu_has_feature(CPU_FTR_HVMODE)) {
>> + if (cpu_has_feature(CPU_FTR_ARCH_207S))
>> + mtspr(SPRN_LPCR, mfspr(SPRN_LPCR) | LPCR_AIL_3);
>> + if (cpu_has_feature(CPU_FTR_ARCH_300) && (current->thread.fscr & FSCR_SCV))
>> + mtspr(SPRN_FSCR, mfspr(SPRN_FSCR) | FSCR_SCV);
>> + }
>>
>> vcpu->cpu = -1;
>> }
>> @@ -1037,6 +1043,8 @@ static int kvmppc_handle_fac(struct kvm_vcpu *vcpu, ulong fac)
>>
>> void kvmppc_set_fscr(struct kvm_vcpu *vcpu, u64 fscr)
>> {
>> + if (fscr & FSCR_SCV)
>> + fscr &= ~FSCR_SCV; /* SCV must not be enabled */
>> if ((vcpu->arch.fscr & FSCR_TAR) && !(fscr & FSCR_TAR)) {
>> /* TAR got dropped, drop it in shadow too */
>> kvmppc_giveup_fac(vcpu, FSCR_TAR_LG);
>
^ permalink raw reply
* Re: [powerpc] ftrace warning kernel/trace/ftrace.c:2068 with code-patching selftests
From: Sachin Sant @ 2022-01-25 4:00 UTC (permalink / raw)
To: Steven Rostedt; +Cc: Yinan Liu, linuxppc-dev
In-Reply-To: <20220124114548.30241947@gandalf.local.home>
> On 24-Jan-2022, at 10:15 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
>
> On Mon, 24 Jan 2022 20:15:06 +0800
> Yinan Liu <yinan@linux.alibaba.com> wrote:
>
>> Hi, Steven and Sachin
>>
>> I don't have a powerpc machine for testing, I guess the ppc has a
>> similar problem with the s390. It's not clear to me why the compiler
>> does this. Maybe we can handle ppc like you did with the s390 before,
>> but I'm not sure if other architectures have similar issues. Or limit
>> BUILDTIME_MCOUNT_SORT to a smaller scope and make it only available for
>> x86 and arm?
>>
>> steven, what's your opinion?
>
> Yeah, I think it's time to opt in, instead of opting out.
>
> Something like this:
>
Thanks. This fixes the reported problem.
Tested-by: Sachin Sant <sachinp@linux.ibm.com>
- Sachin
^ permalink raw reply
* Re: [PATCH 6/7] modules: Add CONFIG_ARCH_WANTS_MODULES_DATA_IN_VMALLOC
From: Christophe Leroy @ 2022-01-25 5:43 UTC (permalink / raw)
To: Doug Anderson
Cc: linux-arch@vger.kernel.org, Daniel Thompson,
kgdb-bugreport@lists.sourceforge.net, Jason Wessel,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Luis Chamberlain, Jessica Yu, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <CAD=FV=VMUA+8RFOSkVQTmBDrHPSYSG5VBVA_EKKQuBjF0ZZKpQ@mail.gmail.com>
Le 24/01/2022 à 22:43, Doug Anderson a écrit :
> Hi,
>
> On Mon, Jan 24, 2022 at 1:22 AM Christophe Leroy
> <christophe.leroy@csgroup.eu> wrote:
>>
>> --- a/kernel/debug/kdb/kdb_main.c
>> +++ b/kernel/debug/kdb/kdb_main.c
>> @@ -2022,8 +2022,11 @@ static int kdb_lsmod(int argc, const char **argv)
>> if (mod->state == MODULE_STATE_UNFORMED)
>> continue;
>>
>> - kdb_printf("%-20s%8u 0x%px ", mod->name,
>> - mod->core_layout.size, (void *)mod);
>> + kdb_printf("%-20s%8u", mod->name, mod->core_layout.size);
>> +#ifdef CONFIG_ARCH_WANTS_MODULES_DATA_IN_VMALLOC
>> + kdb_printf("/%8u 0x%px ", mod->data_layout.size);
>
> Just counting percentages and arguments, it seems like something's
> wrong in the above print statement.
>
Yes it seems, the build robot reported something here as well.
Thanks
Christophe
^ permalink raw reply
* Re: [PATCH 0/2] powerpc: Disable syscall emulation and stepping
From: Christophe Leroy @ 2022-01-25 5:53 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev@lists.ozlabs.org; +Cc: Naveen N. Rao
In-Reply-To: <1643079479.32j7nee5j0.astroid@bobo.none>
Le 25/01/2022 à 04:04, Nicholas Piggin a écrit :
> +Naveen (sorry missed cc'ing you at first)
>
> Excerpts from Christophe Leroy's message of January 24, 2022 4:39 pm:
>>
>>
>> Le 24/01/2022 à 06:57, Nicholas Piggin a écrit :
>>> As discussed previously
>>>
>>> https://lists.ozlabs.org/pipermail/linuxppc-dev/2022-January/238946.html
>>>
>>> I'm wondering whether PPC32 should be returning -1 for syscall
>>> instructions too here? That could be done in another patch anyway.
>>>
>>
>> The 'Programming Environments Manual for 32-Bit Implementations of the
>> PowerPC™ Architecture' says:
>>
>> The following are not traced:
>> • rfi instruction
>> • sc and trap instructions that trap
>> • Other instructions that cause interrupts (other than trace interrupts)
>> • The first instruction of any interrupt handler
>> • Instructions that are emulated by software
>>
>>
>> So I think PPC32 should return -1 as well.
>
> I agree.
>
> What about the trap instructions? analyse_instr returns 0 for them
> which falls through to return 0 for emulate_step, should they
> return -1 as well or am I missing something?
>
For the traps I don't know. The manual says "trap instructions that
trap" are not traced. It means that "trap instructions that _don't_
trap" are traced. Taking into account that trap instructions don't trap
at least 99.9% of the time, not sure if returning -1 is needed.
Allthought that'd probably be the safest.
But then what happens with other instruction that will sparsely generate
an exception like a DSI or so ? If we do it for the traps then we should
do it for this as well, and then it becomes a non ending story.
So at the end it's probably ok with return 0, both for them and for traps.
Christophe
^ permalink raw reply
* Re: [PATCH v4 2/7] mm: page_isolation: move has_unmovable_pages() to mm/page_isolation.c
From: Oscar Salvador @ 2022-01-25 6:23 UTC (permalink / raw)
To: Zi Yan
Cc: Mel Gorman, David Hildenbrand, linuxppc-dev, linux-kernel,
virtualization, linux-mm, iommu, Eric Ren, Robin Murphy,
Christoph Hellwig, Vlastimil Babka, Marek Szyprowski
In-Reply-To: <20220119190623.1029355-3-zi.yan@sent.com>
On 2022-01-19 20:06, Zi Yan wrote:
> From: Zi Yan <ziy@nvidia.com>
>
> has_unmovable_pages() is only used in mm/page_isolation.c. Move it from
> mm/page_alloc.c and make it static.
>
> Signed-off-by: Zi Yan <ziy@nvidia.com>
Reviewed-by: Oscar Salvador <osalvador@suse.de>
--
Oscar Salvador
SUSE Labs
^ permalink raw reply
* [PATCH] powerpc/smp: poll cpu_callin_map more aggressively in __cpu_up()
From: Nathan Lynch @ 2022-01-25 7:21 UTC (permalink / raw)
To: linuxppc-dev; +Cc: brking, linux-kernel, npiggin, srikar
Replace the outdated iteration and timeout calculations here with
indefinite spin_until_cond()-wrapped poll of cpu_callin_map. __cpu_up()
already does this when waiting for the cpu to set its online bit before
returning, so this change is not really making the function more brittle.
Removing the msleep(1) in the hotplug path here reduces the time it takes
to online a CPU on a P9 PowerVM LPAR from about 30ms to 1ms when exercised
via thaw_secondary_cpus().
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
---
arch/powerpc/kernel/smp.c | 25 ++-----------------------
1 file changed, 2 insertions(+), 23 deletions(-)
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index b7fd6a72aa76..990893365fe0 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -1270,7 +1270,7 @@ static void cpu_idle_thread_init(unsigned int cpu, struct task_struct *idle)
int __cpu_up(unsigned int cpu, struct task_struct *tidle)
{
- int rc, c;
+ int rc;
/*
* Don't allow secondary threads to come online if inhibited
@@ -1314,28 +1314,7 @@ int __cpu_up(unsigned int cpu, struct task_struct *tidle)
return rc;
}
- /*
- * wait to see if the cpu made a callin (is actually up).
- * use this value that I found through experimentation.
- * -- Cort
- */
- if (system_state < SYSTEM_RUNNING)
- for (c = 50000; c && !cpu_callin_map[cpu]; c--)
- udelay(100);
-#ifdef CONFIG_HOTPLUG_CPU
- else
- /*
- * CPUs can take much longer to come up in the
- * hotplug case. Wait five seconds.
- */
- for (c = 5000; c && !cpu_callin_map[cpu]; c--)
- msleep(1);
-#endif
-
- if (!cpu_callin_map[cpu]) {
- printk(KERN_ERR "Processor %u is stuck.\n", cpu);
- return -ENOENT;
- }
+ spin_until_cond(cpu_callin_map[cpu] != 0);
DBG("Processor %u found.\n", cpu);
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v2 0/5] fsl-asoc-card: Add optional dt property for setting mclk-id
From: Mark Brown @ 2022-01-25 10:20 UTC (permalink / raw)
To: Ariel D'Alessandro, alsa-devel, devicetree, linux-omap,
linux-kernel, linuxppc-dev
Cc: kuninori.morimoto.gx, Xiubo.Lee, tony, festevam, tiwai, lgirdwood,
nicoleotsuka, robh+dt, bcousson, perex, michael, shengjiu.wang
In-Reply-To: <20220117132109.283365-1-ariel.dalessandro@collabora.com>
On Mon, 17 Jan 2022 10:21:04 -0300, Ariel D'Alessandro wrote:
> This is a follow up of patchset:
>
> [RFC patch 0/5] Support BCLK input clock in tlv320aic31xx
>
> Sound cards may allow using different main clock inputs. In the generic
> fsl-asoc-card driver, these values are hardcoded for each specific card
> configuration.
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/5] dt-bindings: sound: Rename tlv320aic31xx-micbias as tlv320aic31xx
commit: 85f856f790b5fd427cb31b3f62755713174da0aa
[2/5] dt-bindings: tlv320aic31xx: Define PLL clock inputs
commit: 6045ffd366283236f0de79c8a0e98ae766e9a8f9
[3/5] ASoC: bindings: fsl-asoc-card: Add mclk-id optional property
commit: 55915f20ad9ae92015bf7b2c4ac854e5b720d63f
[4/5] ASoC: fsl-asoc-card: Add optional dt property for setting mclk-id
commit: e6ec5a3936ee0c01f46e1d09dc758bb762e06dd9
[5/5] ASoC: fsl-asoc-card: Remove BCLK default value for tlv320aic31xx card
commit: d4c4e2861560ab1cbf540bbda5bcdf4c92b17110
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/uprobes: Reject uprobe on a system call instruction
From: Michael Ellerman @ 2022-01-25 11:45 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev; +Cc: Naveen N . Rao, Nicholas Piggin
In-Reply-To: <20220124055741.3686496-3-npiggin@gmail.com>
Nicholas Piggin <npiggin@gmail.com> writes:
> Per the ISA, a Trace interrupt is not generated for a system call
> [vectored] instruction. Reject uprobes on such instructions as we are
> not emulating a system call [vectored] instruction anymore.
This should really be patch 1, otherwise there's a single commit window
where we allow uprobes on sc but don't honour them.
> Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
> [np: Switch to pr_info_ratelimited]
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
> ---
> arch/powerpc/include/asm/ppc-opcode.h | 1 +
> arch/powerpc/kernel/uprobes.c | 6 ++++++
> 2 files changed, 7 insertions(+)
>
> diff --git a/arch/powerpc/include/asm/ppc-opcode.h b/arch/powerpc/include/asm/ppc-opcode.h
> index 9675303b724e..8bbe16ce5173 100644
> --- a/arch/powerpc/include/asm/ppc-opcode.h
> +++ b/arch/powerpc/include/asm/ppc-opcode.h
> @@ -411,6 +411,7 @@
> #define PPC_RAW_DCBFPS(a, b) (0x7c0000ac | ___PPC_RA(a) | ___PPC_RB(b) | (4 << 21))
> #define PPC_RAW_DCBSTPS(a, b) (0x7c0000ac | ___PPC_RA(a) | ___PPC_RB(b) | (6 << 21))
> #define PPC_RAW_SC() (0x44000002)
> +#define PPC_RAW_SCV() (0x44000001)
> #define PPC_RAW_SYNC() (0x7c0004ac)
> #define PPC_RAW_ISYNC() (0x4c00012c)
>
> diff --git a/arch/powerpc/kernel/uprobes.c b/arch/powerpc/kernel/uprobes.c
> index c6975467d9ff..3779fde804bd 100644
> --- a/arch/powerpc/kernel/uprobes.c
> +++ b/arch/powerpc/kernel/uprobes.c
> @@ -41,6 +41,12 @@ int arch_uprobe_analyze_insn(struct arch_uprobe *auprobe,
> if (addr & 0x03)
> return -EINVAL;
>
> + if (ppc_inst_val(ppc_inst_read(auprobe->insn)) == PPC_RAW_SC() ||
> + ppc_inst_val(ppc_inst_read(auprobe->insn)) == PPC_RAW_SCV()) {
We should probably reject hypercall too?
There's also a lot of reserved fields in `sc`, so doing an exact match
like this risks missing instructions that are badly formed but the CPU
will happily execute as `sc`.
We'd obviously never expect to see those in compiler generated code, but
it'd still be safer to mask. We could probably just reject opcode 17
entirely.
And I guess for a subsequent patch, but we should be rejecting some
others here as well shouldn't we? Like rfid etc.
cheers
> + pr_info_ratelimited("Rejecting uprobe on system call instruction\n");
> + return -EINVAL;
> + }
> +
> if (cpu_has_feature(CPU_FTR_ARCH_31) &&
> ppc_inst_prefixed(ppc_inst_read(auprobe->insn)) &&
> (addr & 0x3f) == 60) {
> --
> 2.23.0
^ permalink raw reply
* Re: [PATCH v4 3/7] mm: page_isolation: check specified range for unmovable pages
From: Oscar Salvador @ 2022-01-25 13:19 UTC (permalink / raw)
To: Zi Yan
Cc: Mel Gorman, David Hildenbrand, linuxppc-dev, linux-kernel,
virtualization, linux-mm, iommu, Eric Ren, Robin Murphy,
Christoph Hellwig, Vlastimil Babka, Marek Szyprowski
In-Reply-To: <6AEF32AC-4E0D-41E0-8850-33B8BD955920@nvidia.com>
On Mon, Jan 24, 2022 at 12:17:23PM -0500, Zi Yan wrote:
> You are right. Sorry for the confusion. I think it should be
> “Page isolation is done at least on max(MAX_ORDER_NR_PAEGS,
> pageblock_nr_pages) granularity.”
>
> memory_hotplug uses PAGES_PER_SECTION. It is greater than that.
Or just specify that the max(MAX_ORDER_NR_PAGES, pageblock_nr_pages) granurality
only comes from alloc_contig_range at the moment. Other callers might want
to work in other granularity (e.g: memory-hotplug) although ultimately the
range has to be aligned to something.
> > True is that start_isolate_page_range() expects the range to be pageblock aligned and works in pageblock_nr_pages chunks, but I do not think that is what you meant to say here.
>
> Actually, start_isolate_page_range() should expect max(MAX_ORDER_NR_PAEGS,
> pageblock_nr_pages) alignment instead of pageblock alignment. It seems to
> be an uncovered bug in the current code, since all callers uses at least
> max(MAX_ORDER_NR_PAEGS, pageblock_nr_pages) alignment.
>
> The reason is that if start_isolate_page_range() is only pageblock aligned
> and a caller wants to isolate one pageblock from a MAX_ORDER-1
> (2 pageblocks on x84_64 systems) free page, this will lead to MIGRATE_ISOLATE
> accounting error. To avoid it, start_isolate_page_range() needs to isolate
> the max(MAX_ORDER_NR_PAEGS, pageblock_nr_pages) aligned range.
So, let me see if I get this straight:
You are saying that, currently, alloc_contig_ranges() works on the biggest
alignment otherwise we might have this scenario:
[ MAX_ORDER-1 ]
[pageblock#0][pageblock#1]
We only want to isolate pageblock#1, so we pass a pageblock-aligned range to
start_isolate_page_range(), but the page belonging to pageblock#1 spans
pageblock#0 and pageblock#1 because it is a MAX_ORDER-1 page.
So when we call set_migratetype_isolate()->set_pageblock_migratetype(), this will
mark either pageblock#0 or pageblock#1 as isolated, but the whole page will be put
in the MIGRATE_ISOLATE freelist by move_freepages_block()->move_freepages().
Meaning, we wil effectively have two pageblocks isolated, but only one marked
as such?
Did I get it right or did I miss something?
I know that this has been discussed previously, and the cover-letter already
mentions it, but I think it would be great to have some sort of information about
the problem in the commit message as well, so people do not have to go and find
it somewhere else.
--
Oscar Salvador
SUSE Labs
^ permalink raw reply
* Re: [PATCH v4 3/7] mm: page_isolation: check specified range for unmovable pages
From: Oscar Salvador @ 2022-01-25 13:21 UTC (permalink / raw)
To: Zi Yan
Cc: Mel Gorman, David Hildenbrand, linuxppc-dev, linux-kernel,
virtualization, linux-mm, iommu, Eric Ren, Robin Murphy,
Christoph Hellwig, Vlastimil Babka, Marek Szyprowski
In-Reply-To: <20220125131943.GA5609@linux>
On Tue, Jan 25, 2022 at 02:19:46PM +0100, Oscar Salvador wrote:
> I know that this has been discussed previously, and the cover-letter already
> mentions it, but I think it would be great to have some sort of information about
> the problem in the commit message as well, so people do not have to go and find
> it somewhere else.
Sorry, the commit already points it out, but I meant to elaborate some more.
--
Oscar Salvador
SUSE Labs
^ permalink raw reply
* [PATCH] macintosh: macio_asic: remove useless cast for driver.name
From: Corentin Labbe @ 2022-01-25 13:54 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, linux-kernel, Corentin Labbe
pci_driver name is const char pointer, so the cast it not necessary.
Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
---
drivers/macintosh/macio_asic.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/macintosh/macio_asic.c b/drivers/macintosh/macio_asic.c
index c1fdf2896021..1943a007e2d5 100644
--- a/drivers/macintosh/macio_asic.c
+++ b/drivers/macintosh/macio_asic.c
@@ -756,7 +756,7 @@ MODULE_DEVICE_TABLE (pci, pci_ids);
/* pci driver glue; this is a "new style" PCI driver module */
static struct pci_driver macio_pci_driver = {
- .name = (char *) "macio",
+ .name = "macio",
.id_table = pci_ids,
.probe = macio_pci_probe,
--
2.34.1
^ permalink raw reply related
* Re: Build regressions/improvements in v5.17-rc1
From: Thomas Bogendoerfer @ 2022-01-25 14:20 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: alsa-devel, kvm, netdev, linux-um, linux-kernel, amd-gfx,
linux-mips, Lakshmi Sowjanya D, sparclinux, linuxppc-dev,
Tobin C. Harding
In-Reply-To: <alpine.DEB.2.22.394.2201240851560.2674757@ramsan.of.borg>
On Mon, Jan 24, 2022 at 08:55:40AM +0100, Geert Uytterhoeven wrote:
> > + /kisskb/src/lib/test_printf.c: error: "PTR" redefined [-Werror]: => 247:0, 247
> > + /kisskb/src/sound/pci/ca0106/ca0106.h: error: "PTR" redefined [-Werror]: => 62, 62:0
>
> mips-gcc8/mips-allmodconfig
> mipsel/mips-allmodconfig
fixing patch sent.
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea. [ RFC1925, 2.3 ]
^ permalink raw reply
* Re: [powerpc] ftrace warning kernel/trace/ftrace.c:2068 with code-patching selftests
From: Steven Rostedt @ 2022-01-25 14:28 UTC (permalink / raw)
To: Sachin Sant; +Cc: Yinan Liu, linuxppc-dev
In-Reply-To: <E92BCDD9-9631-4668-815E-8D443D2E21D9@linux.ibm.com>
On Tue, 25 Jan 2022 09:30:51 +0530
Sachin Sant <sachinp@linux.ibm.com> wrote:
> Tested-by: Sachin Sant <sachinp@linux.ibm.com>
Thanks, I'll start running it through my tests and send it to Linus later
today or tomorrow.
-- Steve
^ permalink raw reply
* [linux-next] 5.17.0-rc1-next-20220124 kernel fails to boot on my powerpc box
From: Abdul Haleem @ 2022-01-25 14:52 UTC (permalink / raw)
To: linux-next; +Cc: sachinp, Stephen Rothwell, linuxppc-dev
Greeting's
Today's next kernel 5.17.0-rc1-next-20220124(first bad) fails to boot on
my powerpc box.
I see it booted fine last Friday for kernel 5.16.0-next-20220121
Boot logs:
Removing IBM Power 842 compression device
device-mapper: multipath: 253:0: Failing path 8:0.
scsi 0:0:0:0: alua: Detached
scsi 0:0:1:0: alua: Detached
kexec_core: Starting new kernel
kexec: waiting for cpu 16 (physical 16) to enter 1 state
kexec: waiting for cpu 17 (physical 17) to enter 1 state
kexec: waiting for cpu 1 (physical 1) to enter 2 state
kexec: waiting for cpu 3 (physical 3) to enter 2 state
kexec: waiting for cpu 8 (physical 8) to enter 2 state
kexec: waiting for cpu 9 (physical 9) to enter 2 state
kexec: waiting for cpu 10 (physical 10) to enter 2 state
kexec: waiting for cpu 11 (physical 11) to enter 2 state
kexec: waiting for cpu 13 (physical 13) to enter 2 state
kexec: waiting for cpu 16 (physical 16) to enter 2 state
kexec: waiting for cpu 17 (physical 17) to enter 2 state
kexec: Starting switchover sequence.
y
Reserving 1024MB of memory at 128MB for crashkernel (System RAM: 30720MB)
hash-mmu: Page sizes from device-tree:
hash-mmu: base_shift=12: shift=12, sllp=0x0000, avpnm=0x00000000,
tlbiel=1, penc=0
hash-mmu: base_shift=12: shift=16, sllp=0x0000, avpnm=0x00000000,
tlbiel=1, penc=7
hash-mmu: base_shift=12: shift=24, sllp=0x0000, avpnm=0x00000000,
tlbiel=1, penc=56
hash-mmu: base_shift=16: shift=16, sllp=0x0110, avpnm=0x00000000,
tlbiel=1, penc=1
hash-mmu: base_shift=16: shift=24, sllp=0x0110, avpnm=0x00000000,
tlbiel=1, penc=8
hash-mmu: base_shift=24: shift=24, sllp=0x0100, avpnm=0x00000001,
tlbiel=0, penc=0
hash-mmu: base_shift=34: shift=34, sllp=0x0120, avpnm=0x000007ff,
tlbiel=0, penc=3
Enabling pkeys with max key count 31
Activating Kernel Userspace Access Prevention
Activating Kernel Userspace Execution Prevention
Using 1TB segments
hash-mmu: Initializing hash mmu with SLB
Linux version 5.17.0-rc1-next-20220124-autotest
(root@ltc-zz3-lp1.aus.stglabs.ibm.com) (gcc (GCC) 8.3.1 20190507 (Red
Hat 8.3.1-4), GNU ld version 2.30-58.el8) #1 SMP Tue Jan 25 04:47:57 CST
2022
Found initrd at 0xc000000005800000:0xc000000007d2892c
Using pSeries machine description
printk: bootconsole [udbg0] enabled
Partition configured for 24 cpus.
CPU maps initialized for 8 threads per core
numa: Partition configured for 32 NUMA nodes.
-----------------------------------------------------
phys_mem_size = 0x780000000
dcache_bsize = 0x80
icache_bsize = 0x80
cpu_features = 0x0001c07b8f5f9187
possible = 0x000ffbfbcf5fb187
always = 0x0000000380008181
cpu_user_features = 0xdc0065c2 0xeff00000
mmu_features = 0x7c006e01
firmware_features = 0x0000009fc45bfc57
vmalloc start = 0xc008000000000000
IO start = 0xc00a000000000000
vmemmap start = 0xc00c000000000000
hash-mmu: ppc64_pft_size = 0x1c
hash-mmu: htab_hash_mask = 0x1fffff
-----------------------------------------------------
numa: NODE_DATA [mem 0x77ff1ef00-0x77ff23fff]
rfi-flush: fallback displacement flush available
rfi-flush: mttrig type flush available
count-cache-flush: flush disabled.
link-stack-flush: software flush enabled.
stf-barrier: eieio barrier available
lpar: H_BLOCK_REMOVE supports base psize:0 psize:0 block size:8
lpar: H_BLOCK_REMOVE supports base psize:0 psize:2 block size:8
lpar: H_BLOCK_REMOVE supports base psize:0 psize:10 block size:8
lpar: H_BLOCK_REMOVE supports base psize:2 psize:2 block size:8
lpar: H_BLOCK_REMOVE supports base psize:2 psize:10 block size:8
PPC64 nvram contains 15360 bytes
PV qspinlock hash table entries: 4096 (order: 0, 65536 bytes, linear)
barrier-nospec: using ORI speculation barrier
Zone ranges:
Normal [mem 0x0000000000000000-0x000000077fffffff]
Movable zone start for each node
Early memory node ranges
node 0: [mem 0x0000000000000000-0x000000077fffffff]
Initmem setup node 0 [mem 0x0000000000000000-0x000000077fffffff]
percpu: Embedded 10 pages/cpu s590744 r0 d64616 u1048576
Fallback order for Node 0: 0
Built 1 zonelists, mobility grouping on. Total pages: 491040
Policy zone: Normal
Kernel command line:
BOOT_IMAGE=/vmlinuz-5.16.0-rc5-next-20211220-autotest
root=UUID=8b32580a-0de0-4694-882d-7db2567ad115 ro crashkernel=1024M
biosdevname=0 ibmvfc.mq=0
Unknown kernel command line parameters
"BOOT_IMAGE=/vmlinuz-5.16.0-rc5-next-20211220-autotest biosdevname=0",
will be passed to user space.
Dentry cache hash table entries: 4194304 (order: 9, 33554432 bytes, linear)
Inode-cache hash table entries: 2097152 (order: 8, 16777216 bytes, linear)
mem auto-init: stack:off, heap alloc:off, heap free:off
Memory: 30158976K/31457280K available (12992K kernel code, 5696K rwdata,
4160K rodata, 3904K init, 2588K bss, 1298304K reserved, 0K cma-reserved)
SLUB: HWalign=128, Order=0-3, MinObjects=0, CPUs=24, Nodes=32
trace event string verifier disabled
rcu: Hierarchical RCU implementation.
rcu: RCU event tracing is enabled.
rcu: RCU restricting CPUs from NR_CPUS=2048 to nr_cpu_ids=24.
rcu: RCU debug extended QS entry/exit.
Trampoline variant of Tasks RCU enabled.
Rude variant of Tasks RCU enabled.
Tracing variant of Tasks RCU enabled.
rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies.
rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=24
NR_IRQS: 512, nr_irqs: 512, preallocated irqs: 16
random: get_random_u64 called from start_kernel+0x65c/0x8bc with crng_init=0
time_init: 56 bit decrementer (max: 7fffffffffffff)
clocksource: timebase: mask: 0xffffffffffffffff max_cycles:
0x761537d007, max_idle_ns: 440795202126 ns
clocksource: timebase mult[1f40000] shift[24] registered
Console: colour dummy device 80x25
printk: console [hvc0] enabled
printk: console [hvc0] enabled
printk: bootconsole [udbg0] disabled
printk: bootconsole [udbg0] disabled
pid_max: default: 32768 minimum: 301
LSM: Security Framework initializing
Yama: becoming mindful.
SELinux: Initializing.
Mount-cache hash table entries: 65536 (order: 3, 524288 bytes, linear)
Mountpoint-cache hash table entries: 65536 (order: 3, 524288 bytes, linear)
cblist_init_generic: Setting adjustable number of callback queues.
cblist_init_generic: Setting shift to 4 and lim to 1.
cblist_init_generic: Setting shift to 4 and lim to 1.
cblist_init_generic: Setting shift to 4 and lim to 1.
POWER9 performance monitor hardware support registered
rcu: Hierarchical SRCU implementation.
smp: Bringing up secondary CPUs ...
smp: Brought up 1 node, 24 CPUs
numa: Node 0 CPUs: 0-23
Big cores detected but using small core scheduling
devtmpfs: initialized
clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff,
max_idle_ns: 19112604462750000 ns
futex hash table entries: 8192 (order: 4, 1048576 bytes, linear)
NET: Registered PF_NETLINK/PF_ROUTE protocol family
audit: initializing netlink subsys (disabled)
audit: type=2000 audit(1643112925.010:1): state=initialized
audit_enabled=0 res=1
thermal_sys: Registered thermal governor 'fair_share'
thermal_sys: Registered thermal governor 'step_wise'
cpuidle: using governor menu
pstore: Registered nvram as persistent store backend
EEH: pSeries platform initialized
software IO TLB: tearing down default memory pool
PCI: Probing PCI hardware
EEH: No capable adapters found: recovery disabled.
pseries-rng: Registering arch random hook.
kprobes: kprobe jump-optimization is enabled. All kprobes are optimized
if possible.
HugeTLB registered 16.0 MiB page size, pre-allocated 0 pages
HugeTLB registered 16.0 GiB page size, pre-allocated 0 pages
iommu: Default domain type: Translated
iommu: DMA domain TLB invalidation policy: strict mode
vgaarb: loaded
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
EDAC MC: Ver: 3.0.0
NetLabel: Initializing
NetLabel: domain hash size = 128
NetLabel: protocols = UNLABELED CIPSOv4 CALIPSO
NetLabel: unlabeled traffic allowed by default
clocksource: Switched to clocksource timebase
VFS: Disk quotas dquot_6.6.0
VFS: Dquot-cache hash table entries: 8192 (order 0, 65536 bytes)
NET: Registered PF_INET protocol family
IP idents hash table entries: 262144 (order: 5, 2097152 bytes, linear)
tcp_listen_portaddr_hash hash table entries: 16384 (order: 2, 262144
bytes, linear)
TCP established hash table entries: 262144 (order: 5, 2097152 bytes, linear)
TCP bind hash table entries: 65536 (order: 4, 1048576 bytes, linear)
TCP: Hash tables configured (established 262144 bind 65536)
UDP hash table entries: 16384 (order: 3, 524288 bytes, linear)
UDP-Lite hash table entries: 16384 (order: 3, 524288 bytes, linear)
NET: Registered PF_UNIX/PF_LOCAL protocol family
PCI: CLS 0 bytes, default 128
Trying to unpack rootfs image as initramfs...
IOMMU table initialized, virtual merging enabled
vas: API is supported only with radix page tables
hv-24x7: read 1530 catalog entries, created 509 event attrs (0
failures), 275 descs
Initialise system trusted keyrings
workingset: timestamp_bits=38 max_order=19 bucket_order=0
zbud: loaded
NET: Registered PF_ALG protocol family
Key type asymmetric registered
Asymmetric key parser 'x509' registered
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 249)
io scheduler mq-deadline registered
io scheduler kyber registered
atomic64_test: passed
Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
Non-volatile memory driver v1.3
Linux agpgart interface v0.103
rdac: device handler registered
hp_sw: device handler registered
emc: device handler registered
alua: device handler registered
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ehci-pci: EHCI PCI platform driver
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
ohci-pci: OHCI PCI platform driver
uhci_hcd: USB Universal Host Controller Interface driver
usbcore: registered new interface driver usbserial_generic
usbserial: USB Serial support registered for generic
mousedev: PS/2 mouse device common for all mice
rtc-generic rtc-generic: registered as rtc0
rtc-generic rtc-generic: setting system clock to 2022-01-25T12:15:25 UTC
(1643112925)
nx_compress_pseries ibm,compression-v1: nx842_OF_upd: max_sync_size
new:65536 old:0
nx_compress_pseries ibm,compression-v1: nx842_OF_upd: max_sync_sg
new:510 old:0
nx_compress_pseries ibm,compression-v1: nx842_OF_upd: max_sg_len
new:4080 old:0
NX-GZIP is not supported. Returned=-524
hid: raw HID events driver (C) Jiri Kosina
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
drop_monitor: Initializing network drop monitor service
Initializing XFRM netlink socket
NET: Registered PF_INET6 protocol family
Segment Routing with IPv6
In-situ OAM (IOAM) with IPv6
NET: Registered PF_PACKET protocol family
registered taskstats version 1
Loading compiled-in X.509 certificates
Freeing initrd memory: 38016K
alg: No test for pkcs1pad(rsa,sha1) (pkcs1pad(rsa-generic,sha1))
Loaded X.509 cert 'Build time autogenerated kernel key:
984d2d0a058cae59d928008a328cb345ccb6f5b1'
zswap: loaded using pool lzo/zbud
pstore: Using crash dump compression: deflate
alg: No test for 842 (842-nx)
INFO: task swapper/0:1 blocked for more than 122 seconds.
Not tainted 5.17.0-rc1-next-20220124-autotest #1
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:swapper/0 state:D stack: 0 pid: 1 ppid: 0
flags:0x00000800
Call Trace:
[c000000003483960] [c0000000034839a0] 0xc0000000034839a0 (unreliable)
[c000000003483b50] [c00000000001e328] __switch_to+0x278/0x490
[c000000003483bb0] [c000000000c9c2f8] __schedule+0x318/0xa00
[c000000003483c70] [c000000000c9ca48] schedule+0x68/0x130
[c000000003483ca0] [c000000000c9d048] schedule_preempt_disabled+0x18/0x30
[c000000003483cc0] [c000000000c9f49c] __mutex_lock.isra.11+0x36c/0x6f0
[c000000003483d50] [c000000000296228] kprobe_free_init_mem+0x48/0xe8
[c000000003483da0] [c0000000000127c4] kernel_init+0x44/0x1a0
[c000000003483e10] [c00000000000ce64] ret_from_kernel_thread+0x5c/0x64
INFO: task kworker/17:1:145 blocked for more than 122 seconds.
Not tainted 5.17.0-rc1-next-20220124-autotest #1
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:kworker/17:1 state:D stack: 0 pid: 145 ppid: 2
flags:0x00000800
Workqueue: events kprobe_optimizer
Call Trace:
[c00000004ccbb6d0] [000000077a820000] 0x77a820000 (unreliable)
[c00000004ccbb8c0] [c00000000001e328] __switch_to+0x278/0x490
[c00000004ccbb920] [c000000000c9c2f8] __schedule+0x318/0xa00
[c00000004ccbb9e0] [c000000000c9ca48] schedule+0x68/0x130
[c00000004ccbba10] [c000000000ca47c8] schedule_timeout+0x348/0x3f0
[c00000004ccbbaf0] [c000000000c9ec20] wait_for_completion+0x140/0x270
[c00000004ccbbb60] [c0000000001fb08c] __wait_rcu_gp+0x21c/0x230
[c00000004ccbbbc0] [c0000000001fb0e0] synchronize_rcu_tasks+0x40/0x70
[c00000004ccbbc20] [c0000000002927d0] kprobe_optimizer+0x1b0/0x3a0
[c00000004ccbbc90] [c0000000001724b8] process_one_work+0x288/0x560
[c00000004ccbbd30] [c000000000172808] worker_thread+0x78/0x620
[c00000004ccbbdc0] [c00000000017e7fc] kthread+0x11c/0x130
[c00000004ccbbe10] [c00000000000ce64] ret_from_kernel_thread+0x5c/0x64
call traces never ends and could not login
--
Regard's
Abdul Haleem
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH v2 4/4] KVM: PPC: Decrement module refcount if init_vm fails
From: Fabiano Rosas @ 2022-01-25 15:08 UTC (permalink / raw)
To: Nicholas Piggin, kvm-ppc; +Cc: aik, linuxppc-dev
In-Reply-To: <1643082153.tb99kluqtm.astroid@bobo.none>
Nicholas Piggin <npiggin@gmail.com> writes:
> Excerpts from Fabiano Rosas's message of January 25, 2022 8:08 am:
>> We increment the reference count for KVM-HV/PR before the call to
>> kvmppc_core_init_vm. If that function fails we need to decrement the
>> refcount.
>>
>> Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com>
>> ---
>> Caught this while testing Nick's LPID patches by looking at
>> /sys/module/kvm_hv/refcnt
>
> Nice catch. Is this the only change in the series?
Yes.
> You can just use kvm_ops->owner like try_module_get() does I think? Also
> try_module_get works on a NULL module same as module_put by the looks,
> so you could adjust that in this patch to remove the NULL check so it
> is consistent with the put.
Sure, I'll send a v3.
^ permalink raw reply
* [PATCH v3 0/4] KVM: PPC: KVM module exit fixes
From: Fabiano Rosas @ 2022-01-25 15:57 UTC (permalink / raw)
To: kvm-ppc; +Cc: linuxppc-dev, npiggin, aik
changes from v2:
- patch 4: Matched module_put() to try_module_get()
v2:
https://lore.kernel.org/r/20220124220803.1011673-1-farosas@linux.ibm.com
v1:
https://lore.kernel.org/r/20211223211931.3560887-1-farosas@linux.ibm.com
Fabiano Rosas (4):
KVM: PPC: Book3S HV: Check return value of kvmppc_radix_init
KVM: PPC: Book3S HV: Delay setting of kvm ops
KVM: PPC: Book3S HV: Free allocated memory if module init fails
KVM: PPC: Decrement module refcount if init_vm fails
arch/powerpc/kvm/book3s_hv.c | 28 ++++++++++++++++++++--------
arch/powerpc/kvm/powerpc.c | 9 +++++++--
2 files changed, 27 insertions(+), 10 deletions(-)
--
2.34.1
^ permalink raw reply
* [PATCH v3 1/4] KVM: PPC: Book3S HV: Check return value of kvmppc_radix_init
From: Fabiano Rosas @ 2022-01-25 15:57 UTC (permalink / raw)
To: kvm-ppc; +Cc: linuxppc-dev, npiggin, aik
In-Reply-To: <20220125155735.1018683-1-farosas@linux.ibm.com>
The return of the function is being shadowed by the call to
kvmppc_uvmem_init.
Fixes: ca9f4942670c ("KVM: PPC: Book3S HV: Support for running secure guests")
Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com>
Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/kvm/book3s_hv.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index d1817cd9a691..3a3845f366d4 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -6138,8 +6138,11 @@ static int kvmppc_book3s_init_hv(void)
if (r)
return r;
- if (kvmppc_radix_possible())
+ if (kvmppc_radix_possible()) {
r = kvmppc_radix_init();
+ if (r)
+ return r;
+ }
r = kvmppc_uvmem_init();
if (r < 0)
--
2.34.1
^ permalink raw reply related
* [PATCH v3 2/4] KVM: PPC: Book3S HV: Delay setting of kvm ops
From: Fabiano Rosas @ 2022-01-25 15:57 UTC (permalink / raw)
To: kvm-ppc; +Cc: linuxppc-dev, npiggin, aik
In-Reply-To: <20220125155735.1018683-1-farosas@linux.ibm.com>
Delay the setting of kvm_hv_ops until after all init code has
completed. This avoids leaving the ops still accessible if the init
fails.
Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com>
---
arch/powerpc/kvm/book3s_hv.c | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index 3a3845f366d4..b9aace212599 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -6127,9 +6127,6 @@ static int kvmppc_book3s_init_hv(void)
}
#endif
- kvm_ops_hv.owner = THIS_MODULE;
- kvmppc_hv_ops = &kvm_ops_hv;
-
init_default_hcalls();
init_vcore_lists();
@@ -6145,10 +6142,15 @@ static int kvmppc_book3s_init_hv(void)
}
r = kvmppc_uvmem_init();
- if (r < 0)
+ if (r < 0) {
pr_err("KVM-HV: kvmppc_uvmem_init failed %d\n", r);
+ return r;
+ }
- return r;
+ kvm_ops_hv.owner = THIS_MODULE;
+ kvmppc_hv_ops = &kvm_ops_hv;
+
+ return 0;
}
static void kvmppc_book3s_exit_hv(void)
--
2.34.1
^ permalink raw reply related
* [PATCH v3 3/4] KVM: PPC: Book3S HV: Free allocated memory if module init fails
From: Fabiano Rosas @ 2022-01-25 15:57 UTC (permalink / raw)
To: kvm-ppc; +Cc: linuxppc-dev, npiggin, aik
In-Reply-To: <20220125155735.1018683-1-farosas@linux.ibm.com>
The module's exit function is not called when the init fails, we need
to do cleanup before returning.
Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com>
Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/kvm/book3s_hv.c | 15 +++++++++++----
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index b9aace212599..87a49651a402 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -6104,7 +6104,7 @@ static int kvmppc_book3s_init_hv(void)
if (!cpu_has_feature(CPU_FTR_ARCH_300)) {
r = kvm_init_subcore_bitmap();
if (r)
- return r;
+ goto err;
}
/*
@@ -6120,7 +6120,8 @@ static int kvmppc_book3s_init_hv(void)
np = of_find_compatible_node(NULL, NULL, "ibm,opal-intc");
if (!np) {
pr_err("KVM-HV: Cannot determine method for accessing XICS\n");
- return -ENODEV;
+ r = -ENODEV;
+ goto err;
}
/* presence of intc confirmed - node can be dropped again */
of_node_put(np);
@@ -6133,12 +6134,12 @@ static int kvmppc_book3s_init_hv(void)
r = kvmppc_mmu_hv_init();
if (r)
- return r;
+ goto err;
if (kvmppc_radix_possible()) {
r = kvmppc_radix_init();
if (r)
- return r;
+ goto err;
}
r = kvmppc_uvmem_init();
@@ -6151,6 +6152,12 @@ static int kvmppc_book3s_init_hv(void)
kvmppc_hv_ops = &kvm_ops_hv;
return 0;
+
+err:
+ kvmhv_nested_exit();
+ kvmppc_radix_exit();
+
+ return r;
}
static void kvmppc_book3s_exit_hv(void)
--
2.34.1
^ permalink raw reply related
* [PATCH v3 4/4] KVM: PPC: Decrement module refcount if init_vm fails
From: Fabiano Rosas @ 2022-01-25 15:57 UTC (permalink / raw)
To: kvm-ppc; +Cc: linuxppc-dev, npiggin, aik
In-Reply-To: <20220125155735.1018683-1-farosas@linux.ibm.com>
We increment the reference count for KVM-HV/PR before the call to
kvmppc_core_init_vm. If that function fails we need to decrement the
refcount.
Also remove the check on kvm_ops->owner because try_module_get can
handle a NULL module.
Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com>
Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/kvm/powerpc.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index 2ad0ccd202d5..a6d6d452243f 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -431,6 +431,8 @@ int kvm_arch_check_processor_compat(void *opaque)
int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
{
struct kvmppc_ops *kvm_ops = NULL;
+ int r;
+
/*
* if we have both HV and PR enabled, default is HV
*/
@@ -452,11 +454,14 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
} else
goto err_out;
- if (kvm_ops->owner && !try_module_get(kvm_ops->owner))
+ if (!try_module_get(kvm_ops->owner))
return -ENOENT;
kvm->arch.kvm_ops = kvm_ops;
- return kvmppc_core_init_vm(kvm);
+ r = kvmppc_core_init_vm(kvm);
+ if (r)
+ module_put(kvm_ops->owner);
+ return r;
err_out:
return -EINVAL;
}
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v4 3/7] mm: page_isolation: check specified range for unmovable pages
From: Zi Yan @ 2022-01-25 16:31 UTC (permalink / raw)
To: Oscar Salvador
Cc: Mel Gorman, David Hildenbrand, linuxppc-dev, linux-kernel,
virtualization, linux-mm, iommu, Eric Ren, Robin Murphy,
Christoph Hellwig, Vlastimil Babka, Marek Szyprowski
In-Reply-To: <20220125132108.GB5609@linux>
[-- Attachment #1: Type: text/plain, Size: 652 bytes --]
On 25 Jan 2022, at 8:21, Oscar Salvador wrote:
> On Tue, Jan 25, 2022 at 02:19:46PM +0100, Oscar Salvador wrote:
>> I know that this has been discussed previously, and the cover-letter already
>> mentions it, but I think it would be great to have some sort of information about
>> the problem in the commit message as well, so people do not have to go and find
>> it somewhere else.
>
> Sorry, the commit already points it out, but I meant to elaborate some more.
You got it right about the issue.
And I will add more text in the commit message and function comments to clarify
the situation.
Thanks for your suggestions.
--
Best Regards,
Yan, Zi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 854 bytes --]
^ permalink raw reply
* Re: [PATCH 00/16] Remove usage of the deprecated "pci-dma-compat.h" API
From: Moritz Fischer @ 2022-01-25 19:28 UTC (permalink / raw)
To: Christophe JAILLET
Cc: airlied, trix, linux-fpga, linux-pci, paulus, sparclinux,
kernel-janitors, linux-scsi, sathya.prakash, hch,
MPT-FusionLinux.pdl, hao.wu, arnd, suganath-prabu.subramani,
sreekanth.reddy, ink, bhelgaas, mchehab, mattst88, rth, awalls,
linux-kernel, davem, alex.bou9, vkoul, linux-alpha, dmaengine,
mdf, akpm, linux-media, linuxppc-dev, yilun.xu
In-Reply-To: <cover.1641500561.git.christophe.jaillet@wanadoo.fr>
On Thu, Jan 06, 2022 at 10:45:13PM +0100, Christophe JAILLET wrote:
> This serie axes all the remaining usages of the deprecated "pci-dma-compat.h"
> API.
>
> All these patches have already been posted.
>
> They have been generated with a coccinelle script.
> The tricky parts are patches that use dma_alloc_coherent() because the correct
> GFP flag has to be used in place of the previous embedded GFP_ATOMIC.
>
> Patches 1-3 are already Reviewed. References to the corresponding mail is
> given below the ---
>
> Patch 1-2,4-10 are just generated from the coccinelle script. Only too long
> lines have been hand modified. dma_alloc_coherent() modification are NOT part
> of these patches.
>
> Patch 3 also includes some 'dma_set_mask_and_coherent()' instead of
> 'pci_set_dma_mask()/pci_set_consistent_dma_mask()'.
> I've left this additional modification because it was reviewed with it.
>
> Patch 10-15 are the tricky parts. Explanation of which GFP flag is the right one
> is given in each patch. It has been divided in several patches to ease review.
>
> Patch 15 is the only one I'm slighly unsure with. The old code was using a
> GFP_USER flag in the function. I'm not familiar with it.
> I *guess* that GFP_KERNEL is fine, but maybe it should also be GFP_USER or left
> as GFP_ATOMIC so that nothing is changed.
>
> Patch 16 is the last step that remove "pci-dma-compat.h" and its only usage.
>
>
> All patches, exept 1-2,6 that are architecture specific, have been compile tested.
>
>
> After all that, a few rst files, 1 or 2 strings in error messages and some
> error branching labels should still need some attention.
> This is some minor issues.
>
>
> Only the cover letter is sent to every one. Each patch is sent to the
> corresponding maintainer(s) + Andrew Morton, Christoph Hellwig and Arnd Bergmann.
>
>
> Best regards.
>
>
> Christophe JAILLET (16):
> alpha: Remove usage of the deprecated "pci-dma-compat.h" API
> floppy: Remove usage of the deprecated "pci-dma-compat.h" API
> fpga: dfl: pci: Remove usage of the deprecated "pci-dma-compat.h" API
> media: Remove usage of the deprecated "pci-dma-compat.h" API
> agp/intel: Remove usage of the deprecated "pci-dma-compat.h" API
> sparc: Remove usage of the deprecated "pci-dma-compat.h" API
> dmaengine: pch_dma: Remove usage of the deprecated "pci-dma-compat.h"
> API
> rapidio/tsi721: Remove usage of the deprecated "pci-dma-compat.h" API
> media: v4l2-pci-skeleton: Remove usage of the deprecated
> "pci-dma-compat.h" API
> scsi: message: fusion: Remove usage of the deprecated
> "pci-dma-compat.h" API
> scsi: mptbase: Use dma_alloc_coherent() in 'mpt_alloc_fw_memory()'
> scsi: mptbase: Use dma_alloc_coherent()
> scsi: mptsas: Use dma_alloc_coherent() in
> mptsas_exp_repmanufacture_info()
> scsi: mptsas: Use dma_alloc_coherent()
> scsi: mptctl: Use dma_alloc_coherent()
> PCI: Remove usage of the deprecated "pci-dma-compat.h" API
>
> arch/alpha/include/asm/floppy.h | 7 +-
> arch/alpha/kernel/pci_iommu.c | 12 +--
> arch/powerpc/include/asm/floppy.h | 8 +-
> arch/sparc/kernel/ioport.c | 2 +-
> drivers/char/agp/intel-gtt.c | 26 ++---
> drivers/dma/pch_dma.c | 2 +-
> drivers/fpga/dfl-pci.c | 14 +--
> drivers/media/pci/cx18/cx18-queue.h | 6 +-
> drivers/media/pci/ivtv/ivtv-queue.h | 25 +++--
> drivers/media/pci/ivtv/ivtv-udma.h | 8 +-
> drivers/message/fusion/mptbase.c | 149 ++++++++++++++++------------
> drivers/message/fusion/mptctl.c | 82 +++++++++------
> drivers/message/fusion/mptlan.c | 90 +++++++++--------
> drivers/message/fusion/mptsas.c | 94 +++++++++---------
> drivers/rapidio/devices/tsi721.c | 8 +-
> include/linux/pci-dma-compat.h | 129 ------------------------
> include/linux/pci.h | 3 -
> samples/v4l/v4l2-pci-skeleton.c | 2 +-
> 18 files changed, 289 insertions(+), 378 deletions(-)
> delete mode 100644 include/linux/pci-dma-compat.h
>
> --
> 2.32.0
>
Applied [03/16] to linux-fpga for-next.
Thanks,
Moritz
^ 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