June 2023 - Linux-stable-mirror

[tip: x86/core] x86/smp: Use dedicated cache-line for mwait_play_dead()

by tip-bot2 for Thomas Gleixner

The following commit has been merged into the x86/core branch of tip: Commit-ID: f9c9987bf52f4e42e940ae217333ebb5a4c3b506 Gitweb: https://git.kernel.org/tip/f9c9987bf52f4e42e940ae217333ebb5a4c3b506 Author: Thomas Gleixner <tglx(a)linutronix.de> AuthorDate: Thu, 15 Jun 2023 22:33:55 +02:00 Committer: Thomas Gleixner <tglx(a)linutronix.de> CommitterDate: Tue, 20 Jun 2023 14:51:47 +02:00 x86/smp: Use dedicated cache-line for mwait_play_dead() Monitoring idletask::thread_info::flags in mwait_play_dead() has been an obvious choice as all what is needed is a cache line which is not written by other CPUs. But there is a use case where a "dead" CPU needs to be brought out of MWAIT: kexec(). This is required as kexec() can overwrite text, pagetables, stacks and the monitored cacheline of the original kernel. The latter causes MWAIT to resume execution which obviously causes havoc on the kexec kernel which results usually in triple faults. Use a dedicated per CPU storage to prepare for that. Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Reviewed-by: Ashok Raj <ashok.raj(a)intel.com> Reviewed-by: Borislav Petkov (AMD) <bp(a)alien8.de> Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/r/20230615193330.434553750@linutronix.de --- arch/x86/kernel/smpboot.c | 24 ++++++++++++++---------- 1 file changed, 14 insertions(+), 10 deletions(-) diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c index 352f0ce..c5ac5d7 100644 --- a/arch/x86/kernel/smpboot.c +++ b/arch/x86/kernel/smpboot.c @@ -101,6 +101,17 @@ EXPORT_PER_CPU_SYMBOL(cpu_die_map); DEFINE_PER_CPU_READ_MOSTLY(struct cpuinfo_x86, cpu_info); EXPORT_PER_CPU_SYMBOL(cpu_info); +struct mwait_cpu_dead { + unsigned int control; + unsigned int status; +}; + +/* + * Cache line aligned data for mwait_play_dead(). Separate on purpose so + * that it's unlikely to be touched by other CPUs. + */ +static DEFINE_PER_CPU_ALIGNED(struct mwait_cpu_dead, mwait_cpu_dead); + /* Logical package management. We might want to allocate that dynamically */ unsigned int __max_logical_packages __read_mostly; EXPORT_SYMBOL(__max_logical_packages); @@ -1758,10 +1769,10 @@ EXPORT_SYMBOL_GPL(cond_wakeup_cpu0); */ static inline void mwait_play_dead(void) { + struct mwait_cpu_dead *md = this_cpu_ptr(&mwait_cpu_dead); unsigned int eax, ebx, ecx, edx; unsigned int highest_cstate = 0; unsigned int highest_subcstate = 0; - void *mwait_ptr; int i; if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD || @@ -1796,13 +1807,6 @@ static inline void mwait_play_dead(void) (highest_subcstate - 1); } - /* - * This should be a memory location in a cache line which is - * unlikely to be touched by other processors. The actual - * content is immaterial as it is not actually modified in any way. - */ - mwait_ptr = &current_thread_info()->flags; - wbinvd(); while (1) { @@ -1814,9 +1818,9 @@ static inline void mwait_play_dead(void) * case where we return around the loop. */ mb(); - clflush(mwait_ptr); + clflush(md); mb(); - __monitor(mwait_ptr, 0, 0); + __monitor(md, 0, 0); mb(); __mwait(eax, 0);

1 year, 6 months

1
0
0 0

[tip: x86/core] x86/smp: Cure kexec() vs. mwait_play_dead() breakage

by tip-bot2 for Thomas Gleixner

