* Re: [PATCH v2] sched/core: fix illegal RCU from offline CPUs
From: Michael Ellerman @ 2020-04-02 11:24 UTC (permalink / raw)
To: Qian Cai, peterz, mingo
Cc: juri.lelli, James.Bottomley, vincent.guittot, linux-parisc,
paulmck, deller, Nicholas Piggin, linux-kernel, rostedt, bsegall,
linux-mm, Qian Cai, mgorman, tglx, linuxppc-dev, dietmar.eggemann
In-Reply-To: <20200401214033.8448-1-cai@lca.pw>
Qian Cai <cai@lca.pw> writes:
> From: Peter Zijlstra <peterz@infradead.org>
>
> In the CPU-offline process, it calls mmdrop() after idle entry and the
> subsequent call to cpuhp_report_idle_dead(). Once execution passes the
> call to rcu_report_dead(), RCU is ignoring the CPU, which results in
> lockdep complaining when mmdrop() uses RCU from either memcg or
> debugobjects below.
>
> Fix it by cleaning up the active_mm state from BP instead. Every arch
> which has CONFIG_HOTPLUG_CPU should have already called idle_task_exit()
> from AP. The only exception is parisc because it switches them to
> &init_mm unconditionally (see smp_boot_one_cpu() and smp_cpu_init()),
> but the patch will still work there because it calls mmgrab(&init_mm) in
> smp_cpu_init() and then should call mmdrop(&init_mm) in finish_cpu().
Thanks for debugging this. How did you hit it in the first place?
A link to the original thread would have helped me:
https://lore.kernel.org/lkml/20200113190331.12788-1-cai@lca.pw/
> WARNING: suspicious RCU usage
> -----------------------------
> kernel/workqueue.c:710 RCU or wq_pool_mutex should be held!
>
> other info that might help us debug this:
>
> RCU used illegally from offline CPU!
> Call Trace:
> dump_stack+0xf4/0x164 (unreliable)
> lockdep_rcu_suspicious+0x140/0x164
> get_work_pool+0x110/0x150
> __queue_work+0x1bc/0xca0
> queue_work_on+0x114/0x120
> css_release+0x9c/0xc0
> percpu_ref_put_many+0x204/0x230
> free_pcp_prepare+0x264/0x570
> free_unref_page+0x38/0xf0
> __mmdrop+0x21c/0x2c0
> idle_task_exit+0x170/0x1b0
> pnv_smp_cpu_kill_self+0x38/0x2e0
> cpu_die+0x48/0x64
> arch_cpu_idle_dead+0x30/0x50
> do_idle+0x2f4/0x470
> cpu_startup_entry+0x38/0x40
> start_secondary+0x7a8/0xa80
> start_secondary_resume+0x10/0x14
Do we know when this started happening? ie. can we determine a Fixes
tag?
> <Peter to sign off here>
> Signed-off-by: Qian Cai <cai@lca.pw>
> ---
> arch/powerpc/platforms/powernv/smp.c | 1 -
> include/linux/sched/mm.h | 2 ++
> kernel/cpu.c | 18 +++++++++++++++++-
> kernel/sched/core.c | 5 +++--
> 4 files changed, 22 insertions(+), 4 deletions(-)
>
> diff --git a/arch/powerpc/platforms/powernv/smp.c b/arch/powerpc/platforms/powernv/smp.c
> index 13e251699346..b2ba3e95bda7 100644
> --- a/arch/powerpc/platforms/powernv/smp.c
> +++ b/arch/powerpc/platforms/powernv/smp.c
> @@ -167,7 +167,6 @@ static void pnv_smp_cpu_kill_self(void)
> /* Standard hot unplug procedure */
>
> idle_task_exit();
> - current->active_mm = NULL; /* for sanity */
If I'm reading it right, we'll now be running with active_mm == init_mm
in the offline loop.
I guess that's fine, I can't think of any reason it would matter, and it
seems like we were NULL'ing it out just for paranoia's sake not because
of any actual problem.
Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
cheers
> diff --git a/include/linux/sched/mm.h b/include/linux/sched/mm.h
> index c49257a3b510..a132d875d351 100644
> --- a/include/linux/sched/mm.h
> +++ b/include/linux/sched/mm.h
> @@ -49,6 +49,8 @@ static inline void mmdrop(struct mm_struct *mm)
> __mmdrop(mm);
> }
>
> +void mmdrop(struct mm_struct *mm);
> +
> /*
> * This has to be called after a get_task_mm()/mmget_not_zero()
> * followed by taking the mmap_sem for writing before modifying the
> diff --git a/kernel/cpu.c b/kernel/cpu.c
> index 2371292f30b0..244d30544377 100644
> --- a/kernel/cpu.c
> +++ b/kernel/cpu.c
> @@ -3,6 +3,7 @@
> *
> * This code is licenced under the GPL.
> */
> +#include <linux/sched/mm.h>
> #include <linux/proc_fs.h>
> #include <linux/smp.h>
> #include <linux/init.h>
> @@ -564,6 +565,21 @@ static int bringup_cpu(unsigned int cpu)
> return bringup_wait_for_ap(cpu);
> }
>
> +static int finish_cpu(unsigned int cpu)
> +{
> + struct task_struct *idle = idle_thread_get(cpu);
> + struct mm_struct *mm = idle->active_mm;
> +
> + /*
> + * idle_task_exit() will have switched to &init_mm, now
> + * clean up any remaining active_mm state.
> + */
> + if (mm != &init_mm)
> + idle->active_mm = &init_mm;
> + mmdrop(mm);
> + return 0;
> +}
> +
> /*
> * Hotplug state machine related functions
> */
> @@ -1549,7 +1565,7 @@ static struct cpuhp_step cpuhp_hp_states[] = {
> [CPUHP_BRINGUP_CPU] = {
> .name = "cpu:bringup",
> .startup.single = bringup_cpu,
> - .teardown.single = NULL,
> + .teardown.single = finish_cpu,
> .cant_stop = true,
> },
> /* Final state before CPU kills itself */
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index a2694ba82874..8787958339d5 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -6200,13 +6200,14 @@ void idle_task_exit(void)
> struct mm_struct *mm = current->active_mm;
>
> BUG_ON(cpu_online(smp_processor_id()));
> + BUG_ON(current != this_rq()->idle);
>
> if (mm != &init_mm) {
> switch_mm(mm, &init_mm, current);
> - current->active_mm = &init_mm;
> finish_arch_post_lock_switch();
> }
> - mmdrop(mm);
> +
> + /* finish_cpu(), as ran on the BP, will clean up the active_mm state */
> }
>
> /*
> --
> 2.21.0 (Apple Git-122.2)
^ permalink raw reply
* Re: [PATCH v3 1/1] ppc/crash: Reset spinlocks during crash
From: Michael Ellerman @ 2020-04-02 11:28 UTC (permalink / raw)
To: Leonardo Bras, Benjamin Herrenschmidt, Paul Mackerras,
Enrico Weigelt, Leonardo Bras, Alexios Zavras, Thomas Gleixner,
Greg Kroah-Hartman, Christophe Leroy, peterz
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20200401000020.590447-1-leonardo@linux.ibm.com>
Leonardo Bras <leonardo@linux.ibm.com> writes:
> During a crash, there is chance that the cpus that handle the NMI IPI
> are holding a spin_lock. If this spin_lock is needed by crashing_cpu it
> will cause a deadlock. (rtas.lock and printk logbuf_lock as of today)
>
> This is a problem if the system has kdump set up, given if it crashes
> for any reason kdump may not be saved for crash analysis.
>
> After NMI IPI is sent to all other cpus, force unlock all spinlocks
> needed for finishing crash routine.
I'm not convinced this is the right approach.
Busting locks is risky, it could easily cause a crash if data structures
are left in some inconsistent state.
I think we need to make this code more careful about what it's doing.
There's a clue at the top of default_machine_crash_shutdown(), which
calls crash_kexec_prepare_cpus():
* This function is only called after the system
* has panicked or is otherwise in a critical state.
* The minimum amount of code to allow a kexec'd kernel
* to run successfully needs to happen here.
You said the "IPI complete" message was the cause of one lockup:
#0 arch_spin_lock
#1 do_raw_spin_lock
#2 __raw_spin_lock
#3 _raw_spin_lock
#4 vprintk_emit
#5 vprintk_func
#7 crash_kexec_prepare_cpus
#8 default_machine_crash_shutdown
#9 machine_crash_shutdown
#10 __crash_kexec
#11 crash_kexec
#12 oops_end
TBH I think we could just drop that printk() entirely.
Or we could tell printk() that we're in NMI context so that it uses the
percpu buffers.
We should probably do the latter anyway, in case there's any other code
we call that inadvertently calls printk().
The RTAS trace you sent was:
#0 arch_spin_lock
#1 lock_rtas ()
#2 rtas_call (token=8204, nargs=1, nret=1, outputs=0x0)
#3 ics_rtas_mask_real_irq (hw_irq=4100)
#4 machine_kexec_mask_interrupts
#5 default_machine_crash_shutdown
#6 machine_crash_shutdown
#7 __crash_kexec
#8 crash_kexec
#9 oops_end
Which doesn't make it clear who holds the RTAS lock. We really shouldn't
be crashing while holding the RTAS lock, but I guess it could happen.
Can you get a full backtrace?
PAPR says we are not allowed to have multiple CPUs calling RTAS at once,
except for a very small list of RTAS calls. So if we bust the RTAS lock
there's a risk we violate that part of PAPR and crash even harder.
Also it's not specific to kdump, we can't even get through a normal
reboot if we crash with the RTAS lock held.
Anyway here's a patch with some ideas. That allows me to get from a
crash with the RTAS lock held through kdump into the 2nd kernel. But it
only works if it's the crashing CPU that holds the RTAS lock.
cheers
diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
index c5fa251b8950..44ce74966d60 100644
--- a/arch/powerpc/kernel/rtas.c
+++ b/arch/powerpc/kernel/rtas.c
@@ -25,6 +25,7 @@
#include <linux/reboot.h>
#include <linux/syscalls.h>
+#include <asm/debugfs.h>
#include <asm/prom.h>
#include <asm/rtas.h>
#include <asm/hvcall.h>
@@ -65,6 +66,8 @@ unsigned long rtas_rmo_buf;
void (*rtas_flash_term_hook)(int);
EXPORT_SYMBOL(rtas_flash_term_hook);
+static int rtas_lock_holder = -1;
+
/* RTAS use home made raw locking instead of spin_lock_irqsave
* because those can be called from within really nasty contexts
* such as having the timebase stopped which would lockup with
@@ -76,7 +79,20 @@ static unsigned long lock_rtas(void)
local_irq_save(flags);
preempt_disable();
- arch_spin_lock(&rtas.lock);
+
+ if (!arch_spin_trylock(&rtas.lock)) {
+ // Couldn't get the lock, do we already hold it?
+ if (rtas_lock_holder == smp_processor_id())
+ // Yes, so we would have deadlocked on ourself. Assume
+ // we're crashing and continue on hopefully ...
+ return flags;
+
+ // No, wait on the lock
+ arch_spin_lock(&rtas.lock);
+ }
+
+ rtas_lock_holder = smp_processor_id();
+
return flags;
}
@@ -85,6 +101,8 @@ static void unlock_rtas(unsigned long flags)
arch_spin_unlock(&rtas.lock);
local_irq_restore(flags);
preempt_enable();
+
+ rtas_lock_holder = -1;
}
/*
@@ -1263,3 +1281,24 @@ void rtas_take_timebase(void)
timebase = 0;
arch_spin_unlock(&timebase_lock);
}
+
+static int rtas_crash_set(void *data, u64 val)
+{
+ printk("%s: Taking RTAS lock and then crashing ...\n", __func__);
+ lock_rtas();
+
+ *((volatile int *) 0) = 0;
+
+ return 0;
+}
+
+DEFINE_DEBUGFS_ATTRIBUTE(fops_rtas_crash, NULL, rtas_crash_set, "%llu\n");
+
+static __init int rtas_crash_debugfs_init(void)
+{
+ debugfs_create_file_unsafe("crash_in_rtas", 0200,
+ powerpc_debugfs_root, NULL,
+ &fops_rtas_crash);
+ return 0;
+}
+device_initcall(rtas_crash_debugfs_init);
diff --git a/arch/powerpc/kexec/crash.c b/arch/powerpc/kexec/crash.c
index d488311efab1..4c52cb58e889 100644
--- a/arch/powerpc/kexec/crash.c
+++ b/arch/powerpc/kexec/crash.c
@@ -15,6 +15,7 @@
#include <linux/crash_dump.h>
#include <linux/delay.h>
#include <linux/irq.h>
+#include <linux/printk.h>
#include <linux/types.h>
#include <asm/processor.h>
@@ -311,6 +312,8 @@ void default_machine_crash_shutdown(struct pt_regs *regs)
unsigned int i;
int (*old_handler)(struct pt_regs *regs);
+ printk_nmi_enter();
+
/*
* This function is only called after the system
* has panicked or is otherwise in a critical state.
^ permalink raw reply related
* [PATCH] Revert "powerpc/64: irq_work avoid interrupt when called with hardware irqs enabled"
From: Nicholas Piggin @ 2020-04-02 12:04 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Nicholas Piggin
This reverts commit ebb37cf3ffd39fdb6ec5b07111f8bb2f11d92c5f.
That commit does not play well with soft-masked irq state manipulations
in idle, interrupt replay, and possibly others due to tracing code
sometimes using irq_work_queue (e.g., in trace_hardirqs_on()). That
can cause PACA_IRQ_DEC to become set when it is not expected, and be
ignored or cleared or cause warnings.
The net result seems to be missing an irq_work until the next timer
interrupt in the worst case which is usually not going to be noticed,
however it could be a long time if the tick is disabled, which is
agains the spirit of irq_work and might cause real problems.
The idea is still solid, but it would need more work. It's not really
clear if it would be worth added complexity, so revert this for now
(not a straight revert, but replace with a comment explaining why we
might see interrupts happening, and gives git blame something to find).
Fixes: ebb37cf3ffd3 ("powerpc/64: irq_work avoid interrupt when called with hardware irqs enabled")
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
This started tripping some warnings testing the latest interrupt code
which juggled a few things around, but it looks like it may have had
problems before that too.
arch/powerpc/kernel/time.c | 44 +++++++++++---------------------------
1 file changed, 13 insertions(+), 31 deletions(-)
diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index 1168e8b37e30..716f8d0960a7 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -522,35 +522,6 @@ static inline void clear_irq_work_pending(void)
"i" (offsetof(struct paca_struct, irq_work_pending)));
}
-void arch_irq_work_raise(void)
-{
- preempt_disable();
- set_irq_work_pending_flag();
- /*
- * Non-nmi code running with interrupts disabled will replay
- * irq_happened before it re-enables interrupts, so setthe
- * decrementer there instead of causing a hardware exception
- * which would immediately hit the masked interrupt handler
- * and have the net effect of setting the decrementer in
- * irq_happened.
- *
- * NMI interrupts can not check this when they return, so the
- * decrementer hardware exception is raised, which will fire
- * when interrupts are next enabled.
- *
- * BookE does not support this yet, it must audit all NMI
- * interrupt handlers to ensure they call nmi_enter() so this
- * check would be correct.
- */
- if (IS_ENABLED(CONFIG_BOOKE) || !irqs_disabled() || in_nmi()) {
- set_dec(1);
- } else {
- hard_irq_disable();
- local_paca->irq_happened |= PACA_IRQ_DEC;
- }
- preempt_enable();
-}
-
#else /* 32-bit */
DEFINE_PER_CPU(u8, irq_work_pending);
@@ -559,16 +530,27 @@ DEFINE_PER_CPU(u8, irq_work_pending);
#define test_irq_work_pending() __this_cpu_read(irq_work_pending)
#define clear_irq_work_pending() __this_cpu_write(irq_work_pending, 0)
+#endif /* 32 vs 64 bit */
+
void arch_irq_work_raise(void)
{
+ /*
+ * 64-bit code that uses irq soft-mask can just cause an immediate
+ * interrupt here that gets soft masked, if this is called under
+ * local_irq_disable(). It might be possible to prevent that happening
+ * by noticing interrupts are disabled and setting decrementer pending
+ * to be replayed when irqs are enabled. The problem there is that
+ * tracing can call irq_work_raise, including in code that does low
+ * level manipulations of irq soft-mask state (e.g., trace_hardirqs_on)
+ * which could get tangled up if we're messing with the same state
+ * here.
+ */
preempt_disable();
set_irq_work_pending_flag();
set_dec(1);
preempt_enable();
}
-#endif /* 32 vs 64 bit */
-
#else /* CONFIG_IRQ_WORK */
#define test_irq_work_pending() 0
--
2.23.0
^ permalink raw reply related
* [PATCH] powerpc/64s: Fix doorbell wakeup msgclr optimisation
From: Nicholas Piggin @ 2020-04-02 12:12 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Nicholas Piggin
Commit 3282a3da25bd ("powerpc/64: Implement soft interrupt replay in C")
broke the doorbell wakeup optimisation introduced by commit a9af97aa0a12
("powerpc/64s: msgclr when handling doorbell exceptions from system
reset").
This patch restores it, in C code. It's moved explicitly to the system
reset wakeup path, rather than the doorbell replay path, because it is
always the right thing to do in the wakeup case, but it could be rare to
have a pending message in other cases in which case it's wasted work --
we would have to be done to see if that was a worthwhile optimisation,
and I suspect it would not be.
The results are similar to those in the original commit, test on POWER8
of context_switch selftests benchmark with polling idle disabled (e.g.,
always nap, giving cross-CPU IPIs) gives the following results:
broken patched
Different threads, same core: 317k/s 375k/s +18.7%
Different cores: 280k/s 282k/s +1.0%
Fixes: 3282a3da25bd ("powerpc/64: Implement soft interrupt replay in C")
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/kernel/exceptions-64s.S | 19 -------------------
arch/powerpc/kernel/irq.c | 13 +++++++++++++
2 files changed, 13 insertions(+), 19 deletions(-)
diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
index 18bbce143084..728ccb0f560c 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -3121,22 +3121,3 @@ handle_dabr_fault:
li r5,SIGSEGV
bl bad_page_fault
b interrupt_return
-
-/*
- * When doorbell is triggered from system reset wakeup, the message is
- * not cleared, so it would fire again when EE is enabled.
- *
- * When coming from local_irq_enable, there may be the same problem if
- * we were hard disabled.
- *
- * Execute msgclr to clear pending exceptions before handling it.
- */
-h_doorbell_common_msgclr:
- LOAD_REG_IMMEDIATE(r3, PPC_DBELL_MSGTYPE << (63-36))
- PPC_MSGCLR(3)
- b h_doorbell_common_virt
-
-doorbell_super_common_msgclr:
- LOAD_REG_IMMEDIATE(r3, PPC_DBELL_MSGTYPE << (63-36))
- PPC_MSGCLRP(3)
- b doorbell_super_common_virt
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index 6ea27dbcb872..ed6230ba0c43 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -527,6 +527,19 @@ void irq_set_pending_from_srr1(unsigned long srr1)
return;
}
+ if (reason == PACA_IRQ_DBELL) {
+ /*
+ * When doorbell triggers a system reset wakeup, the message
+ * is not cleared, so if the doorbell interrupt is replayed
+ * and the IPI handled, the doorbell interrupt would still
+ * fire when EE is enabled.
+ *
+ * To avoid taking the superfluous doorbell interrupt,
+ * execute a msgclr here before the interrupt is replayed.
+ */
+ ppc_msgclr(PPC_DBELL_MSGTYPE);
+ }
+
/*
* The 0 index (SRR1[42:45]=b0000) must always evaluate to 0,
* so this can be called unconditionally with the SRR1 wake
--
2.23.0
^ permalink raw reply related
* [PATCH v2] powerpc/64: Update Speculation_Store_Bypass in /proc/<pid>/status
From: Michael Ellerman @ 2020-04-02 12:49 UTC (permalink / raw)
To: linuxppc-dev; +Cc: gwalbon, ricklind
Currently we don't report anything useful in /proc/<pid>/status:
$ grep Speculation_Store_Bypass /proc/self/status
Speculation_Store_Bypass: unknown
Our mitigation is currently always a barrier instruction, which
doesn't map that well onto the existing possibilities for the PR_SPEC
values.
However even if we added a "barrier" type PR_SPEC value, userspace
would still need to consult some other source to work out which type
of barrier to use. So reporting "vulnerable" seems sufficient, as
userspace can see that and then consult its source to determine what
barrier to use.
Signed-off-by: Gustavo Walbon <gwalbon@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/kernel/security.c | 35 ++++++++++++++++++++++++++++++++++
1 file changed, 35 insertions(+)
v2: Change the logic.
diff --git a/arch/powerpc/kernel/security.c b/arch/powerpc/kernel/security.c
index bd70f5be1c27..7c0b7b55e969 100644
--- a/arch/powerpc/kernel/security.c
+++ b/arch/powerpc/kernel/security.c
@@ -7,6 +7,7 @@
#include <linux/cpu.h>
#include <linux/kernel.h>
#include <linux/device.h>
+#include <linux/prctl.h>
#include <linux/seq_buf.h>
#include <asm/asm-prototypes.h>
@@ -353,6 +354,40 @@ ssize_t cpu_show_spec_store_bypass(struct device *dev, struct device_attribute *
return sprintf(buf, "Vulnerable\n");
}
+static int ssb_prctl_get(struct task_struct *task)
+{
+ if (stf_enabled_flush_types == STF_BARRIER_NONE)
+ /*
+ * We don't have an explicit signal from firmware that we're
+ * vulnerable or not, we only have certain CPU revisions that
+ * are known to be vulnerable.
+ *
+ * We assume that if we're on another CPU, where the barrier is
+ * NONE, then we are not vulnerable.
+ */
+ return PR_SPEC_NOT_AFFECTED;
+ else
+ /*
+ * If we do have a barrier type then we are vulnerable. The
+ * barrier is not a global or per-process mitigation, so the
+ * only value we can report here is PR_SPEC_ENABLE, which
+ * appears as "vulnerable" in /proc.
+ */
+ return PR_SPEC_ENABLE;
+
+ return -EINVAL;
+}
+
+int arch_prctl_spec_ctrl_get(struct task_struct *task, unsigned long which)
+{
+ switch (which) {
+ case PR_SPEC_STORE_BYPASS:
+ return ssb_prctl_get(task);
+ default:
+ return -ENODEV;
+ }
+}
+
#ifdef CONFIG_DEBUG_FS
static int stf_barrier_set(void *data, u64 val)
{
base-commit: c17eb4dca5a353a9dbbb8ad6934fe57af7165e91
--
2.25.1
^ permalink raw reply related
* Re: [PATCH v8 6/7] tools/perf: Enable Hz/hz prinitg for --metric-only option
From: Jiri Olsa @ 2020-04-02 12:49 UTC (permalink / raw)
To: Kajol Jain
Cc: mark.rutland, maddy, peterz, yao.jin, mingo, kan.liang, ak,
alexander.shishkin, anju, mamatha4, sukadev, ravi.bangoria, acme,
jmario, namhyung, tglx, mpetlan, gregkh, linux-kernel,
linux-perf-users, jolsa, linuxppc-dev
In-Reply-To: <20200401203340.31402-7-kjain@linux.ibm.com>
On Thu, Apr 02, 2020 at 02:03:39AM +0530, Kajol Jain wrote:
> Commit 54b5091606c18 ("perf stat: Implement --metric-only mode")
> added function 'valid_only_metric()' which drops "Hz" or "hz",
> if it is part of "ScaleUnit". This patch enable it since hv_24x7
> supports couple of frequency events.
>
> Signed-off-by: Kajol Jain <kjain@linux.ibm.com>
> ---
> tools/perf/util/stat-display.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/tools/perf/util/stat-display.c b/tools/perf/util/stat-display.c
> index 9e757d18d713..679aaa655824 100644
> --- a/tools/perf/util/stat-display.c
> +++ b/tools/perf/util/stat-display.c
> @@ -237,8 +237,6 @@ static bool valid_only_metric(const char *unit)
> if (!unit)
> return false;
> if (strstr(unit, "/sec") ||
> - strstr(unit, "hz") ||
> - strstr(unit, "Hz") ||
will this change output of --metric-only for some setups then?
Andi, are you ok with this?
other than this, the patchset looks ok to me
thanks,
jirka
> strstr(unit, "CPUs utilized"))
> return false;
> return true;
> --
> 2.21.0
>
^ permalink raw reply
* Re: [PATCH v4 00/25] Add support for OpenCAPI Persistent Memory devices
From: Greg Kurz @ 2020-04-02 11:10 UTC (permalink / raw)
To: Michael Ellerman
Cc: Madhavan Srinivasan, Alexey Kardashevskiy, Mahesh Salgaonkar,
Masahiro Yamada, Oliver O'Halloran, Mauro Carvalho Chehab,
Ira Weiny, Thomas Gleixner, Rob Herring, Dave Jiang, linux-nvdimm,
Aneesh Kumar K . V, Krzysztof Kozlowski, Anju T Sudhakar,
Alastair D'Silva, Andrew Donnellan, Arnd Bergmann,
Nicholas Piggin, Cédric Le Goater, Dan Williams,
Hari Bathini, Linux MM, Greg Kroah-Hartman,
Linux Kernel Mailing List, Vishal Verma, Frederic Barrat,
Paul Mackerras, Andrew Morton, linuxppc-dev, David S. Miller
In-Reply-To: <87bloatd6e.fsf@mpe.ellerman.id.au>
On Thu, 02 Apr 2020 21:06:01 +1100
Michael Ellerman <mpe@ellerman.id.au> wrote:
> "Oliver O'Halloran" <oohall@gmail.com> writes:
> > On Thu, Apr 2, 2020 at 2:42 PM Michael Ellerman <mpe@ellerman.id.au> wrote:
> >> "Alastair D'Silva" <alastair@d-silva.org> writes:
> >> >> -----Original Message-----
> >> >> From: Dan Williams <dan.j.williams@intel.com>
> >> >>
> >> >> On Sun, Mar 29, 2020 at 10:23 PM Alastair D'Silva <alastair@d-silva.org>
> >> >> wrote:
> >> >> >
> >> >> > *snip*
> >> >> Are OPAL calls similar to ACPI DSMs? I.e. methods for the OS to invoke
> >> >> platform firmware services? What's Skiboot?
> >> >
> >> > Yes, OPAL is the interface to firmware for POWER. Skiboot is the open-source (and only) implementation of OPAL.
> >>
> >> https://github.com/open-power/skiboot
> >>
> >> In particular the tokens for calls are defined here:
> >>
> >> https://github.com/open-power/skiboot/blob/master/include/opal-api.h#L220
> >>
> >> And you can grep for the token to find the implementation:
> >>
> >> https://github.com/open-power/skiboot/blob/master/hw/npu2-opencapi.c#L2328
> >
> > I'm not sure I'd encourage anyone to read npu2-opencapi.c. I find it
> > hard enough to follow even with access to the workbooks.
>
> Compared to certain firmwares that run on certain other platforms it's
> actually pretty readable code ;)
>
Forth rocks ! ;-)
> > There's an OPAL call API reference here:
> > http://open-power.github.io/skiboot/doc/opal-api/index.html
>
> Even better.
>
> cheers
^ permalink raw reply
* [PATCH] powerpc/mm: ptdump: Add missing include <asm/vio.h>
From: YueHaibing @ 2020-04-02 13:58 UTC (permalink / raw)
To: mpe, benh, paulus, gregkh, christophe.leroy, allison, armijn,
tglx, aneesh.kumar, yuehaibing
Cc: linuxppc-dev, linux-kernel
gcc build fails:
arch/powerpc/mm/ptdump/hashpagetable.c: In function ‘pseries_find’:
arch/powerpc/mm/ptdump/hashpagetable.c:262:18: error: ‘H_SUCCESS’ undeclared (first use in this function); did you mean ‘FL_ACCESS’?
if (lpar_rc != H_SUCCESS)
^~~~~~~~~
FL_ACCESS
Reported-by: Hulk Robot <hulkci@huawei.com>
Fixes: 65e701b2d2a8 ("powerpc/ptdump: drop non vital #ifdefs")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
arch/powerpc/mm/ptdump/hashpagetable.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/mm/ptdump/hashpagetable.c b/arch/powerpc/mm/ptdump/hashpagetable.c
index b6ed9578382f..8ea5f9a3b658 100644
--- a/arch/powerpc/mm/ptdump/hashpagetable.c
+++ b/arch/powerpc/mm/ptdump/hashpagetable.c
@@ -20,6 +20,7 @@
#include <asm/page.h>
#include <asm/pgalloc.h>
#include <asm/plpar_wrappers.h>
+#include <asm/vio.h>
#include <linux/memblock.h>
#include <asm/firmware.h>
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v2] sched/core: fix illegal RCU from offline CPUs
From: Qian Cai @ 2020-04-02 14:00 UTC (permalink / raw)
To: Michael Ellerman
Cc: juri.lelli, James.Bottomley@hansenpartnership.com,
vincent.guittot, linux-parisc, paulmck, Peter Zijlstra, deller,
Nicholas Piggin, linux-kernel, rostedt, bsegall, linux-mm,
Ingo Molnar, mgorman, tglx, linuxppc-dev, dietmar.eggemann
In-Reply-To: <87369mt9kf.fsf@mpe.ellerman.id.au>
> On Apr 2, 2020, at 7:24 AM, Michael Ellerman <mpe@ellerman.id.au> wrote:
>
> Qian Cai <cai@lca.pw> writes:
>> From: Peter Zijlstra <peterz@infradead.org>
>>
>> In the CPU-offline process, it calls mmdrop() after idle entry and the
>> subsequent call to cpuhp_report_idle_dead(). Once execution passes the
>> call to rcu_report_dead(), RCU is ignoring the CPU, which results in
>> lockdep complaining when mmdrop() uses RCU from either memcg or
>> debugobjects below.
>>
>> Fix it by cleaning up the active_mm state from BP instead. Every arch
>> which has CONFIG_HOTPLUG_CPU should have already called idle_task_exit()
>> from AP. The only exception is parisc because it switches them to
>> &init_mm unconditionally (see smp_boot_one_cpu() and smp_cpu_init()),
>> but the patch will still work there because it calls mmgrab(&init_mm) in
>> smp_cpu_init() and then should call mmdrop(&init_mm) in finish_cpu().
>
> Thanks for debugging this. How did you hit it in the first place?
Just repeatedly offline/online CPUs which will eventually cause an idle thread
refcount goes to 0 and trigger __mmdrop() and of course it needs to enable
lockdep (PROVE_RCU?) as well as having luck to hit the cgroup, workqueue
or debugobject code paths to call RCU.
>
> A link to the original thread would have helped me:
>
> https://lore.kernel.org/lkml/20200113190331.12788-1-cai@lca.pw/
>
>> WARNING: suspicious RCU usage
>> -----------------------------
>> kernel/workqueue.c:710 RCU or wq_pool_mutex should be held!
>>
>> other info that might help us debug this:
>>
>> RCU used illegally from offline CPU!
>> Call Trace:
>> dump_stack+0xf4/0x164 (unreliable)
>> lockdep_rcu_suspicious+0x140/0x164
>> get_work_pool+0x110/0x150
>> __queue_work+0x1bc/0xca0
>> queue_work_on+0x114/0x120
>> css_release+0x9c/0xc0
>> percpu_ref_put_many+0x204/0x230
>> free_pcp_prepare+0x264/0x570
>> free_unref_page+0x38/0xf0
>> __mmdrop+0x21c/0x2c0
>> idle_task_exit+0x170/0x1b0
>> pnv_smp_cpu_kill_self+0x38/0x2e0
>> cpu_die+0x48/0x64
>> arch_cpu_idle_dead+0x30/0x50
>> do_idle+0x2f4/0x470
>> cpu_startup_entry+0x38/0x40
>> start_secondary+0x7a8/0xa80
>> start_secondary_resume+0x10/0x14
>
> Do we know when this started happening? ie. can we determine a Fixes
> tag?
I don’t know. I looked at some commits that it seems the code was like that
even 10-year ago. It must be nobody who cares to run lockdep (PROVE_RCU?)
with CPU hotplug very regularly.
>
>> <Peter to sign off here>
>> Signed-off-by: Qian Cai <cai@lca.pw>
>> ---
>> arch/powerpc/platforms/powernv/smp.c | 1 -
>> include/linux/sched/mm.h | 2 ++
>> kernel/cpu.c | 18 +++++++++++++++++-
>> kernel/sched/core.c | 5 +++--
>> 4 files changed, 22 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/powerpc/platforms/powernv/smp.c b/arch/powerpc/platforms/powernv/smp.c
>> index 13e251699346..b2ba3e95bda7 100644
>> --- a/arch/powerpc/platforms/powernv/smp.c
>> +++ b/arch/powerpc/platforms/powernv/smp.c
>> @@ -167,7 +167,6 @@ static void pnv_smp_cpu_kill_self(void)
>> /* Standard hot unplug procedure */
>>
>> idle_task_exit();
>> - current->active_mm = NULL; /* for sanity */
>
> If I'm reading it right, we'll now be running with active_mm == init_mm
> in the offline loop.
>
> I guess that's fine, I can't think of any reason it would matter, and it
> seems like we were NULL'ing it out just for paranoia's sake not because
> of any actual problem.
>
> Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
>
>
> cheers
>
>> diff --git a/include/linux/sched/mm.h b/include/linux/sched/mm.h
>> index c49257a3b510..a132d875d351 100644
>> --- a/include/linux/sched/mm.h
>> +++ b/include/linux/sched/mm.h
>> @@ -49,6 +49,8 @@ static inline void mmdrop(struct mm_struct *mm)
>> __mmdrop(mm);
>> }
>>
>> +void mmdrop(struct mm_struct *mm);
>> +
>> /*
>> * This has to be called after a get_task_mm()/mmget_not_zero()
>> * followed by taking the mmap_sem for writing before modifying the
>> diff --git a/kernel/cpu.c b/kernel/cpu.c
>> index 2371292f30b0..244d30544377 100644
>> --- a/kernel/cpu.c
>> +++ b/kernel/cpu.c
>> @@ -3,6 +3,7 @@
>> *
>> * This code is licenced under the GPL.
>> */
>> +#include <linux/sched/mm.h>
>> #include <linux/proc_fs.h>
>> #include <linux/smp.h>
>> #include <linux/init.h>
>> @@ -564,6 +565,21 @@ static int bringup_cpu(unsigned int cpu)
>> return bringup_wait_for_ap(cpu);
>> }
>>
>> +static int finish_cpu(unsigned int cpu)
>> +{
>> + struct task_struct *idle = idle_thread_get(cpu);
>> + struct mm_struct *mm = idle->active_mm;
>> +
>> + /*
>> + * idle_task_exit() will have switched to &init_mm, now
>> + * clean up any remaining active_mm state.
>> + */
>> + if (mm != &init_mm)
>> + idle->active_mm = &init_mm;
>> + mmdrop(mm);
>> + return 0;
>> +}
>> +
>> /*
>> * Hotplug state machine related functions
>> */
>> @@ -1549,7 +1565,7 @@ static struct cpuhp_step cpuhp_hp_states[] = {
>> [CPUHP_BRINGUP_CPU] = {
>> .name = "cpu:bringup",
>> .startup.single = bringup_cpu,
>> - .teardown.single = NULL,
>> + .teardown.single = finish_cpu,
>> .cant_stop = true,
>> },
>> /* Final state before CPU kills itself */
>> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
>> index a2694ba82874..8787958339d5 100644
>> --- a/kernel/sched/core.c
>> +++ b/kernel/sched/core.c
>> @@ -6200,13 +6200,14 @@ void idle_task_exit(void)
>> struct mm_struct *mm = current->active_mm;
>>
>> BUG_ON(cpu_online(smp_processor_id()));
>> + BUG_ON(current != this_rq()->idle);
>>
>> if (mm != &init_mm) {
>> switch_mm(mm, &init_mm, current);
>> - current->active_mm = &init_mm;
>> finish_arch_post_lock_switch();
>> }
>> - mmdrop(mm);
>> +
>> + /* finish_cpu(), as ran on the BP, will clean up the active_mm state */
>> }
>>
>> /*
>> --
>> 2.21.0 (Apple Git-122.2)
^ permalink raw reply
* Re: WARNING in ext4_da_update_reserve_space
From: Dmitry Vyukov @ 2020-04-02 14:31 UTC (permalink / raw)
To: Murilo Opsfelder Araújo
Cc: Theodore Ts'o, mareklindner, sw, b.a.t.m.a.n, a, syzbot, LKML,
syzkaller-bugs, netdev, Andreas Dilger, Paul Mackerras,
linux-ext4, linuxppc-dev, David Miller
In-Reply-To: <2094673.WoIe4zePQG@kermit.br.ibm.com>
On Thu, Apr 2, 2020 at 4:06 PM Murilo Opsfelder Araújo
<muriloo@linux.ibm.com> wrote:
>
> On Thursday, April 2, 2020 8:02:11 AM -03 syzbot wrote:
> > Hello,
> >
> > syzbot found the following crash on:
> >
> > HEAD commit: 1a147b74 Merge branch 'DSA-mtu'
> > git tree: net-next
> > console output: https://syzkaller.appspot.com/x/log.txt?x=14237713e00000
> > kernel config: https://syzkaller.appspot.com/x/.config?x=46ee14d4915944bc
> > dashboard link: https://syzkaller.appspot.com/bug?extid=67e4f16db666b1c8253c
> > compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12237713e00000
> > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=10ec7c97e00000
> >
> > The bug was bisected to:
> >
> > commit 658b0f92bc7003bc734471f61bf7cd56339eb8c3
> > Author: Murilo Opsfelder Araujo <muriloo@linux.ibm.com>
> > Date: Wed Aug 1 21:33:15 2018 +0000
> >
> > powerpc/traps: Print unhandled signals in a separate function
>
> This commit is specific to powerpc and the crash is from an x86_64 system.
>
> There is a bunch of scp errors in the logs:
>
> scp: ./syz-executor998635077: No space left on device
>
> Is it possible that these errors might be misleading the syzbot?
You may see how it reacted on them based on
# git bisect bad/good
lines. As far as I see these errors did not confuse it.
But this guy did:
run #0: crashed: general protection fault in batadv_iv_ogm_queue_add
> > bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=15979f5be00000
> > final crash: https://syzkaller.appspot.com/x/report.txt?x=17979f5be00000
> > console output: https://syzkaller.appspot.com/x/log.txt?x=13979f5be00000
> >
> > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > Reported-by: syzbot+67e4f16db666b1c8253c@syzkaller.appspotmail.com
> > Fixes: 658b0f92bc70 ("powerpc/traps: Print unhandled signals in a separate
> > function")
> >
> > EXT4-fs warning (device sda1): ext4_da_update_reserve_space:344:
> > ext4_da_update_reserve_space: ino 15722, used 1 with only 0 reserved data
> > blocks ------------[ cut here ]------------
> > WARNING: CPU: 1 PID: 359 at fs/ext4/inode.c:348
> > ext4_da_update_reserve_space+0x622/0x7d0 fs/ext4/inode.c:344 Kernel panic -
> > not syncing: panic_on_warn set ...
> > CPU: 1 PID: 359 Comm: kworker/u4:5 Not tainted 5.6.0-rc7-syzkaller #0
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> > Google 01/01/2011 Workqueue: writeback wb_workfn (flush-8:0)
> > Call Trace:
> > __dump_stack lib/dump_stack.c:77 [inline]
> > dump_stack+0x188/0x20d lib/dump_stack.c:118
> > panic+0x2e3/0x75c kernel/panic.c:221
> > __warn.cold+0x2f/0x35 kernel/panic.c:582
> > report_bug+0x27b/0x2f0 lib/bug.c:195
> > fixup_bug arch/x86/kernel/traps.c:174 [inline]
> > fixup_bug arch/x86/kernel/traps.c:169 [inline]
> > do_error_trap+0x12b/0x220 arch/x86/kernel/traps.c:267
> > do_invalid_op+0x32/0x40 arch/x86/kernel/traps.c:286
> > invalid_op+0x23/0x30 arch/x86/entry/entry_64.S:1027
> > RIP: 0010:ext4_da_update_reserve_space+0x622/0x7d0 fs/ext4/inode.c:348
> > Code: 02 00 0f 85 94 01 00 00 48 8b 7d 28 49 c7 c0 20 72 3c 88 41 56 48 c7
> > c1 80 60 3c 88 53 ba 58 01 00 00 4c 89 c6 e8 1e 6d 0d 00 <0f> 0b 48 b8 00
> > 00 00 00 00 fc ff df 4c 89 ea 48 c1 ea 03 0f b6 04 RSP:
> > 0018:ffffc90002197288 EFLAGS: 00010296
> > RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000
> > RDX: 0000000000000000 RSI: ffffffff820bf066 RDI: fffff52000432e21
> > RBP: ffff888086b744c8 R08: 0000000000000091 R09: ffffed1015ce6659
> > R10: ffffed1015ce6658 R11: ffff8880ae7332c7 R12: 0000000000000001
> > R13: ffff888086b74990 R14: 0000000000000000 R15: ffff888086b74a40
> > ext4_ext_map_blocks+0x24aa/0x37d0 fs/ext4/extents.c:4500
> > ext4_map_blocks+0x4cb/0x1650 fs/ext4/inode.c:622
> > mpage_map_one_extent fs/ext4/inode.c:2365 [inline]
> > mpage_map_and_submit_extent fs/ext4/inode.c:2418 [inline]
> > ext4_writepages+0x19eb/0x3080 fs/ext4/inode.c:2772
> > do_writepages+0xfa/0x2a0 mm/page-writeback.c:2344
> > __writeback_single_inode+0x12a/0x1410 fs/fs-writeback.c:1452
> > writeback_sb_inodes+0x515/0xdd0 fs/fs-writeback.c:1716
> > wb_writeback+0x2a5/0xd90 fs/fs-writeback.c:1892
> > wb_do_writeback fs/fs-writeback.c:2037 [inline]
> > wb_workfn+0x339/0x11c0 fs/fs-writeback.c:2078
> > process_one_work+0x94b/0x1690 kernel/workqueue.c:2266
> > worker_thread+0x96/0xe20 kernel/workqueue.c:2412
> > kthread+0x357/0x430 kernel/kthread.c:255
> > ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
> > Kernel Offset: disabled
> > Rebooting in 86400 seconds..
> >
> >
> > ---
> > This bug is generated by a bot. It may contain errors.
> > See https://goo.gl/tpsmEJ for more information about syzbot.
> > syzbot engineers can be reached at syzkaller@googlegroups.com.
> >
> > syzbot will keep track of this bug report. See:
> > https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
> > For information about bisection process see: https://goo.gl/tpsmEJ#bisection
> > syzbot can test patches for this bug, for details see:
> > https://goo.gl/tpsmEJ#testing-patches
>
> --
> Murilo
>
> --
> You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bugs+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/2094673.WoIe4zePQG%40kermit.br.ibm.com.
^ permalink raw reply
* RE: [PATCH 0/6] Kill setup_irq()
From: Brian Cain @ 2020-04-02 15:03 UTC (permalink / raw)
To: 'afzal mohammed'
Cc: linux-s390, linux-samsung-soc, linux-ia64, linux-c6x-dev,
linux-parisc, linux-sh, linux-hexagon, x86, linux-kernel,
linux-mips, linux-m68k, linux-alpha, 'Thomas Gleixner',
linux-omap, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20200328073253.GA5250@afzalpc>
> -----Original Message-----
> From: linux-hexagon-owner@vger.kernel.org <linux-hexagon-
> owner@vger.kernel.org> On Behalf Of afzal mohammed
...
> On Fri, Mar 27, 2020 at 09:48:38PM -0500, Brian Cain wrote:
>
> > > Note 2: hexagon final image creation fails even w/o my patch
>
> > What's the nature of the failure in "Note 2"?
>
> drivers/base/firmware_loader/main.o: In function `fw_is_builtin_firmware':
> /devel/src/kernel6/drivers/base/firmware_loader/main.c:132:(.text+0xc8):
> relocation truncated to fit: R_HEX_16_X against symbol
`__start_builtin_fw'
> defined in .modinfo section in .tmp_vmlinux1
> Makefile:1077: recipe for target 'vmlinux' failed
> make: *** [vmlinux] Error 1
Thanks for reporting it -- I will make a patch to fix it.
-Brian
^ permalink raw reply
* [PATCH v4 0/3] Add support for divde[.] and divdeu[.] instruction emulation
From: Balamuruhan S @ 2020-04-02 15:19 UTC (permalink / raw)
To: mpe
Cc: ravi.bangoria, jniethe5, Balamuruhan S, paulus, sandipan,
naveen.n.rao, linuxppc-dev
Hi All,
This patchset adds support to emulate divde, divde., divdeu and divdeu.
instructions and testcases for it.
Changes in v4:
-------------
Fix review comments from Naveen,
* replace TEST_DIVDEU() instead of wrongly used TEST_DIVDEU_DOT() in
divdeu testcase.
* Include `acked-by` tag from Naveen for the series.
* Rebase it on latest mpe's merge tree.
Changes in v3:
-------------
* Fix suggestion from Sandipan to remove `PPC_INST_DIVDE_DOT` and
`PPC_INST_DIVDEU_DOT` opcode macros defined in ppc-opcode.h, reuse
`PPC_INST_DIVDE` and `PPC_INST_DIVDEU` in test_emulate_step.c to
derive them respectively.
Changes in v2:
-------------
* Fix review comments from Paul to make divde_dot and divdeu_dot simple
by using divde and divdeu, then goto `arith_done` instead of
`compute_done`.
* Include `Reviewed-by` tag from Sandipan Das.
* Rebase with recent mpe's merge tree.
I would request for your review and suggestions for making it better.
Boot Log:
--------
:: ::
:: ::
[ 2.777518] emulate_step_test: divde : RA = LONG_MIN, RB = LONG_MIN PASS
[ 2.777882] emulate_step_test: divde : RA = 1L, RB = 0 PASS
[ 2.778432] emulate_step_test: divde : RA = LONG_MIN, RB = LONG_MAX PASS
[ 2.778880] emulate_step_test: divde. : RA = LONG_MIN, RB = LONG_MIN PASS
[ 2.780172] emulate_step_test: divde. : RA = 1L, RB = 0 PASS
[ 2.780582] emulate_step_test: divde. : RA = LONG_MIN, RB = LONG_MAX PASS
[ 2.780983] emulate_step_test: divdeu : RA = LONG_MIN, RB = LONG_MIN PASS
[ 2.781276] emulate_step_test: divdeu : RA = 1L, RB = 0 PASS
[ 2.781579] emulate_step_test: divdeu : RA = LONG_MIN, RB = LONG_MAX PASS
[ 2.781820] emulate_step_test: divdeu : RA = LONG_MAX - 1, RB = LONG_MAX PASS
[ 2.782056] emulate_step_test: divdeu : RA = LONG_MIN + 1, RB = LONG_MIN PASS
[ 2.782296] emulate_step_test: divdeu. : RA = LONG_MIN, RB = LONG_MIN PASS
[ 2.782556] emulate_step_test: divdeu. : RA = 1L, RB = 0 PASS
[ 2.783502] emulate_step_test: divdeu. : RA = LONG_MIN, RB = LONG_MAX PASS
[ 2.783748] emulate_step_test: divdeu. : RA = LONG_MAX - 1, RB = LONG_MAX PASS
[ 2.783973] emulate_step_test: divdeu. : RA = LONG_MIN + 1, RB = LONG_MIN PASS
[ 2.789617] registered taskstats version 1
[ 2.794779] printk: console [netcon0] enabled
[ 2.794931] netconsole: network logging started
[ 2.795327] hctosys: unable to open rtc device (rtc0)
[ 2.953449] Freeing unused kernel memory: 5120K
[ 2.953639] This architecture does not have kernel memory protection.
[ 2.953918] Run /init as init process
[ 3.173573] mount (54) used greatest stack depth: 12576 bytes left
[ 3.252465] mount (55) used greatest stack depth: 12544 bytes left
Welcome to Buildroot
buildroot login:
Balamuruhan S (3):
powerpc ppc-opcode: add divde and divdeu opcodes
powerpc sstep: add support for divde[.] and divdeu[.] instructions
powerpc test_emulate_step: add testcases for divde[.] and divdeu[.]
instructions
arch/powerpc/include/asm/ppc-opcode.h | 8 ++
arch/powerpc/lib/sstep.c | 13 +-
arch/powerpc/lib/test_emulate_step.c | 164 ++++++++++++++++++++++++++
3 files changed, 184 insertions(+), 1 deletion(-)
base-commit: 9c17a47d827c00401c2ff2ba71d7ecf08ed5b677
--
2.24.1
^ permalink raw reply
* [PATCH v4 1/3] powerpc ppc-opcode: add divde and divdeu opcodes
From: Balamuruhan S @ 2020-04-02 15:19 UTC (permalink / raw)
To: mpe
Cc: ravi.bangoria, jniethe5, Balamuruhan S, paulus, sandipan,
naveen.n.rao, linuxppc-dev
In-Reply-To: <20200402151923.605791-1-bala24@linux.ibm.com>
include instruction opcodes for divde and divdeu as macros.
Reviewed-by: Sandipan Das <sandipan@linux.ibm.com>
Signed-off-by: Balamuruhan S <bala24@linux.ibm.com>
Acked-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/ppc-opcode.h | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/powerpc/include/asm/ppc-opcode.h b/arch/powerpc/include/asm/ppc-opcode.h
index c1df75edde44..9c9a604f30a6 100644
--- a/arch/powerpc/include/asm/ppc-opcode.h
+++ b/arch/powerpc/include/asm/ppc-opcode.h
@@ -339,6 +339,8 @@
#define PPC_INST_DIVWU 0x7c000396
#define PPC_INST_DIVD 0x7c0003d2
#define PPC_INST_DIVDU 0x7c000392
+#define PPC_INST_DIVDE 0x7c000352
+#define PPC_INST_DIVDEU 0x7c000312
#define PPC_INST_RLWINM 0x54000000
#define PPC_INST_RLWINM_DOT 0x54000001
#define PPC_INST_RLWIMI 0x50000000
@@ -439,6 +441,12 @@
__PPC_RA(a) | __PPC_RB(b))
#define PPC_DCBZL(a, b) stringify_in_c(.long PPC_INST_DCBZL | \
__PPC_RA(a) | __PPC_RB(b))
+#define PPC_DIVDE(t, a, b) stringify_in_c(.long PPC_INST_DIVDE | \
+ ___PPC_RT(t) | ___PPC_RA(a) | \
+ ___PPC_RB(b))
+#define PPC_DIVDEU(t, a, b) stringify_in_c(.long PPC_INST_DIVDEU | \
+ ___PPC_RT(t) | ___PPC_RA(a) | \
+ ___PPC_RB(b))
#define PPC_LQARX(t, a, b, eh) stringify_in_c(.long PPC_INST_LQARX | \
___PPC_RT(t) | ___PPC_RA(a) | \
___PPC_RB(b) | __PPC_EH(eh))
--
2.24.1
^ permalink raw reply related
* [PATCH v4 2/3] powerpc sstep: add support for divde[.] and divdeu[.] instructions
From: Balamuruhan S @ 2020-04-02 15:19 UTC (permalink / raw)
To: mpe
Cc: ravi.bangoria, jniethe5, Balamuruhan S, paulus, sandipan,
naveen.n.rao, linuxppc-dev
In-Reply-To: <20200402151923.605791-1-bala24@linux.ibm.com>
This patch adds emulation support for divde, divdeu instructions,
* Divide Doubleword Extended (divde[.])
* Divide Doubleword Extended Unsigned (divdeu[.])
Reviewed-by: Sandipan Das <sandipan@linux.ibm.com>
Signed-off-by: Balamuruhan S <bala24@linux.ibm.com>
Acked-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
---
arch/powerpc/lib/sstep.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/lib/sstep.c b/arch/powerpc/lib/sstep.c
index 5f3a7bd9d90d..c9036a75730c 100644
--- a/arch/powerpc/lib/sstep.c
+++ b/arch/powerpc/lib/sstep.c
@@ -1736,7 +1736,18 @@ int analyse_instr(struct instruction_op *op, const struct pt_regs *regs,
op->val = (int) regs->gpr[ra] /
(int) regs->gpr[rb];
goto arith_done;
-
+#ifdef __powerpc64__
+ case 425: /* divde[.] */
+ asm volatile(PPC_DIVDE(%0, %1, %2) :
+ "=r" (op->val) : "r" (regs->gpr[ra]),
+ "r" (regs->gpr[rb]));
+ goto arith_done;
+ case 393: /* divdeu[.] */
+ asm volatile(PPC_DIVDEU(%0, %1, %2) :
+ "=r" (op->val) : "r" (regs->gpr[ra]),
+ "r" (regs->gpr[rb]));
+ goto arith_done;
+#endif
case 755: /* darn */
if (!cpu_has_feature(CPU_FTR_ARCH_300))
return -1;
--
2.24.1
^ permalink raw reply related
* [PATCH v4 3/3] powerpc test_emulate_step: add testcases for divde[.] and divdeu[.] instructions
From: Balamuruhan S @ 2020-04-02 15:19 UTC (permalink / raw)
To: mpe
Cc: ravi.bangoria, jniethe5, Balamuruhan S, paulus, sandipan,
naveen.n.rao, linuxppc-dev
In-Reply-To: <20200402151923.605791-1-bala24@linux.ibm.com>
add testcases for divde, divde., divdeu, divdeu. emulated
instructions to cover few scenarios,
* with same dividend and divisor to have undefine RT
for divdeu[.]
* with divide by zero to have undefine RT for both
divde[.] and divdeu[.]
* with negative dividend to cover -|divisor| < r <= 0 if
the dividend is negative for divde[.]
* normal case with proper dividend and divisor for both
divde[.] and divdeu[.]
Reviewed-by: Sandipan Das <sandipan@linux.ibm.com>
Signed-off-by: Balamuruhan S <bala24@linux.ibm.com>
Acked-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
---
arch/powerpc/lib/test_emulate_step.c | 164 +++++++++++++++++++++++++++
1 file changed, 164 insertions(+)
diff --git a/arch/powerpc/lib/test_emulate_step.c b/arch/powerpc/lib/test_emulate_step.c
index 53df4146dd32..eb1dea47a637 100644
--- a/arch/powerpc/lib/test_emulate_step.c
+++ b/arch/powerpc/lib/test_emulate_step.c
@@ -54,6 +54,14 @@
___PPC_RA(a) | ___PPC_RB(b))
#define TEST_ADDC_DOT(t, a, b) (PPC_INST_ADDC | ___PPC_RT(t) | \
___PPC_RA(a) | ___PPC_RB(b) | 0x1)
+#define TEST_DIVDE(t, a, b) (PPC_INST_DIVDE | ___PPC_RT(t) | \
+ ___PPC_RA(a) | ___PPC_RB(b))
+#define TEST_DIVDE_DOT(t, a, b) (PPC_INST_DIVDE | ___PPC_RT(t) | \
+ ___PPC_RA(a) | ___PPC_RB(b) | 0x1)
+#define TEST_DIVDEU(t, a, b) (PPC_INST_DIVDEU | ___PPC_RT(t) | \
+ ___PPC_RA(a) | ___PPC_RB(b))
+#define TEST_DIVDEU_DOT(t, a, b)(PPC_INST_DIVDEU | ___PPC_RT(t) | \
+ ___PPC_RA(a) | ___PPC_RB(b) | 0x1)
#define MAX_SUBTESTS 16
@@ -838,6 +846,162 @@ static struct compute_test compute_tests[] = {
}
}
}
+ },
+ {
+ .mnemonic = "divde",
+ .subtests = {
+ {
+ .descr = "RA = LONG_MIN, RB = LONG_MIN",
+ .instr = TEST_DIVDE(20, 21, 22),
+ .regs = {
+ .gpr[21] = LONG_MIN,
+ .gpr[22] = LONG_MIN,
+ }
+ },
+ {
+ .descr = "RA = 1L, RB = 0",
+ .instr = TEST_DIVDE(20, 21, 22),
+ .flags = IGNORE_GPR(20),
+ .regs = {
+ .gpr[21] = 1L,
+ .gpr[22] = 0,
+ }
+ },
+ {
+ .descr = "RA = LONG_MIN, RB = LONG_MAX",
+ .instr = TEST_DIVDE(20, 21, 22),
+ .regs = {
+ .gpr[21] = LONG_MIN,
+ .gpr[22] = LONG_MAX,
+ }
+ }
+ }
+ },
+ {
+ .mnemonic = "divde.",
+ .subtests = {
+ {
+ .descr = "RA = LONG_MIN, RB = LONG_MIN",
+ .instr = TEST_DIVDE_DOT(20, 21, 22),
+ .regs = {
+ .gpr[21] = LONG_MIN,
+ .gpr[22] = LONG_MIN,
+ }
+ },
+ {
+ .descr = "RA = 1L, RB = 0",
+ .instr = TEST_DIVDE_DOT(20, 21, 22),
+ .flags = IGNORE_GPR(20),
+ .regs = {
+ .gpr[21] = 1L,
+ .gpr[22] = 0,
+ }
+ },
+ {
+ .descr = "RA = LONG_MIN, RB = LONG_MAX",
+ .instr = TEST_DIVDE_DOT(20, 21, 22),
+ .regs = {
+ .gpr[21] = LONG_MIN,
+ .gpr[22] = LONG_MAX,
+ }
+ }
+ }
+ },
+ {
+ .mnemonic = "divdeu",
+ .subtests = {
+ {
+ .descr = "RA = LONG_MIN, RB = LONG_MIN",
+ .instr = TEST_DIVDEU(20, 21, 22),
+ .flags = IGNORE_GPR(20),
+ .regs = {
+ .gpr[21] = LONG_MIN,
+ .gpr[22] = LONG_MIN,
+ }
+ },
+ {
+ .descr = "RA = 1L, RB = 0",
+ .instr = TEST_DIVDEU(20, 21, 22),
+ .flags = IGNORE_GPR(20),
+ .regs = {
+ .gpr[21] = 1L,
+ .gpr[22] = 0,
+ }
+ },
+ {
+ .descr = "RA = LONG_MIN, RB = LONG_MAX",
+ .instr = TEST_DIVDEU(20, 21, 22),
+ .regs = {
+ .gpr[21] = LONG_MIN,
+ .gpr[22] = LONG_MAX,
+ }
+ },
+ {
+ .descr = "RA = LONG_MAX - 1, RB = LONG_MAX",
+ .instr = TEST_DIVDEU(20, 21, 22),
+ .regs = {
+ .gpr[21] = LONG_MAX - 1,
+ .gpr[22] = LONG_MAX,
+ }
+ },
+ {
+ .descr = "RA = LONG_MIN + 1, RB = LONG_MIN",
+ .instr = TEST_DIVDEU(20, 21, 22),
+ .flags = IGNORE_GPR(20),
+ .regs = {
+ .gpr[21] = LONG_MIN + 1,
+ .gpr[22] = LONG_MIN,
+ }
+ }
+ }
+ },
+ {
+ .mnemonic = "divdeu.",
+ .subtests = {
+ {
+ .descr = "RA = LONG_MIN, RB = LONG_MIN",
+ .instr = TEST_DIVDEU_DOT(20, 21, 22),
+ .flags = IGNORE_GPR(20),
+ .regs = {
+ .gpr[21] = LONG_MIN,
+ .gpr[22] = LONG_MIN,
+ }
+ },
+ {
+ .descr = "RA = 1L, RB = 0",
+ .instr = TEST_DIVDEU_DOT(20, 21, 22),
+ .flags = IGNORE_GPR(20),
+ .regs = {
+ .gpr[21] = 1L,
+ .gpr[22] = 0,
+ }
+ },
+ {
+ .descr = "RA = LONG_MIN, RB = LONG_MAX",
+ .instr = TEST_DIVDEU_DOT(20, 21, 22),
+ .regs = {
+ .gpr[21] = LONG_MIN,
+ .gpr[22] = LONG_MAX,
+ }
+ },
+ {
+ .descr = "RA = LONG_MAX - 1, RB = LONG_MAX",
+ .instr = TEST_DIVDEU_DOT(20, 21, 22),
+ .regs = {
+ .gpr[21] = LONG_MAX - 1,
+ .gpr[22] = LONG_MAX,
+ }
+ },
+ {
+ .descr = "RA = LONG_MIN + 1, RB = LONG_MIN",
+ .instr = TEST_DIVDEU_DOT(20, 21, 22),
+ .flags = IGNORE_GPR(20),
+ .regs = {
+ .gpr[21] = LONG_MIN + 1,
+ .gpr[22] = LONG_MIN,
+ }
+ }
+ }
}
};
--
2.24.1
^ permalink raw reply related
* [PATCH 0/4] ocxl: Cleanup AFU interrupt allocation
From: Frederic Barrat @ 2020-04-02 15:43 UTC (permalink / raw)
To: linuxppc-dev, clg, christophe_lombard, ajd, ukrishn, mrochs; +Cc: haren, groug
Short series to cleanup AFU interrupt allocation for opencapi.
Current code was using its own allocation service, calling opal
directly to get the trigger page. This is not needed and we can use
xive to achieve the same thing. The only caveat is that the trigger
page address is only valid after the interrupt has been mapped, but
that is not a problem with the way the code is using it.
No functional change.
Frederic Barrat (4):
scsi: cxlflash: Access interrupt trigger page from xive directly
ocxl: Access interrupt trigger page from xive directly
ocxl: Don't return trigger page when allocating an interrupt
ocxl: Remove custom service to allocate interrupts
arch/powerpc/include/asm/pnv-ocxl.h | 3 ---
arch/powerpc/platforms/powernv/ocxl.c | 30 ---------------------------
drivers/misc/ocxl/Kconfig | 2 +-
drivers/misc/ocxl/afu_irq.c | 12 ++++++-----
drivers/misc/ocxl/link.c | 15 +++++++-------
drivers/scsi/cxlflash/ocxl_hw.c | 20 +++++++-----------
drivers/scsi/cxlflash/ocxl_hw.h | 1 -
include/misc/ocxl.h | 10 ++-------
8 files changed, 25 insertions(+), 68 deletions(-)
--
2.25.1
^ permalink raw reply
* [PATCH 3/4] ocxl: Don't return trigger page when allocating an interrupt
From: Frederic Barrat @ 2020-04-02 15:43 UTC (permalink / raw)
To: linuxppc-dev, clg, christophe_lombard, ajd, ukrishn, mrochs; +Cc: haren, groug
In-Reply-To: <20200402154352.586166-1-fbarrat@linux.ibm.com>
Existing users of ocxl_link_irq_alloc() have been converted to obtain
the trigger page of an interrupt through xive directly, we therefore
have no need to return the trigger page when allocating an interrupt.
It also allows ocxl to use the xive native interface to allocate
interrupts, instead of its custom service.
Signed-off-by: Frederic Barrat <fbarrat@linux.ibm.com>
---
drivers/misc/ocxl/Kconfig | 2 +-
drivers/misc/ocxl/afu_irq.c | 4 +---
drivers/misc/ocxl/link.c | 15 +++++++--------
drivers/scsi/cxlflash/ocxl_hw.c | 3 +--
include/misc/ocxl.h | 10 ++--------
5 files changed, 12 insertions(+), 22 deletions(-)
diff --git a/drivers/misc/ocxl/Kconfig b/drivers/misc/ocxl/Kconfig
index 2d2266c1439e..e65773f5cf59 100644
--- a/drivers/misc/ocxl/Kconfig
+++ b/drivers/misc/ocxl/Kconfig
@@ -9,7 +9,7 @@ config OCXL_BASE
config OCXL
tristate "OpenCAPI coherent accelerator support"
- depends on PPC_POWERNV && PCI && EEH
+ depends on PPC_POWERNV && PCI && EEH && PPC_XIVE_NATIVE
select OCXL_BASE
select HOTPLUG_PCI_POWERNV
default m
diff --git a/drivers/misc/ocxl/afu_irq.c b/drivers/misc/ocxl/afu_irq.c
index b30ec0ef7be7..ecdcfae025b7 100644
--- a/drivers/misc/ocxl/afu_irq.c
+++ b/drivers/misc/ocxl/afu_irq.c
@@ -11,7 +11,6 @@ struct afu_irq {
int hw_irq;
unsigned int virq;
char *name;
- u64 trigger_page;
irqreturn_t (*handler)(void *private);
void (*free_private)(void *private);
void *private;
@@ -125,8 +124,7 @@ int ocxl_afu_irq_alloc(struct ocxl_context *ctx, int *irq_id)
goto err_unlock;
}
- rc = ocxl_link_irq_alloc(ctx->afu->fn->link, &irq->hw_irq,
- &irq->trigger_page);
+ rc = ocxl_link_irq_alloc(ctx->afu->fn->link, &irq->hw_irq);
if (rc)
goto err_idr;
diff --git a/drivers/misc/ocxl/link.c b/drivers/misc/ocxl/link.c
index 58d111afd9f6..fd73d3bc0eb6 100644
--- a/drivers/misc/ocxl/link.c
+++ b/drivers/misc/ocxl/link.c
@@ -6,6 +6,7 @@
#include <linux/mmu_context.h>
#include <asm/copro.h>
#include <asm/pnv-ocxl.h>
+#include <asm/xive.h>
#include <misc/ocxl.h>
#include "ocxl_internal.h"
#include "trace.h"
@@ -682,23 +683,21 @@ int ocxl_link_remove_pe(void *link_handle, int pasid)
}
EXPORT_SYMBOL_GPL(ocxl_link_remove_pe);
-int ocxl_link_irq_alloc(void *link_handle, int *hw_irq, u64 *trigger_addr)
+int ocxl_link_irq_alloc(void *link_handle, int *hw_irq)
{
struct ocxl_link *link = (struct ocxl_link *) link_handle;
- int rc, irq;
- u64 addr;
+ int irq;
if (atomic_dec_if_positive(&link->irq_available) < 0)
return -ENOSPC;
- rc = pnv_ocxl_alloc_xive_irq(&irq, &addr);
- if (rc) {
+ irq = xive_native_alloc_irq();
+ if (!irq) {
atomic_inc(&link->irq_available);
- return rc;
+ return -ENXIO;
}
*hw_irq = irq;
- *trigger_addr = addr;
return 0;
}
EXPORT_SYMBOL_GPL(ocxl_link_irq_alloc);
@@ -707,7 +706,7 @@ void ocxl_link_free_irq(void *link_handle, int hw_irq)
{
struct ocxl_link *link = (struct ocxl_link *) link_handle;
- pnv_ocxl_free_xive_irq(hw_irq);
+ xive_native_free_irq(hw_irq);
atomic_inc(&link->irq_available);
}
EXPORT_SYMBOL_GPL(ocxl_link_free_irq);
diff --git a/drivers/scsi/cxlflash/ocxl_hw.c b/drivers/scsi/cxlflash/ocxl_hw.c
index 59452850f71c..03bff0cae658 100644
--- a/drivers/scsi/cxlflash/ocxl_hw.c
+++ b/drivers/scsi/cxlflash/ocxl_hw.c
@@ -613,7 +613,6 @@ static int alloc_afu_irqs(struct ocxlflash_context *ctx, int num)
struct ocxl_hw_afu *afu = ctx->hw_afu;
struct device *dev = afu->dev;
struct ocxlflash_irqs *irqs;
- u64 addr;
int rc = 0;
int hwirq;
int i;
@@ -638,7 +637,7 @@ static int alloc_afu_irqs(struct ocxlflash_context *ctx, int num)
}
for (i = 0; i < num; i++) {
- rc = ocxl_link_irq_alloc(afu->link_token, &hwirq, &addr);
+ rc = ocxl_link_irq_alloc(afu->link_token, &hwirq);
if (unlikely(rc)) {
dev_err(dev, "%s: ocxl_link_irq_alloc failed rc=%d\n",
__func__, rc);
diff --git a/include/misc/ocxl.h b/include/misc/ocxl.h
index 06dd5839e438..a2868adec22f 100644
--- a/include/misc/ocxl.h
+++ b/include/misc/ocxl.h
@@ -480,14 +480,8 @@ int ocxl_link_remove_pe(void *link_handle, int pasid);
* Allocate an AFU interrupt associated to the link.
*
* 'hw_irq' is the hardware interrupt number
- * 'obj_handle' is the 64-bit object handle to be passed to the AFU to
- * trigger the interrupt.
- * On P9, 'obj_handle' is an address, which, if written, triggers the
- * interrupt. It is an MMIO address which needs to be remapped (one
- * page).
- */
-int ocxl_link_irq_alloc(void *link_handle, int *hw_irq,
- u64 *obj_handle);
+ */
+int ocxl_link_irq_alloc(void *link_handle, int *hw_irq);
/*
* Free a previously allocated AFU interrupt
--
2.25.1
^ permalink raw reply related
* [PATCH 4/4] ocxl: Remove custom service to allocate interrupts
From: Frederic Barrat @ 2020-04-02 15:43 UTC (permalink / raw)
To: linuxppc-dev, clg, christophe_lombard, ajd, ukrishn, mrochs; +Cc: haren, groug
In-Reply-To: <20200402154352.586166-1-fbarrat@linux.ibm.com>
We now allocate interrupts through xive directly.
Signed-off-by: Frederic Barrat <fbarrat@linux.ibm.com>
---
arch/powerpc/include/asm/pnv-ocxl.h | 3 ---
arch/powerpc/platforms/powernv/ocxl.c | 30 ---------------------------
2 files changed, 33 deletions(-)
diff --git a/arch/powerpc/include/asm/pnv-ocxl.h b/arch/powerpc/include/asm/pnv-ocxl.h
index 7de82647e761..e90650328c9c 100644
--- a/arch/powerpc/include/asm/pnv-ocxl.h
+++ b/arch/powerpc/include/asm/pnv-ocxl.h
@@ -30,7 +30,4 @@ extern int pnv_ocxl_spa_setup(struct pci_dev *dev, void *spa_mem, int PE_mask,
extern void pnv_ocxl_spa_release(void *platform_data);
extern int pnv_ocxl_spa_remove_pe_from_cache(void *platform_data, int pe_handle);
-extern int pnv_ocxl_alloc_xive_irq(u32 *irq, u64 *trigger_addr);
-extern void pnv_ocxl_free_xive_irq(u32 irq);
-
#endif /* _ASM_PNV_OCXL_H */
diff --git a/arch/powerpc/platforms/powernv/ocxl.c b/arch/powerpc/platforms/powernv/ocxl.c
index 8c65aacda9c8..ecdad219d704 100644
--- a/arch/powerpc/platforms/powernv/ocxl.c
+++ b/arch/powerpc/platforms/powernv/ocxl.c
@@ -2,7 +2,6 @@
// Copyright 2017 IBM Corp.
#include <asm/pnv-ocxl.h>
#include <asm/opal.h>
-#include <asm/xive.h>
#include <misc/ocxl-config.h>
#include "pci.h"
@@ -484,32 +483,3 @@ int pnv_ocxl_spa_remove_pe_from_cache(void *platform_data, int pe_handle)
return rc;
}
EXPORT_SYMBOL_GPL(pnv_ocxl_spa_remove_pe_from_cache);
-
-int pnv_ocxl_alloc_xive_irq(u32 *irq, u64 *trigger_addr)
-{
- __be64 flags, trigger_page;
- s64 rc;
- u32 hwirq;
-
- hwirq = xive_native_alloc_irq();
- if (!hwirq)
- return -ENOENT;
-
- rc = opal_xive_get_irq_info(hwirq, &flags, NULL, &trigger_page, NULL,
- NULL);
- if (rc || !trigger_page) {
- xive_native_free_irq(hwirq);
- return -ENOENT;
- }
- *irq = hwirq;
- *trigger_addr = be64_to_cpu(trigger_page);
- return 0;
-
-}
-EXPORT_SYMBOL_GPL(pnv_ocxl_alloc_xive_irq);
-
-void pnv_ocxl_free_xive_irq(u32 irq)
-{
- xive_native_free_irq(irq);
-}
-EXPORT_SYMBOL_GPL(pnv_ocxl_free_xive_irq);
--
2.25.1
^ permalink raw reply related
* [PATCH 2/4] ocxl: Access interrupt trigger page from xive directly
From: Frederic Barrat @ 2020-04-02 15:43 UTC (permalink / raw)
To: linuxppc-dev, clg, christophe_lombard, ajd, ukrishn, mrochs; +Cc: haren, groug
In-Reply-To: <20200402154352.586166-1-fbarrat@linux.ibm.com>
We can access the trigger page through standard APIs so let's use it
and avoid saving it when allocating the interrupt. It will also allow
to simplify allocation in a later patch.
Signed-off-by: Frederic Barrat <fbarrat@linux.ibm.com>
---
drivers/misc/ocxl/afu_irq.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/misc/ocxl/afu_irq.c b/drivers/misc/ocxl/afu_irq.c
index 70f8f1c3929d..b30ec0ef7be7 100644
--- a/drivers/misc/ocxl/afu_irq.c
+++ b/drivers/misc/ocxl/afu_irq.c
@@ -2,6 +2,7 @@
// Copyright 2017 IBM Corp.
#include <linux/interrupt.h>
#include <asm/pnv-ocxl.h>
+#include <asm/xive.h>
#include "ocxl_internal.h"
#include "trace.h"
@@ -196,13 +197,16 @@ void ocxl_afu_irq_free_all(struct ocxl_context *ctx)
u64 ocxl_afu_irq_get_addr(struct ocxl_context *ctx, int irq_id)
{
+ struct xive_irq_data *xd;
struct afu_irq *irq;
u64 addr = 0;
mutex_lock(&ctx->irq_lock);
irq = idr_find(&ctx->irq_idr, irq_id);
- if (irq)
- addr = irq->trigger_page;
+ if (irq) {
+ xd = irq_get_handler_data(irq->virq);
+ addr = xd ? xd->trig_page : 0;
+ }
mutex_unlock(&ctx->irq_lock);
return addr;
}
--
2.25.1
^ permalink raw reply related
* [PATCH 1/4] scsi: cxlflash: Access interrupt trigger page from xive directly
From: Frederic Barrat @ 2020-04-02 15:43 UTC (permalink / raw)
To: linuxppc-dev, clg, christophe_lombard, ajd, ukrishn, mrochs; +Cc: haren, groug
In-Reply-To: <20200402154352.586166-1-fbarrat@linux.ibm.com>
xive is already mapping the trigger page in kernel space and it can be
accessed through standard APIs, so let's reuse it and simplify the code.
Signed-off-by: Frederic Barrat <fbarrat@linux.ibm.com>
---
drivers/scsi/cxlflash/ocxl_hw.c | 17 +++++++----------
drivers/scsi/cxlflash/ocxl_hw.h | 1 -
2 files changed, 7 insertions(+), 11 deletions(-)
diff --git a/drivers/scsi/cxlflash/ocxl_hw.c b/drivers/scsi/cxlflash/ocxl_hw.c
index 7018cd802569..59452850f71c 100644
--- a/drivers/scsi/cxlflash/ocxl_hw.c
+++ b/drivers/scsi/cxlflash/ocxl_hw.c
@@ -15,7 +15,8 @@
#include <linux/pseudo_fs.h>
#include <linux/poll.h>
#include <linux/sched/signal.h>
-
+#include <linux/interrupt.h>
+#include <asm/xive.h>
#include <misc/ocxl.h>
#include <uapi/misc/cxl.h>
@@ -180,7 +181,7 @@ static int afu_map_irq(u64 flags, struct ocxlflash_context *ctx, int num,
struct ocxl_hw_afu *afu = ctx->hw_afu;
struct device *dev = afu->dev;
struct ocxlflash_irqs *irq;
- void __iomem *vtrig;
+ struct xive_irq_data *xd;
u32 virq;
int rc = 0;
@@ -204,15 +205,14 @@ static int afu_map_irq(u64 flags, struct ocxlflash_context *ctx, int num,
goto err1;
}
- vtrig = ioremap(irq->ptrig, PAGE_SIZE);
- if (unlikely(!vtrig)) {
- dev_err(dev, "%s: Trigger page mapping failed\n", __func__);
- rc = -ENOMEM;
+ xd = irq_get_handler_data(virq);
+ if (unlikely(!xd)) {
+ dev_err(dev, "%s: Can't get interrupt data\n", __func__);
goto err2;
}
irq->virq = virq;
- irq->vtrig = vtrig;
+ irq->vtrig = xd->trig_mmio;
out:
return rc;
err2:
@@ -259,8 +259,6 @@ static void afu_unmap_irq(u64 flags, struct ocxlflash_context *ctx, int num,
}
irq = &ctx->irqs[num];
- if (irq->vtrig)
- iounmap(irq->vtrig);
if (irq_find_mapping(NULL, irq->hwirq)) {
free_irq(irq->virq, cookie);
@@ -648,7 +646,6 @@ static int alloc_afu_irqs(struct ocxlflash_context *ctx, int num)
}
irqs[i].hwirq = hwirq;
- irqs[i].ptrig = addr;
}
ctx->irqs = irqs;
diff --git a/drivers/scsi/cxlflash/ocxl_hw.h b/drivers/scsi/cxlflash/ocxl_hw.h
index fc6ad4f985de..f2fe88816bea 100644
--- a/drivers/scsi/cxlflash/ocxl_hw.h
+++ b/drivers/scsi/cxlflash/ocxl_hw.h
@@ -13,7 +13,6 @@
struct ocxlflash_irqs {
int hwirq;
u32 virq;
- u64 ptrig;
void __iomem *vtrig;
};
--
2.25.1
^ permalink raw reply related
* Re: [PATCH v2] sched/core: fix illegal RCU from offline CPUs
From: Paul E. McKenney @ 2020-04-02 15:54 UTC (permalink / raw)
To: Qian Cai
Cc: juri.lelli, James.Bottomley@hansenpartnership.com,
vincent.guittot, linux-parisc, Peter Zijlstra, deller,
Nicholas Piggin, linux-kernel, rostedt, bsegall, linux-mm,
Ingo Molnar, mgorman, tglx, linuxppc-dev, dietmar.eggemann
In-Reply-To: <C0F26F4C-77A0-41DF-856A-B7E29C56A4B6@lca.pw>
On Thu, Apr 02, 2020 at 10:00:16AM -0400, Qian Cai wrote:
>
>
> > On Apr 2, 2020, at 7:24 AM, Michael Ellerman <mpe@ellerman.id.au> wrote:
> >
> > Qian Cai <cai@lca.pw> writes:
> >> From: Peter Zijlstra <peterz@infradead.org>
> >>
> >> In the CPU-offline process, it calls mmdrop() after idle entry and the
> >> subsequent call to cpuhp_report_idle_dead(). Once execution passes the
> >> call to rcu_report_dead(), RCU is ignoring the CPU, which results in
> >> lockdep complaining when mmdrop() uses RCU from either memcg or
> >> debugobjects below.
> >>
> >> Fix it by cleaning up the active_mm state from BP instead. Every arch
> >> which has CONFIG_HOTPLUG_CPU should have already called idle_task_exit()
> >> from AP. The only exception is parisc because it switches them to
> >> &init_mm unconditionally (see smp_boot_one_cpu() and smp_cpu_init()),
> >> but the patch will still work there because it calls mmgrab(&init_mm) in
> >> smp_cpu_init() and then should call mmdrop(&init_mm) in finish_cpu().
> >
> > Thanks for debugging this. How did you hit it in the first place?
>
> Just repeatedly offline/online CPUs which will eventually cause an idle thread
> refcount goes to 0 and trigger __mmdrop() and of course it needs to enable
> lockdep (PROVE_RCU?) as well as having luck to hit the cgroup, workqueue
> or debugobject code paths to call RCU.
>
> >
> > A link to the original thread would have helped me:
> >
> > https://lore.kernel.org/lkml/20200113190331.12788-1-cai@lca.pw/
> >
> >> WARNING: suspicious RCU usage
> >> -----------------------------
> >> kernel/workqueue.c:710 RCU or wq_pool_mutex should be held!
> >>
> >> other info that might help us debug this:
> >>
> >> RCU used illegally from offline CPU!
> >> Call Trace:
> >> dump_stack+0xf4/0x164 (unreliable)
> >> lockdep_rcu_suspicious+0x140/0x164
> >> get_work_pool+0x110/0x150
> >> __queue_work+0x1bc/0xca0
> >> queue_work_on+0x114/0x120
> >> css_release+0x9c/0xc0
> >> percpu_ref_put_many+0x204/0x230
> >> free_pcp_prepare+0x264/0x570
> >> free_unref_page+0x38/0xf0
> >> __mmdrop+0x21c/0x2c0
> >> idle_task_exit+0x170/0x1b0
> >> pnv_smp_cpu_kill_self+0x38/0x2e0
> >> cpu_die+0x48/0x64
> >> arch_cpu_idle_dead+0x30/0x50
> >> do_idle+0x2f4/0x470
> >> cpu_startup_entry+0x38/0x40
> >> start_secondary+0x7a8/0xa80
> >> start_secondary_resume+0x10/0x14
> >
> > Do we know when this started happening? ie. can we determine a Fixes
> > tag?
>
> I don’t know. I looked at some commits that it seems the code was like that
> even 10-year ago. It must be nobody who cares to run lockdep (PROVE_RCU?)
> with CPU hotplug very regularly.
I do run this combination quite frequently, but only as part of
rcutorture, which might not be a representative workload. For one thing,
it has a minimal userspace consisting only of a trivial init program.
I don't recall having ever seen this. (I have seen one recent complaint
about an IPI being sent to an offline CPU, but I cannot prove that this
was not due to RCU bugs that I was chasing at the time.)
Thanx, Paul
> >> <Peter to sign off here>
> >> Signed-off-by: Qian Cai <cai@lca.pw>
> >> ---
> >> arch/powerpc/platforms/powernv/smp.c | 1 -
> >> include/linux/sched/mm.h | 2 ++
> >> kernel/cpu.c | 18 +++++++++++++++++-
> >> kernel/sched/core.c | 5 +++--
> >> 4 files changed, 22 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/arch/powerpc/platforms/powernv/smp.c b/arch/powerpc/platforms/powernv/smp.c
> >> index 13e251699346..b2ba3e95bda7 100644
> >> --- a/arch/powerpc/platforms/powernv/smp.c
> >> +++ b/arch/powerpc/platforms/powernv/smp.c
> >> @@ -167,7 +167,6 @@ static void pnv_smp_cpu_kill_self(void)
> >> /* Standard hot unplug procedure */
> >>
> >> idle_task_exit();
> >> - current->active_mm = NULL; /* for sanity */
> >
> > If I'm reading it right, we'll now be running with active_mm == init_mm
> > in the offline loop.
> >
> > I guess that's fine, I can't think of any reason it would matter, and it
> > seems like we were NULL'ing it out just for paranoia's sake not because
> > of any actual problem.
> >
> > Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
> >
> >
> > cheers
> >
> >> diff --git a/include/linux/sched/mm.h b/include/linux/sched/mm.h
> >> index c49257a3b510..a132d875d351 100644
> >> --- a/include/linux/sched/mm.h
> >> +++ b/include/linux/sched/mm.h
> >> @@ -49,6 +49,8 @@ static inline void mmdrop(struct mm_struct *mm)
> >> __mmdrop(mm);
> >> }
> >>
> >> +void mmdrop(struct mm_struct *mm);
> >> +
> >> /*
> >> * This has to be called after a get_task_mm()/mmget_not_zero()
> >> * followed by taking the mmap_sem for writing before modifying the
> >> diff --git a/kernel/cpu.c b/kernel/cpu.c
> >> index 2371292f30b0..244d30544377 100644
> >> --- a/kernel/cpu.c
> >> +++ b/kernel/cpu.c
> >> @@ -3,6 +3,7 @@
> >> *
> >> * This code is licenced under the GPL.
> >> */
> >> +#include <linux/sched/mm.h>
> >> #include <linux/proc_fs.h>
> >> #include <linux/smp.h>
> >> #include <linux/init.h>
> >> @@ -564,6 +565,21 @@ static int bringup_cpu(unsigned int cpu)
> >> return bringup_wait_for_ap(cpu);
> >> }
> >>
> >> +static int finish_cpu(unsigned int cpu)
> >> +{
> >> + struct task_struct *idle = idle_thread_get(cpu);
> >> + struct mm_struct *mm = idle->active_mm;
> >> +
> >> + /*
> >> + * idle_task_exit() will have switched to &init_mm, now
> >> + * clean up any remaining active_mm state.
> >> + */
> >> + if (mm != &init_mm)
> >> + idle->active_mm = &init_mm;
> >> + mmdrop(mm);
> >> + return 0;
> >> +}
> >> +
> >> /*
> >> * Hotplug state machine related functions
> >> */
> >> @@ -1549,7 +1565,7 @@ static struct cpuhp_step cpuhp_hp_states[] = {
> >> [CPUHP_BRINGUP_CPU] = {
> >> .name = "cpu:bringup",
> >> .startup.single = bringup_cpu,
> >> - .teardown.single = NULL,
> >> + .teardown.single = finish_cpu,
> >> .cant_stop = true,
> >> },
> >> /* Final state before CPU kills itself */
> >> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> >> index a2694ba82874..8787958339d5 100644
> >> --- a/kernel/sched/core.c
> >> +++ b/kernel/sched/core.c
> >> @@ -6200,13 +6200,14 @@ void idle_task_exit(void)
> >> struct mm_struct *mm = current->active_mm;
> >>
> >> BUG_ON(cpu_online(smp_processor_id()));
> >> + BUG_ON(current != this_rq()->idle);
> >>
> >> if (mm != &init_mm) {
> >> switch_mm(mm, &init_mm, current);
> >> - current->active_mm = &init_mm;
> >> finish_arch_post_lock_switch();
> >> }
> >> - mmdrop(mm);
> >> +
> >> + /* finish_cpu(), as ran on the BP, will clean up the active_mm state */
> >> }
> >>
> >> /*
> >> --
> >> 2.21.0 (Apple Git-122.2)
>
^ permalink raw reply
* Re: [PATCH v8 2/7] powerpc/kprobes: Mark newly allocated probes as RO
From: Naveen N. Rao @ 2020-04-02 16:16 UTC (permalink / raw)
To: linuxppc-dev, Russell Currey; +Cc: kernel-hardening, ajd, npiggin, dja
In-Reply-To: <20200402084053.188537-2-ruscur@russell.cc>
Russell Currey wrote:
> With CONFIG_STRICT_KERNEL_RWX=y and CONFIG_KPROBES=y, there will be one
> W+X page at boot by default. This can be tested with
> CONFIG_PPC_PTDUMP=y and CONFIG_PPC_DEBUG_WX=y set, and checking the
> kernel log during boot.
>
> powerpc doesn't implement its own alloc() for kprobes like other
> architectures do, but we couldn't immediately mark RO anyway since we do
> a memcpy to the page we allocate later. After that, nothing should be
> allowed to modify the page, and write permissions are removed well
> before the kprobe is armed.
>
> The memcpy() would fail if >1 probes were allocated, so use
> patch_instruction() instead which is safe for RO.
>
> Reviewed-by: Daniel Axtens <dja@axtens.net>
> Signed-off-by: Russell Currey <ruscur@russell.cc>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
> ---
> arch/powerpc/kernel/kprobes.c | 17 +++++++++++++----
> 1 file changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/arch/powerpc/kernel/kprobes.c b/arch/powerpc/kernel/kprobes.c
> index 81efb605113e..fa4502b4de35 100644
> --- a/arch/powerpc/kernel/kprobes.c
> +++ b/arch/powerpc/kernel/kprobes.c
> @@ -24,6 +24,8 @@
> #include <asm/sstep.h>
> #include <asm/sections.h>
> #include <linux/uaccess.h>
> +#include <linux/set_memory.h>
> +#include <linux/vmalloc.h>
>
> DEFINE_PER_CPU(struct kprobe *, current_kprobe) = NULL;
> DEFINE_PER_CPU(struct kprobe_ctlblk, kprobe_ctlblk);
> @@ -102,6 +104,16 @@ kprobe_opcode_t *kprobe_lookup_name(const char *name, unsigned int offset)
> return addr;
> }
>
> +void *alloc_insn_page(void)
> +{
> + void *page = vmalloc_exec(PAGE_SIZE);
> +
> + if (page)
> + set_memory_ro((unsigned long)page, 1);
> +
> + return page;
> +}
> +
This crashes for me with KPROBES_SANITY_TEST during the kretprobe test.
It seems to be handling the kretprobe itself properly, but seems to
crash on the return path. I haven't yet been able to work out what's
going wrong.
[ 0.517880] Kprobe smoke test: started
[ 0.626680] Oops: Exception in kernel mode, sig: 4 [#1]
[ 0.626708] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA PowerNV
[ 0.626735] Modules linked in:
[ 0.626760] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.6.0-06592-g2e64694b9137 #51
[ 0.626795] NIP: c008000000020000 LR: c00000000021ce34 CTR: c00000000021c5f8
[ 0.626829] REGS: c0000000fd3e3860 TRAP: 0e40 Not tainted (5.6.0-06592-g2e64694b9137)
[ 0.626862] MSR: 9000000002089433 <SF,HV,VEC,EE,ME,SE,IR,DR,RI,LE> CR: 28000284 XER: 00040000
[ 0.626922] CFAR: c00000000000ef20 IRQMASK: 0
[ 0.626922] GPR00: c000000000052250 c0000000fd3e3af0 c000000002330200 000000002db8ad86
[ 0.626922] GPR04: 0000000000000000 c00000000006ba3c 0000000000000800 c0000000fd3a0000
[ 0.626922] GPR08: 0000000000000000 ffffffffaaaaaaab c0000000fd3a0000 0000000040000000
[ 0.626922] GPR12: c00000000021c5f0 c000000002520000 c000000000011790 0000000000000000
[ 0.626922] GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 0.626922] GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 0.626922] GPR24: c0000000020034bc c0000000012068b8 c000000002062e50 c0000000fd2319a0
[ 0.626922] GPR28: c000000000f5ebb0 0000000000000000 c0000000021bc278 c000000002458540
[ 0.627234] NIP [c008000000020000] 0xc008000000020000
[ 0.627264] LR [c00000000021ce34] init_test_probes+0x424/0x560
[ 0.627291] Call Trace:
[ 0.627313] [c0000000fd3e3af0] [c00000000021ce34] init_test_probes+0x424/0x560 (unreliable)
[ 0.627356] [c0000000fd3e3b90] [c00000000202de2c] init_kprobes+0x1a8/0x1c8
[ 0.627392] [c0000000fd3e3c00] [c000000000011140] do_one_initcall+0x60/0x2b0
[ 0.627432] [c0000000fd3e3cd0] [c000000002004674] kernel_init_freeable+0x2e0/0x3a0
[ 0.627471] [c0000000fd3e3db0] [c0000000000117ac] kernel_init+0x24/0x178
[ 0.627510] [c0000000fd3e3e20] [c00000000000c7a8] ret_from_kernel_thread+0x5c/0x74
[ 0.627543] Instruction dump:
[ 0.627562] XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
[ 0.627607] XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX <00000000> 00000000 00000000 00000000
[ 0.627660] ---[ end trace 964ab92781f5d99d ]---
[ 0.629607]
- Naveen
^ permalink raw reply
* Re: [PATCH v2] sched/core: fix illegal RCU from offline CPUs
From: Qian Cai @ 2020-04-02 16:19 UTC (permalink / raw)
To: paulmck
Cc: juri.lelli, James.Bottomley@hansenpartnership.com,
vincent.guittot, linux-parisc, Peter Zijlstra, deller,
Nicholas Piggin, linux-kernel, rostedt, bsegall, linux-mm,
Ingo Molnar, mgorman, tglx, linuxppc-dev, dietmar.eggemann
In-Reply-To: <20200402155406.GP19865@paulmck-ThinkPad-P72>
> On Apr 2, 2020, at 11:54 AM, Paul E. McKenney <paulmck@kernel.org> wrote:
>
> I do run this combination quite frequently, but only as part of
> rcutorture, which might not be a representative workload. For one thing,
> it has a minimal userspace consisting only of a trivial init program.
> I don't recall having ever seen this. (I have seen one recent complaint
> about an IPI being sent to an offline CPU, but I cannot prove that this
> was not due to RCU bugs that I was chasing at the time.)
Yes, a trivial init is tough while running systemd should be able to catch it as it will use cgroup.
^ permalink raw reply
* Re: [PATCH RESEND 1/4] uaccess: Add user_read_access_begin/end and user_write_access_begin/end
From: Al Viro @ 2020-04-02 16:29 UTC (permalink / raw)
To: Christophe Leroy
Cc: linux-arch, linuxppc-dev, keescook, Christian Borntraeger,
airlied, hpa, linux-kernel, Russell King, linux-mm,
Paul Mackerras, daniel, akpm, torvalds
In-Reply-To: <27106d62fdbd4ffb47796236050e418131cb837f.1585811416.git.christophe.leroy@c-s.fr>
On Thu, Apr 02, 2020 at 07:34:16AM +0000, Christophe Leroy wrote:
> Some architectures like powerpc64 have the capability to separate
> read access and write access protection.
> For get_user() and copy_from_user(), powerpc64 only open read access.
> For put_user() and copy_to_user(), powerpc64 only open write access.
> But when using unsafe_get_user() or unsafe_put_user(),
> user_access_begin open both read and write.
>
> Other architectures like powerpc book3s 32 bits only allow write
> access protection. And on this architecture protection is an heavy
> operation as it requires locking/unlocking per segment of 256Mbytes.
> On those architecture it is therefore desirable to do the unlocking
> only for write access. (Note that book3s/32 ranges from very old
> powermac from the 90's with powerpc 601 processor, till modern
> ADSL boxes with PowerQuicc II modern processors for instance so it
> is still worth considering)
>
> In order to avoid any risk based of hacking some variable parameters
> passed to user_access_begin/end that would allow hacking and
> leaving user access open or opening too much, it is preferable to
> use dedicated static functions that can't be overridden.
>
> Add a user_read_access_begin and user_read_access_end to only open
> read access.
>
> Add a user_write_access_begin and user_write_access_end to only open
> write access.
>
> By default, when undefined, those new access helpers default on the
> existing user_access_begin and user_access_end.
The only problem I have is that we'd better choose the calling
conventions that work for other architectures as well.
AFAICS, aside of ppc and x86 we have (at least) this:
arm:
unsigned int __ua_flags = uaccess_save_and_enable();
...
uaccess_restore(__ua_flags);
arm64:
uaccess_enable_not_uao();
...
uaccess_disable_not_uao();
riscv:
__enable_user_access();
...
__disable_user_access();
s390/mvc:
old_fs = enable_sacf_uaccess();
...
disable_sacf_uaccess(old_fs);
arm64 and riscv are easy - they map well on what we have now.
The interesting ones are ppc, arm and s390.
You wants to specify the kind of access; OK, but... it's not just read
vs. write - there's read-write as well. AFAICS, there are 3 users of
that:
* copy_in_user()
* arch_futex_atomic_op_inuser()
* futex_atomic_cmpxchg_inatomic()
The former is of dubious utility (all users outside of arch are in
the badly done compat code), but the other two are not going to go
away.
What should we do about that? Do we prohibit such blocks outside
of arch?
What should we do about arm and s390? There we want a cookie passed
from beginning of block to its end; should that be a return value?
And at least on arm that thing nests (see e.g. __clear_user_memset()
there), so "stash that cookie in current->something" is not a solution...
Folks, let's sort that out while we still have few users of that
interface; changing the calling conventions later will be much harder.
Comments?
^ permalink raw reply
* Re: [PATCH v2] sched/core: fix illegal RCU from offline CPUs
From: Paul E. McKenney @ 2020-04-02 16:57 UTC (permalink / raw)
To: Qian Cai
Cc: juri.lelli, James.Bottomley@hansenpartnership.com,
vincent.guittot, linux-parisc, Peter Zijlstra, deller,
Nicholas Piggin, linux-kernel, rostedt, bsegall, linux-mm,
Ingo Molnar, mgorman, tglx, linuxppc-dev, dietmar.eggemann
In-Reply-To: <4134872A-3D1D-4860-9C1B-2FD9C00272BB@lca.pw>
On Thu, Apr 02, 2020 at 12:19:54PM -0400, Qian Cai wrote:
>
>
> > On Apr 2, 2020, at 11:54 AM, Paul E. McKenney <paulmck@kernel.org> wrote:
> >
> > I do run this combination quite frequently, but only as part of
> > rcutorture, which might not be a representative workload. For one thing,
> > it has a minimal userspace consisting only of a trivial init program.
> > I don't recall having ever seen this. (I have seen one recent complaint
> > about an IPI being sent to an offline CPU, but I cannot prove that this
> > was not due to RCU bugs that I was chasing at the time.)
>
> Yes, a trivial init is tough while running systemd should be able to catch it as it will use cgroup.
Not planning to add systemd to my rcutorture runs. ;-)
Thanx, 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