The following commit has been merged into the x86/core branch of tip: Commit-ID: d7893093a7417527c0d73c9832244e65c9d0114f Gitweb: https://git.kernel.org/tip/d7893093a7417527c0d73c9832244e65c9d0114f Author: Thomas Gleixner <tglx(a)linutronix.de> AuthorDate: Thu, 15 Jun 2023 22:33:57 +02:00 Committer: Thomas Gleixner <tglx(a)linutronix.de> CommitterDate: Tue, 20 Jun 2023 14:51:47 +02:00 x86/smp: Cure kexec() vs. mwait_play_dead() breakage TLDR: It's a mess. When kexec() is executed on a system with offline CPUs, which are parked in mwait_play_dead() it can end up in a triple fault during the bootup of the kexec kernel or cause hard to diagnose data corruption. The reason is that kexec() eventually overwrites the previous kernel's text, page tables, data and stack. If it writes to the cache line which is monitored by a previously offlined CPU, MWAIT resumes execution and ends up executing the wrong text, dereferencing overwritten page tables or corrupting the kexec kernels data. Cure this by bringing the offlined CPUs out of MWAIT into HLT. Write to the monitored cache line of each offline CPU, which makes MWAIT resume execution. The written control word tells the offlined CPUs to issue HLT, which does not have the MWAIT problem. That does not help, if a stray NMI, MCE or SMI hits the offlined CPUs as those make it come out of HLT. A follow up change will put them into INIT, which protects at least against NMI and SMI. Fixes: ea53069231f9 ("x86, hotplug: Use mwait to offline a processor, fix the legacy case") Reported-by: Ashok Raj <ashok.raj(a)intel.com> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Tested-by: Ashok Raj <ashok.raj(a)intel.com> Reviewed-by: Ashok Raj <ashok.raj(a)intel.com> Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/r/20230615193330.492257119@linutronix.de --- arch/x86/include/asm/smp.h | 2 +- arch/x86/kernel/smp.c | 5 +++- arch/x86/kernel/smpboot.c | 59 +++++++++++++++++++++++++++++++++++++- 3 files changed, 66 insertions(+) diff --git a/arch/x86/include/asm/smp.h b/arch/x86/include/asm/smp.h index 4e91054..d4ce5cb 100644 --- a/arch/x86/include/asm/smp.h +++ b/arch/x86/include/asm/smp.h @@ -132,6 +132,8 @@ void wbinvd_on_cpu(int cpu); int wbinvd_on_all_cpus(void); void cond_wakeup_cpu0(void); +void smp_kick_mwait_play_dead(void); + void native_smp_send_reschedule(int cpu); void native_send_call_func_ipi(const struct cpumask *mask); void native_send_call_func_single_ipi(int cpu); diff --git a/arch/x86/kernel/smp.c b/arch/x86/kernel/smp.c index d842875..174d623 100644 --- a/arch/x86/kernel/smp.c +++ b/arch/x86/kernel/smp.c @@ -21,6 +21,7 @@ #include <linux/interrupt.h> #include <linux/cpu.h> #include <linux/gfp.h> +#include <linux/kexec.h> #include <asm/mtrr.h> #include <asm/tlbflush.h> @@ -157,6 +158,10 @@ static void native_stop_other_cpus(int wait) if (atomic_cmpxchg(&stopping_cpu, -1, cpu) != -1) return; + /* For kexec, ensure that offline CPUs are out of MWAIT and in HLT */ + if (kexec_in_progress) + smp_kick_mwait_play_dead(); + /* * 1) Send an IPI on the reboot vector to all other CPUs. * diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c index c5ac5d7..483df04 100644 --- a/arch/x86/kernel/smpboot.c +++ b/arch/x86/kernel/smpboot.c @@ -53,6 +53,7 @@ #include <linux/tboot.h> #include <linux/gfp.h> #include <linux/cpuidle.h> +#include <linux/kexec.h> #include <linux/numa.h> #include <linux/pgtable.h> #include <linux/overflow.h> @@ -106,6 +107,9 @@ struct mwait_cpu_dead { unsigned int status; }; +#define CPUDEAD_MWAIT_WAIT 0xDEADBEEF +#define CPUDEAD_MWAIT_KEXEC_HLT 0x4A17DEAD + /* * Cache line aligned data for mwait_play_dead(). Separate on purpose so * that it's unlikely to be touched by other CPUs. @@ -173,6 +177,10 @@ static void smp_callin(void) { int cpuid; + /* Mop up eventual mwait_play_dead() wreckage */ + this_cpu_write(mwait_cpu_dead.status, 0); + this_cpu_write(mwait_cpu_dead.control, 0); + /* * If waken up by an INIT in an 82489DX configuration * cpu_callout_mask guarantees we don't get here before @@ -1807,6 +1815,10 @@ static inline void mwait_play_dead(void) (highest_subcstate - 1); } + /* Set up state for the kexec() hack below */ + md->status = CPUDEAD_MWAIT_WAIT; + md->control = CPUDEAD_MWAIT_WAIT; + wbinvd(); while (1) { @@ -1824,10 +1836,57 @@ static inline void mwait_play_dead(void) mb(); __mwait(eax, 0); + if (READ_ONCE(md->control) == CPUDEAD_MWAIT_KEXEC_HLT) { + /* + * Kexec is about to happen. Don't go back into mwait() as + * the kexec kernel might overwrite text and data including + * page tables and stack. So mwait() would resume when the + * monitor cache line is written to and then the CPU goes + * south due to overwritten text, page tables and stack. + * + * Note: This does _NOT_ protect against a stray MCE, NMI, + * SMI. They will resume execution at the instruction + * following the HLT instruction and run into the problem + * which this is trying to prevent. + */ + WRITE_ONCE(md->status, CPUDEAD_MWAIT_KEXEC_HLT); + while(1) + native_halt(); + } + cond_wakeup_cpu0(); } } +/* + * Kick all "offline" CPUs out of mwait on kexec(). See comment in + * mwait_play_dead(). + */ +void smp_kick_mwait_play_dead(void) +{ + u32 newstate = CPUDEAD_MWAIT_KEXEC_HLT; + struct mwait_cpu_dead *md; + unsigned int cpu, i; + + for_each_cpu_andnot(cpu, cpu_present_mask, cpu_online_mask) { + md = per_cpu_ptr(&mwait_cpu_dead, cpu); + + /* Does it sit in mwait_play_dead() ? */ + if (READ_ONCE(md->status) != CPUDEAD_MWAIT_WAIT) + continue; + + /* Wait up to 5ms */ + for (i = 0; READ_ONCE(md->status) != newstate && i < 1000; i++) { + /* Bring it out of mwait */ + WRITE_ONCE(md->control, newstate); + udelay(5); + } + + if (READ_ONCE(md->status) != newstate) + pr_err_once("CPU%u is stuck in mwait_play_dead()\n", cpu); + } +} + void __noreturn hlt_play_dead(void) { if (__this_cpu_read(cpu_info.x86) >= 4)

1 year, 6 months

1
0
0 0

[PATCH 1/6] amd-pstate: Make amd-pstate epp driver name hyphenated

by Wyes Karny

amd-pstate passive mode driver is hyphenated. So make amd-pstate active mode driver consistent with that rename "amd_pstate_epp" to "amd-pstate-epp". Cc: stable(a)vger.kernel.org Fixes: ffa5096a7c33 ("cpufreq: amd-pstate: implement Pstate EPP support for the AMD processors") Reviewed-by: Gautham R. Shenoy <gautham.shenoy(a)amd.com> Signed-off-by: Wyes Karny <wyes.karny(a)amd.com> --- drivers/cpufreq/amd-pstate.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/cpufreq/amd-pstate.c b/drivers/cpufreq/amd-pstate.c index ddd346a239e0..a5764946434c 100644 --- a/drivers/cpufreq/amd-pstate.c +++ b/drivers/cpufreq/amd-pstate.c @@ -1356,7 +1356,7 @@ static struct cpufreq_driver amd_pstate_epp_driver = { .online = amd_pstate_epp_cpu_online, .suspend = amd_pstate_epp_suspend, .resume = amd_pstate_epp_resume, - .name = "amd_pstate_epp", + .name = "amd-pstate-epp", .attr = amd_pstate_epp_attr, }; -- 2.34.1

1 year, 6 months

4
8
0 0

IPMI related kernel panics since v4.19.286

by Janne Huttunen (Nokia)

We recently updated an internal test server from kernel v4.19.273 to v4.19.286 and since then it has already multiple times triggered a kernel panic due to a hard lockup. The lockups look e.g. like this: [29397.950589] RIP: 0010:native_queued_spin_lock_slowpath+0x57/0x190 [29397.950590] Code: 74 38 81 e6 00 ff ff ff 75 60 f0 0f ba 2f 08 8b 07 72 57 89 c2 30 e6 a9 00 00 ff ff 75 48 85 d2 74 0e 8b 07 84 c0 74 08 f3 90 <8b> 07 84 c0 75 f8 b8 01 00 00 00 5d 66 89 07 c3 8b 37 81 fe 00 01 [29397.950591] RSP: 0000:ffff93d07f703de8 EFLAGS: 00000002 [29397.950591] RAX: 0000000000000101 RBX: ffff93cf90087220 RCX: 0000000000000006 [29397.950592] RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff93cf90087220 [29397.950592] RBP: ffff93d07f703de8 R08: 0000000000000000 R09: ffff93d07f71fb70 [29397.950593] R10: ffff93d07f71fb28 R11: ffff93d07f703ee8 R12: 0000000000000002 [29397.950593] R13: ffff93cf852cde58 R14: ffff93cf852cc000 R15: 0000000000000003 [29397.950594] ? native_queued_spin_lock_slowpath+0x57/0x190 [29397.950594] ? native_queued_spin_lock_slowpath+0x57/0x190 [29397.950594] </NMI> [29397.950595] <IRQ> [29397.950595] _raw_spin_lock_irqsave+0x46/0x50 [29397.950595] set_need_watch+0x2d/0x70 [ipmi_si] [29397.950596] ? _raw_spin_lock_irqsave+0x25/0x50 [29397.950596] ipmi_timeout+0x2b4/0x530 [ipmi_msghandler] [29397.950597] ? ipmi_set_gets_events+0x260/0x260 [ipmi_msghandler] [29397.950597] call_timer_fn+0x30/0x130 [29397.950597] ? ipmi_set_gets_events+0x260/0x260 [ipmi_msghandler] [29397.950598] run_timer_softirq+0x1ce/0x3f0 [29397.950598] ? ktime_get+0x40/0xa0 [29397.950598] ? sched_clock+0x9/0x10 [29397.950599] ? sched_clock_cpu+0x11/0xc0 [29397.950599] __do_softirq+0x104/0x32d [29397.950600] ? sched_clock_cpu+0x11/0xc0 [29397.950600] irq_exit+0x11b/0x120 [29397.950600] smp_apic_timer_interrupt+0x79/0x140 [29397.950601] apic_timer_interrupt+0xf/0x20 [29397.950601] </IRQ> And like this: [16944.269585] RIP: 0010:native_queued_spin_lock_slowpath+0x57/0x190 [16944.269586] Code: 74 38 81 e6 00 ff ff ff 75 60 f0 0f ba 2f 08 8b 07 72 57 89 c2 30 e6 a9 00 00 ff ff 75 48 85 d2 74 0e 8b 07 84 c0 74 08 f3 90 <8b> 07 84 c0 75 f8 b8 01 00 00 00 5d 66 89 07 c3 8b 37 81 fe 00 01 [16944.269587] RSP: 0018:ffff9a4e40b03dd0 EFLAGS: 00000002 [16944.269588] RAX: 0000000000580101 RBX: ffff9a4ac5089e98 RCX: ffff9a2b9574b538 [16944.269588] RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff9a4ac5089e98 [16944.269589] RBP: ffff9a4e40b03dd0 R08: ffff9a4ac5089e58 R09: ffff9a4e40b1fb70 [16944.269589] R10: ffff9a4e40b1fb28 R11: ffff9a4e40b03ee8 R12: 0000000000000002 [16944.269590] R13: ffff9a4ac5089e98 R14: ffff9a4ac5089e58 R15: ffff9a4ac5089e54 [16944.269590] ? native_queued_spin_lock_slowpath+0x57/0x190 [16944.269591] ? native_queued_spin_lock_slowpath+0x57/0x190 [16944.269591] </NMI> [16944.269592] <IRQ> [16944.269592] _raw_spin_lock_irqsave+0x46/0x50 [16944.269592] ipmi_smi_msg_received+0x1bc/0x300 [ipmi_msghandler] [16944.269593] smi_event_handler+0x26c/0x650 [ipmi_si] [16944.269593] smi_timeout+0x46/0xc0 [ipmi_si] [16944.269594] ? ipmi_si_irq_handler+0x70/0x70 [ipmi_si] [16944.269594] call_timer_fn+0x30/0x130 [16944.269595] ? ipmi_si_irq_handler+0x70/0x70 [ipmi_si] [16944.269595] run_timer_softirq+0x1ce/0x3f0 [16944.269595] ? ktime_get+0x40/0xa0 [16944.269596] ? sched_clock+0x9/0x10 [16944.269596] ? sched_clock_cpu+0x11/0xc0 [16944.269597] __do_softirq+0x104/0x32d [16944.269597] ? sched_clock_cpu+0x11/0xc0 [16944.269597] irq_exit+0x11b/0x120 [16944.269598] smp_apic_timer_interrupt+0x79/0x140 [16944.269598] apic_timer_interrupt+0xf/0x20 [16944.269599] </IRQ> To me these would look like an ordering violation between "smi_info->si_lock" and "intf->xmit_msgs_lock", probably introduced by this commit: commit b4a34aa6dfbca67610e56ad84a3595f537c85af9 Author: Corey Minyard <cminyard(a)mvista.com> Date: Tue Oct 23 11:29:02 2018 -0500 ipmi: Fix how the lower layers are told to watch for messages [ Upstream commit c65ea996595005be470fbfa16711deba414fd33b ] In order to test the theory further I built and booted a kernel with lockdep and this happened: [ 215.679605] kipmi0/1465 is trying to acquire lock: [ 215.684490] 00000000fc1528d3 (&(&new_smi->si_lock)->rlock){..-.}, at: set_need_watch+0x2d/0x70 [ipmi_si] [ 215.694073] but task is already holding lock: [ 215.699995] 00000000e2eea01c (&(&intf->xmit_msgs_lock)->rlock){..-.}, at: smi_recv_tasklet+0x170/0x260 [ipmi_msghandler] [ 215.710966] which lock already depends on the new lock. [ 215.719243] the existing dependency chain (in reverse order) is: [ 215.726824] -> #1 (&(&intf->xmit_msgs_lock)->rlock){..-.}: [ 215.733890] lock_acquire+0xae/0x180 [ 215.738111] _raw_spin_lock_irqsave+0x4d/0x8a [ 215.743113] ipmi_smi_msg_received+0x1bc/0x300 [ipmi_msghandler] [ 215.749766] smi_event_handler+0x26c/0x660 [ipmi_si] [ 215.755378] ipmi_thread+0x5d/0x200 [ipmi_si] [ 215.760377] kthread+0x13c/0x160 [ 215.764247] ret_from_fork+0x24/0x50 [ 215.768457] -> #0 (&(&new_smi->si_lock)->rlock){..-.}: [ 215.775220] __lock_acquire+0xa61/0xfb0 [ 215.779700] lock_acquire+0xae/0x180 [ 215.783912] _raw_spin_lock_irqsave+0x4d/0x8a [ 215.788915] set_need_watch+0x2d/0x70 [ipmi_si] [ 215.794091] smi_tell_to_watch.constprop.39+0x4a/0x50 [ipmi_msghandler] [ 215.801353] smi_recv_tasklet+0xe8/0x260 [ipmi_msghandler] [ 215.807484] tasklet_action_common.isra.14+0x83/0x1a0 [ 215.813177] tasklet_action+0x22/0x30 [ 215.817479] __do_softirq+0xd4/0x3ef [ 215.821698] irq_exit+0x120/0x130 [ 215.825649] smp_irq_work_interrupt+0x8c/0x190 [ 215.830732] irq_work_interrupt+0xf/0x20 [ 215.835296] _raw_spin_unlock_irqrestore+0x56/0x60 [ 215.840725] ipmi_thread+0x13e/0x200 [ipmi_si] [ 215.845811] kthread+0x13c/0x160 [ 215.849683] ret_from_fork+0x24/0x50 [ 215.853894] other info that might help us debug this: [ 215.862075] Possible unsafe locking scenario: [ 215.868139] CPU0 CPU1 [ 215.872788] ---- ---- [ 215.877433] lock(&(&intf->xmit_msgs_lock)->rlock); [ 215.882512] lock(&(&new_smi->si_lock)->rlock); [ 215.889776] lock(&(&intf->xmit_msgs_lock)->rlock); [ 215.897413] lock(&(&new_smi->si_lock)->rlock); [ 215.902151] *** DEADLOCK *** [ 215.908250] 2 locks held by kipmi0/1465: This seems to also indicate the same locks as culprits although the backtraces look different from the actual crashes.

1 year, 6 months

3
5
0 0

[PATCH net-next] net: dsa: microchip: ksz9477: follow errata sheet when applying fixups

by Rasmus Villemoes

The errata sheets for both ksz9477 and ksz9567 begin with IMPORTANT NOTE Multiple errata workarounds in this document call for changing PHY registers for each PHY port. PHY registers 0x0 to 0x1F are in the address range 0xN100 to 0xN13F, while indirect (MMD) PHY registers are accessed via the PHY MMD Setup Register and the PHY MMD Data Register. Before configuring the PHY MMD registers, it is necessary to set the PHY to 100 Mbps speed with auto-negotiation disabled by writing to register 0xN100-0xN101. After writing the MMD registers, and after all errata workarounds that involve PHY register settings, write register 0xN100-0xN101 again to enable and restart auto-negotiation. Without that explicit auto-neg restart, we do sometimes have problems establishing link. Rather than writing back the hardcoded 0x1340 value the errata sheet suggests (which likely just corresponds to the most common strap configuration), restore the original value, setting the PORT_AUTO_NEG_RESTART bit if PORT_AUTO_NEG_ENABLE is set. Fixes: 1fc33199185d ("net: dsa: microchip: Add PHY errata workarounds") Cc: stable(a)vger.kernel.org Signed-off-by: Rasmus Villemoes <linux(a)rasmusvillemoes.dk> --- While I do believe this is a fix, I don't think it's post-rc7 material, hence targeting net-next with cc stable. drivers/net/dsa/microchip/ksz9477.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/drivers/net/dsa/microchip/ksz9477.c b/drivers/net/dsa/microchip/ksz9477.c index bf13d47c26cf..9a712ea71ee7 100644 --- a/drivers/net/dsa/microchip/ksz9477.c +++ b/drivers/net/dsa/microchip/ksz9477.c @@ -902,6 +902,16 @@ static void ksz9477_port_mmd_write(struct ksz_device *dev, int port, static void ksz9477_phy_errata_setup(struct ksz_device *dev, int port) { + u16 cr; + + /* Errata document says the PHY must be configured to 100Mbps + * with auto-neg disabled before configuring the PHY MMD + * registers. + */ + ksz_pread16(dev, port, REG_PORT_PHY_CTRL, &cr); + ksz_pwrite16(dev, port, REG_PORT_PHY_CTRL, + PORT_SPEED_100MBIT | PORT_FULL_DUPLEX); + /* Apply PHY settings to address errata listed in * KSZ9477, KSZ9897, KSZ9896, KSZ9567, KSZ8565 * Silicon Errata and Data Sheet Clarification documents: @@ -943,6 +953,13 @@ static void ksz9477_phy_errata_setup(struct ksz_device *dev, int port) ksz9477_port_mmd_write(dev, port, 0x1c, 0x1d, 0xe7ff); ksz9477_port_mmd_write(dev, port, 0x1c, 0x1e, 0xefff); ksz9477_port_mmd_write(dev, port, 0x1c, 0x20, 0xeeee); + + /* Restore PHY CTRL register, restart auto-negotiation if + * enabled in the original value. + */ + if (cr & PORT_AUTO_NEG_ENABLE) + cr |= PORT_AUTO_NEG_RESTART; + ksz_pwrite16(dev, port, REG_PORT_PHY_CTRL, cr); } void ksz9477_get_caps(struct ksz_device *dev, int port, -- 2.37.2

1 year, 6 months

4
4
0 0

Re: [PATCH AUTOSEL 4.14 08/10] MIPS: Alchemy: fix dbdma2

by Pavel Machek

On Sun 2023-06-18 07:43:10, Manuel Lauss wrote: > On Fri, Jun 16, 2023 at 9:33 PM Pavel Machek <pavel(a)denx.de> wrote: > > > Hi! > > > > > From: Manuel Lauss <manuel.lauss(a)gmail.com> > > > > > > [ Upstream commit 2d645604f69f3a772d58ead702f9a8e84ab2b342 ] > > > > > > Various fixes for the Au1200/Au1550/Au1300 DBDMA2 code: > > > > > > - skip cache invalidation if chip has working coherency circuitry. > > > - invalidate KSEG0-portion of the (physical) data address. > > > - force the dma channel doorbell write out to bus immediately with > > > a sync. > > > > > > Signed-off-by: Thomas Bogendoerfer <tsbogend(a)alpha.franken.de> > > > Signed-off-by: Sasha Levin <sashal(a)kernel.org> > > > > I believe author's signoff is missing here. > > > > As the author, I say this patch should not be applied to 4.xx at all. Same > for my other 2 MIPS patches. Thanks for info, where is the threshold, do we need them for 5.10? Sasha, please drop. Best regards, Pavel -- DENX Software Engineering GmbH, Managing Director: Erika Unter HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

1 year, 6 months

2
1
0 0

[PATCH 5.4] tracing: Add tracing_reset_all_online_cpus_unlocked() function

by Zheng Yejian

From: "Steven Rostedt (Google)" <rostedt(a)goodmis.org> commit e18eb8783ec4949adebc7d7b0fdb65f65bfeefd9 upstream. Currently the tracing_reset_all_online_cpus() requires the trace_types_lock held. But only one caller of this function actually has that lock held before calling it, and the other just takes the lock so that it can call it. More users of this function is needed where the lock is not held. Add a tracing_reset_all_online_cpus_unlocked() function for the one use case that calls it without being held, and also add a lockdep_assert to make sure it is held when called. Then have tracing_reset_all_online_cpus() take the lock internally, such that callers do not need to worry about taking it. Link: https://lkml.kernel.org/r/20221123192741.658273220@goodmis.org Cc: Masami Hiramatsu <mhiramat(a)kernel.org> Cc: Andrew Morton <akpm(a)linux-foundation.org> Cc: Zheng Yejian <zhengyejian1(a)huawei.com> Signed-off-by: Steven Rostedt (Google) <rostedt(a)goodmis.org> [Refers to commit message of 1603feac154ff38514e8354e3079a455eb4801e2, this patch is pre-depended, and tracing_reset_all_online_cpus() should be called after trace_types_lock is held as its comment describes.] Fixes: 1603feac154f ("tracing: Free buffers when a used dynamic event is removed") Signed-off-by: Zheng Yejian <zhengyejian1(a)huawei.com> --- kernel/trace/trace.c | 11 ++++++++++- kernel/trace/trace.h | 1 + kernel/trace/trace_events.c | 2 +- 3 files changed, 12 insertions(+), 2 deletions(-) diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c index d068124815bc..219cd2c81936 100644 --- a/kernel/trace/trace.c +++ b/kernel/trace/trace.c @@ -1931,10 +1931,12 @@ void tracing_reset_online_cpus(struct trace_buffer *buf) } /* Must have trace_types_lock held */ -void tracing_reset_all_online_cpus(void) +void tracing_reset_all_online_cpus_unlocked(void) { struct trace_array *tr; + lockdep_assert_held(&trace_types_lock); + list_for_each_entry(tr, &ftrace_trace_arrays, list) { if (!tr->clear_trace) continue; @@ -1946,6 +1948,13 @@ void tracing_reset_all_online_cpus(void) } } +void tracing_reset_all_online_cpus(void) +{ + mutex_lock(&trace_types_lock); + tracing_reset_all_online_cpus_unlocked(); + mutex_unlock(&trace_types_lock); +} + /* * The tgid_map array maps from pid to tgid; i.e. the value stored at index i * is the tgid last observed corresponding to pid=i. diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h index f2ff39353e03..edc17a640ab3 100644 --- a/kernel/trace/trace.h +++ b/kernel/trace/trace.h @@ -677,6 +677,7 @@ int tracing_is_enabled(void); void tracing_reset_online_cpus(struct trace_buffer *buf); void tracing_reset_current(int cpu); void tracing_reset_all_online_cpus(void); +void tracing_reset_all_online_cpus_unlocked(void); int tracing_open_generic(struct inode *inode, struct file *filp); int tracing_open_generic_tr(struct inode *inode, struct file *filp); bool tracing_is_disabled(void); diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c index 8f2cbc9ebb6e..a0675ecc8142 100644 --- a/kernel/trace/trace_events.c +++ b/kernel/trace/trace_events.c @@ -2440,7 +2440,7 @@ static void trace_module_remove_events(struct module *mod) * over from this module may be passed to the new module events and * unexpected results may occur. */ - tracing_reset_all_online_cpus(); + tracing_reset_all_online_cpus_unlocked(); } static int trace_module_notify(struct notifier_block *self, -- 2.25.1

1 year, 6 months

1
0
0 0

[PATCH 5.10] tracing: Add tracing_reset_all_online_cpus_unlocked() function

by Zheng Yejian

From: "Steven Rostedt (Google)" <rostedt(a)goodmis.org> commit e18eb8783ec4949adebc7d7b0fdb65f65bfeefd9 upstream. Currently the tracing_reset_all_online_cpus() requires the trace_types_lock held. But only one caller of this function actually has that lock held before calling it, and the other just takes the lock so that it can call it. More users of this function is needed where the lock is not held. Add a tracing_reset_all_online_cpus_unlocked() function for the one use case that calls it without being held, and also add a lockdep_assert to make sure it is held when called. Then have tracing_reset_all_online_cpus() take the lock internally, such that callers do not need to worry about taking it. Link: https://lkml.kernel.org/r/20221123192741.658273220@goodmis.org Cc: Masami Hiramatsu <mhiramat(a)kernel.org> Cc: Andrew Morton <akpm(a)linux-foundation.org> Cc: Zheng Yejian <zhengyejian1(a)huawei.com> Signed-off-by: Steven Rostedt (Google) <rostedt(a)goodmis.org> [Refers to commit message of be111ebd8868d4b7c041cb3c6102e1ae27d6dc1d, this patch is pre-depended, and tracing_reset_all_online_cpus() should be called after trace_types_lock is held as its comment describes.] Fixes: be111ebd8868 ("tracing: Free buffers when a used dynamic event is removed") Signed-off-by: Zheng Yejian <zhengyejian1(a)huawei.com> --- kernel/trace/trace.c | 11 ++++++++++- kernel/trace/trace.h | 1 + kernel/trace/trace_events.c | 2 +- kernel/trace/trace_events_synth.c | 2 -- 4 files changed, 12 insertions(+), 4 deletions(-) diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c index 482ec6606b7b..70526400e05c 100644 --- a/kernel/trace/trace.c +++ b/kernel/trace/trace.c @@ -2178,10 +2178,12 @@ void tracing_reset_online_cpus(struct array_buffer *buf) } /* Must have trace_types_lock held */ -void tracing_reset_all_online_cpus(void) +void tracing_reset_all_online_cpus_unlocked(void) { struct trace_array *tr; + lockdep_assert_held(&trace_types_lock); + list_for_each_entry(tr, &ftrace_trace_arrays, list) { if (!tr->clear_trace) continue; @@ -2193,6 +2195,13 @@ void tracing_reset_all_online_cpus(void) } } +void tracing_reset_all_online_cpus(void) +{ + mutex_lock(&trace_types_lock); + tracing_reset_all_online_cpus_unlocked(); + mutex_unlock(&trace_types_lock); +} + /* * The tgid_map array maps from pid to tgid; i.e. the value stored at index i * is the tgid last observed corresponding to pid=i. diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h index 37f616bf5fa9..e5b505b5b7d0 100644 --- a/kernel/trace/trace.h +++ b/kernel/trace/trace.h @@ -725,6 +725,7 @@ int tracing_is_enabled(void); void tracing_reset_online_cpus(struct array_buffer *buf); void tracing_reset_current(int cpu); void tracing_reset_all_online_cpus(void); +void tracing_reset_all_online_cpus_unlocked(void); int tracing_open_generic(struct inode *inode, struct file *filp); int tracing_open_generic_tr(struct inode *inode, struct file *filp); bool tracing_is_disabled(void); diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c index bac13f24a96e..f8ed66f38175 100644 --- a/kernel/trace/trace_events.c +++ b/kernel/trace/trace_events.c @@ -2661,7 +2661,7 @@ static void trace_module_remove_events(struct module *mod) * over from this module may be passed to the new module events and * unexpected results may occur. */ - tracing_reset_all_online_cpus(); + tracing_reset_all_online_cpus_unlocked(); } static int trace_module_notify(struct notifier_block *self, diff --git a/kernel/trace/trace_events_synth.c b/kernel/trace/trace_events_synth.c index 18291ab35657..ee174de0b8f6 100644 --- a/kernel/trace/trace_events_synth.c +++ b/kernel/trace/trace_events_synth.c @@ -1363,7 +1363,6 @@ int synth_event_delete(const char *event_name) mutex_unlock(&event_mutex); if (mod) { - mutex_lock(&trace_types_lock); /* * It is safest to reset the ring buffer if the module * being unloaded registered any events that were @@ -1375,7 +1374,6 @@ int synth_event_delete(const char *event_name) * occur. */ tracing_reset_all_online_cpus(); - mutex_unlock(&trace_types_lock); } return ret; -- 2.25.1

1 year, 6 months

1
0
0 0

[merged mm-stable] shmem-use-ramfs_kill_sb-for-kill_sb-method-of-ramfs-based-tmpfs.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: shmem: use ramfs_kill_sb() for kill_sb method of ramfs-based tmpfs has been removed from the -mm tree. Its filename was shmem-use-ramfs_kill_sb-for-kill_sb-method-of-ramfs-based-tmpfs.patch This patch was dropped because it was merged into the mm-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Roberto Sassu <roberto.sassu(a)huawei.com> Subject: shmem: use ramfs_kill_sb() for kill_sb method of ramfs-based tmpfs Date: Wed, 7 Jun 2023 18:15:23 +0200 As the ramfs-based tmpfs uses ramfs_init_fs_context() for the init_fs_context method, which allocates fc->s_fs_info, use ramfs_kill_sb() to free it and avoid a memory leak. Link: https://lkml.kernel.org/r/20230607161523.2876433-1-roberto.sassu@huaweiclou… Fixes: c3b1b1cbf002 ("ramfs: add support for "mode=" mount option") Signed-off-by: Roberto Sassu <roberto.sassu(a)huawei.com> Cc: Hugh Dickins <hughd(a)google.com> Cc: David Howells <dhowells(a)redhat.com> Cc: Al Viro <viro(a)zeniv.linux.org.uk> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/ramfs/inode.c | 2 +- include/linux/ramfs.h | 1 + mm/shmem.c | 2 +- 3 files changed, 3 insertions(+), 2 deletions(-) --- a/fs/ramfs/inode.c~shmem-use-ramfs_kill_sb-for-kill_sb-method-of-ramfs-based-tmpfs +++ a/fs/ramfs/inode.c @@ -278,7 +278,7 @@ int ramfs_init_fs_context(struct fs_cont return 0; } -static void ramfs_kill_sb(struct super_block *sb) +void ramfs_kill_sb(struct super_block *sb) { kfree(sb->s_fs_info); kill_litter_super(sb); --- a/include/linux/ramfs.h~shmem-use-ramfs_kill_sb-for-kill_sb-method-of-ramfs-based-tmpfs +++ a/include/linux/ramfs.h @@ -7,6 +7,7 @@ struct inode *ramfs_get_inode(struct super_block *sb, const struct inode *dir, umode_t mode, dev_t dev); extern int ramfs_init_fs_context(struct fs_context *fc); +extern void ramfs_kill_sb(struct super_block *sb); #ifdef CONFIG_MMU static inline int --- a/mm/shmem.c~shmem-use-ramfs_kill_sb-for-kill_sb-method-of-ramfs-based-tmpfs +++ a/mm/shmem.c @@ -4199,7 +4199,7 @@ static struct file_system_type shmem_fs_ .name = "tmpfs", .init_fs_context = ramfs_init_fs_context, .parameters = ramfs_fs_parameters, - .kill_sb = kill_litter_super, + .kill_sb = ramfs_kill_sb, .fs_flags = FS_USERNS_MOUNT, }; _ Patches currently in -mm which might be from roberto.sassu(a)huawei.com are

1 year, 6 months

1
0
0 0

FAILED: patch "[PATCH] serial: lantiq: add missing interrupt ack" failed to apply to 4.19-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.19-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-4.19.y git checkout FETCH_HEAD git cherry-pick -x 306320034e8fbe7ee1cc4f5269c55658b4612048 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023061831-detention-overtime-783b@gregkh' --subject-prefix 'PATCH 4.19.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 306320034e8fbe7ee1cc4f5269c55658b4612048 Mon Sep 17 00:00:00 2001 From: Bernhard Seibold <mail(a)bernhard-seibold.de> Date: Fri, 2 Jun 2023 15:30:29 +0200 Subject: [PATCH] serial: lantiq: add missing interrupt ack MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Currently, the error interrupt is never acknowledged, so once active it will stay active indefinitely, causing the handler to be called in an infinite loop. Fixes: 2f0fc4159a6a ("SERIAL: Lantiq: Add driver for MIPS Lantiq SOCs.") Cc: <stable(a)vger.kernel.org> Signed-off-by: Bernhard Seibold <mail(a)bernhard-seibold.de> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen(a)linux.intel.com> Message-ID: <20230602133029.546-1-mail(a)bernhard-seibold.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/tty/serial/lantiq.c b/drivers/tty/serial/lantiq.c index a58e9277dfad..f1387f1024db 100644 --- a/drivers/tty/serial/lantiq.c +++ b/drivers/tty/serial/lantiq.c @@ -250,6 +250,7 @@ lqasc_err_int(int irq, void *_port) struct ltq_uart_port *ltq_port = to_ltq_uart_port(port); spin_lock_irqsave(&ltq_port->lock, flags); + __raw_writel(ASC_IRNCR_EIR, port->membase + LTQ_ASC_IRNCR); /* clear any pending interrupts */ asc_update_bits(0, ASCWHBSTATE_CLRPE | ASCWHBSTATE_CLRFE | ASCWHBSTATE_CLRROE, port->membase + LTQ_ASC_WHBSTATE);

1 year, 6 months

2
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror June 2023