January 2023 - Linux-stable-mirror

[PATCH] clocksource/drivers/arm_arch_timer: Update sched_clock when non-boot CPUs need counter workaround

by Marc Zyngier

When booting on a CPU that has a countertum on the counter read, we use the arch_counter_get_cnt{v,p}ct_stable() backend which applies the workaround. However, we don't do the same thing when an affected CPU is a secondary CPU, and we're stuck with the standard sched_clock() backend that knows nothing about the workaround. Fix it by always indirecting sched_clock(), making arch_timer_read_counter a function instead of a function pointer. In turn, we update the pointer (now private to the driver code) when detecting a new workaround. Cc: Mark Rutland <mark.rutland(a)arm.com> Cc: Will Deacon <will(a)kernel.org> Cc: Daniel Lezcano <daniel.lezcano(a)kernel.org> Cc: Thomas Gleixner <tglx(a)linotronix.de> Cc: stable(a)vger.kernel.org Reported-by: Yogesh Lal <quic_ylal(a)quicinc.com> Signed-off-by: Marc Zyngier <maz(a)kernel.org> Fixes: 0ea415390cd3 ("clocksource/arm_arch_timer: Use arch_timer_read_counter to access stable counters") Link: https://lore.kernel.org/r/ca4679a0-7f29-65f4-54b9-c575248192f1@quicinc.com --- drivers/clocksource/arm_arch_timer.c | 56 +++++++++++++++++----------- include/clocksource/arm_arch_timer.h | 2 +- 2 files changed, 36 insertions(+), 22 deletions(-) diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c index e09d4427f604..5272db86bef5 100644 --- a/drivers/clocksource/arm_arch_timer.c +++ b/drivers/clocksource/arm_arch_timer.c @@ -217,7 +217,12 @@ static notrace u64 arch_counter_get_cntvct(void) * to exist on arm64. arm doesn't use this before DT is probed so even * if we don't have the cp15 accessors we won't have a problem. */ -u64 (*arch_timer_read_counter)(void) __ro_after_init = arch_counter_get_cntvct; +static u64 (*__arch_timer_read_counter)(void) __ro_after_init = arch_counter_get_cntvct; + +u64 arch_timer_read_counter(void) +{ + return __arch_timer_read_counter(); +} EXPORT_SYMBOL_GPL(arch_timer_read_counter); static u64 arch_counter_read(struct clocksource *cs) @@ -230,6 +235,28 @@ static u64 arch_counter_read_cc(const struct cyclecounter *cc) return arch_timer_read_counter(); } +static bool arch_timer_counter_has_wa(void); + +static u64 (*arch_counter_get_read_fn(void))(void) +{ + u64 (*rd)(void); + + if ((IS_ENABLED(CONFIG_ARM64) && !is_hyp_mode_available()) || + arch_timer_uses_ppi == ARCH_TIMER_VIRT_PPI) { + if (arch_timer_counter_has_wa()) + rd = arch_counter_get_cntvct_stable; + else + rd = arch_counter_get_cntvct; + } else { + if (arch_timer_counter_has_wa()) + rd = arch_counter_get_cntpct_stable; + else + rd = arch_counter_get_cntpct; + } + + return rd; +} + static struct clocksource clocksource_counter = { .name = "arch_sys_counter", .id = CSID_ARM_ARCH_COUNTER, @@ -571,8 +598,10 @@ void arch_timer_enable_workaround(const struct arch_timer_erratum_workaround *wa per_cpu(timer_unstable_counter_workaround, i) = wa; } - if (wa->read_cntvct_el0 || wa->read_cntpct_el0) - atomic_set(&timer_unstable_counter_workaround_in_use, 1); + if (wa->read_cntvct_el0 || wa->read_cntpct_el0) { + __arch_timer_read_counter = arch_counter_get_read_fn(); + atomic_set_release(&timer_unstable_counter_workaround_in_use, 1); + } /* * Don't use the vdso fastpath if errata require using the @@ -641,7 +670,7 @@ static bool arch_timer_counter_has_wa(void) #else #define arch_timer_check_ool_workaround(t,a) do { } while(0) #define arch_timer_this_cpu_has_cntvct_wa() ({false;}) -#define arch_timer_counter_has_wa() ({false;}) +static bool arch_timer_counter_has_wa(void) { return false; } #endif /* CONFIG_ARM_ARCH_TIMER_OOL_WORKAROUND */ static __always_inline irqreturn_t timer_handler(const int access, @@ -1079,25 +1108,10 @@ static void __init arch_counter_register(unsigned type) /* Register the CP15 based counter if we have one */ if (type & ARCH_TIMER_TYPE_CP15) { - u64 (*rd)(void); - - if ((IS_ENABLED(CONFIG_ARM64) && !is_hyp_mode_available()) || - arch_timer_uses_ppi == ARCH_TIMER_VIRT_PPI) { - if (arch_timer_counter_has_wa()) - rd = arch_counter_get_cntvct_stable; - else - rd = arch_counter_get_cntvct; - } else { - if (arch_timer_counter_has_wa()) - rd = arch_counter_get_cntpct_stable; - else - rd = arch_counter_get_cntpct; - } - - arch_timer_read_counter = rd; + __arch_timer_read_counter = arch_counter_get_read_fn(); clocksource_counter.vdso_clock_mode = vdso_default; } else { - arch_timer_read_counter = arch_counter_get_cntvct_mem; + __arch_timer_read_counter = arch_counter_get_cntvct_mem; } width = arch_counter_get_width(); diff --git a/include/clocksource/arm_arch_timer.h b/include/clocksource/arm_arch_timer.h index 057c8964aefb..ec331b65ba23 100644 --- a/include/clocksource/arm_arch_timer.h +++ b/include/clocksource/arm_arch_timer.h @@ -85,7 +85,7 @@ struct arch_timer_mem { #ifdef CONFIG_ARM_ARCH_TIMER extern u32 arch_timer_get_rate(void); -extern u64 (*arch_timer_read_counter)(void); +extern u64 arch_timer_read_counter(void); extern struct arch_timer_kvm_info *arch_timer_get_kvm_info(void); extern bool arch_timer_evtstrm_available(void); -- 2.34.1

1 year, 9 months

3
2
0 0

[PATCH v2] module: Don't wait for GOING modules

by Petr Pavlu

During a system boot, it can happen that the kernel receives a burst of requests to insert the same module but loading it eventually fails during its init call. For instance, udev can make a request to insert a frequency module for each individual CPU when another frequency module is already loaded which causes the init function of the new module to return an error. Since commit 6e6de3dee51a ("kernel/module.c: Only return -EEXIST for modules that have finished loading"), the kernel waits for modules in MODULE_STATE_GOING state to finish unloading before making another attempt to load the same module. This creates unnecessary work in the described scenario and delays the boot. In the worst case, it can prevent udev from loading drivers for other devices and might cause timeouts of services waiting on them and subsequently a failed boot. This patch attempts a different solution for the problem 6e6de3dee51a was trying to solve. Rather than waiting for the unloading to complete, it returns a different error code (-EBUSY) for modules in the GOING state. This should avoid the error situation that was described in 6e6de3dee51a (user space attempting to load a dependent module because the -EEXIST error code would suggest to user space that the first module had been loaded successfully), while avoiding the delay situation too. Fixes: 6e6de3dee51a ("kernel/module.c: Only return -EEXIST for modules that have finished loading") Co-developed-by: Martin Wilck <mwilck(a)suse.com> Signed-off-by: Martin Wilck <mwilck(a)suse.com> Signed-off-by: Petr Pavlu <petr.pavlu(a)suse.com> Cc: stable(a)vger.kernel.org --- Changes since v1 [1]: - Don't attempt a new module initialization when a same-name module completely disappeared while waiting on it, which means it went through the GOING state implicitly already. [1] https://lore.kernel.org/linux-modules/20221123131226.24359-1-petr.pavlu@sus… kernel/module/main.c | 26 +++++++++++++++++++++----- 1 file changed, 21 insertions(+), 5 deletions(-) diff --git a/kernel/module/main.c b/kernel/module/main.c index d02d39c7174e..7a627345d4fd 100644 --- a/kernel/module/main.c +++ b/kernel/module/main.c @@ -2386,7 +2386,8 @@ static bool finished_loading(const char *name) sched_annotate_sleep(); mutex_lock(&module_mutex); mod = find_module_all(name, strlen(name), true); - ret = !mod || mod->state == MODULE_STATE_LIVE; + ret = !mod || mod->state == MODULE_STATE_LIVE + || mod->state == MODULE_STATE_GOING; mutex_unlock(&module_mutex); return ret; @@ -2562,20 +2563,35 @@ static int add_unformed_module(struct module *mod) mod->state = MODULE_STATE_UNFORMED; -again: mutex_lock(&module_mutex); old = find_module_all(mod->name, strlen(mod->name), true); if (old != NULL) { - if (old->state != MODULE_STATE_LIVE) { + if (old->state == MODULE_STATE_COMING + || old->state == MODULE_STATE_UNFORMED) { /* Wait in case it fails to load. */ mutex_unlock(&module_mutex); err = wait_event_interruptible(module_wq, finished_loading(mod->name)); if (err) goto out_unlocked; - goto again; + + /* The module might have gone in the meantime. */ + mutex_lock(&module_mutex); + old = find_module_all(mod->name, strlen(mod->name), + true); } - err = -EEXIST; + + /* + * We are here only when the same module was being loaded. Do + * not try to load it again right now. It prevents long delays + * caused by serialized module load failures. It might happen + * when more devices of the same type trigger load of + * a particular module. + */ + if (old && old->state == MODULE_STATE_LIVE) + err = -EEXIST; + else + err = -EBUSY; goto out; } mod_update_bounds(mod); -- 2.35.3

1 year, 9 months

5
30
0 0

[PATCH v2] wifi: cfg80211: Fix use after free for wext

by Alexander Wetzel

Key information in wext.connect is not reset on (re)connect and can hold data from a previous connection. Reset key data to avoid that drivers or mac80211 incorrectly detect a WEP connection request and access the freed or already reused memory. Additionally optimize cfg80211_sme_connect() and avoid an useless schedule of conn_work. Fixes: fffd0934b939 ("cfg80211: rework key operation") Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/r/c80f04d2-8159-a02a-9287-26e5ec838826@wetzel-home.… Signed-off-by: Alexander Wetzel <alexander(a)wetzel-home.de> --- V2 changes: - updated comment - reset more key data --- net/wireless/sme.c | 31 ++++++++++++++++++++++++++----- 1 file changed, 26 insertions(+), 5 deletions(-) diff --git a/net/wireless/sme.c b/net/wireless/sme.c index 123248b2c0be..0cc841c0c59b 100644 --- a/net/wireless/sme.c +++ b/net/wireless/sme.c @@ -285,6 +285,15 @@ void cfg80211_conn_work(struct work_struct *work) wiphy_unlock(&rdev->wiphy); } +static void cfg80211_step_auth_next(struct cfg80211_conn *conn, + struct cfg80211_bss *bss) +{ + memcpy(conn->bssid, bss->bssid, ETH_ALEN); + conn->params.bssid = conn->bssid; + conn->params.channel = bss->channel; + conn->state = CFG80211_CONN_AUTHENTICATE_NEXT; +} + /* Returned bss is reference counted and must be cleaned up appropriately. */ static struct cfg80211_bss *cfg80211_get_conn_bss(struct wireless_dev *wdev) { @@ -302,10 +311,7 @@ static struct cfg80211_bss *cfg80211_get_conn_bss(struct wireless_dev *wdev) if (!bss) return NULL; - memcpy(wdev->conn->bssid, bss->bssid, ETH_ALEN); - wdev->conn->params.bssid = wdev->conn->bssid; - wdev->conn->params.channel = bss->channel; - wdev->conn->state = CFG80211_CONN_AUTHENTICATE_NEXT; + cfg80211_step_auth_next(wdev->conn, bss); schedule_work(&rdev->conn_work); return bss; @@ -597,7 +603,12 @@ static int cfg80211_sme_connect(struct wireless_dev *wdev, wdev->conn->params.ssid_len = wdev->u.client.ssid_len; /* see if we have the bss already */ - bss = cfg80211_get_conn_bss(wdev); + bss = cfg80211_get_bss(wdev->wiphy, wdev->conn->params.channel, + wdev->conn->params.bssid, + wdev->conn->params.ssid, + wdev->conn->params.ssid_len, + wdev->conn_bss_type, + IEEE80211_PRIVACY(wdev->conn->params.privacy)); if (prev_bssid) { memcpy(wdev->conn->prev_bssid, prev_bssid, ETH_ALEN); @@ -608,6 +619,7 @@ static int cfg80211_sme_connect(struct wireless_dev *wdev, if (bss) { enum nl80211_timeout_reason treason; + cfg80211_step_auth_next(wdev->conn, bss); err = cfg80211_conn_do_work(wdev, &treason); cfg80211_put_bss(wdev->wiphy, bss); } else { @@ -1464,6 +1476,15 @@ int cfg80211_connect(struct cfg80211_registered_device *rdev, } else { if (WARN_ON(connkeys)) return -EINVAL; + + /* connect can point to wdev->wext.connect which + * can hold key data from a previous connection + */ + connect->key = NULL; + connect->key_len = 0; + connect->key_idx = 0; + connect->crypto.cipher_group = 0; + connect->crypto.n_ciphers_pairwise = 0; } wdev->connect_keys = connkeys; -- 2.39.0

1 year, 9 months

7
7
0 0

FAILED: patch "[PATCH] tracing: Free buffers when a used dynamic event is removed" 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>. Possible dependencies: 4313e5a61304 ("tracing: Free buffers when a used dynamic event is removed") 5448d44c3855 ("tracing: Add unified dynamic event framework") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 4313e5a613049dfc1819a6dfb5f94cf2caff9452 Mon Sep 17 00:00:00 2001 From: "Steven Rostedt (Google)" <rostedt(a)goodmis.org> Date: Wed, 23 Nov 2022 17:14:34 -0500 Subject: [PATCH] tracing: Free buffers when a used dynamic event is removed MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit After 65536 dynamic events have been added and removed, the "type" field of the event then uses the first type number that is available (not currently used by other events). A type number is the identifier of the binary blobs in the tracing ring buffer (known as events) to map them to logic that can parse the binary blob. The issue is that if a dynamic event (like a kprobe event) is traced and is in the ring buffer, and then that event is removed (because it is dynamic, which means it can be created and destroyed), if another dynamic event is created that has the same number that new event's logic on parsing the binary blob will be used. To show how this can be an issue, the following can crash the kernel: # cd /sys/kernel/tracing # for i in `seq 65536`; do echo 'p:kprobes/foo do_sys_openat2 $arg1:u32' > kprobe_events # done For every iteration of the above, the writing to the kprobe_events will remove the old event and create a new one (with the same format) and increase the type number to the next available on until the type number reaches over 65535 which is the max number for the 16 bit type. After it reaches that number, the logic to allocate a new number simply looks for the next available number. When an dynamic event is removed, that number is then available to be reused by the next dynamic event created. That is, once the above reaches the max number, the number assigned to the event in that loop will remain the same. Now that means deleting one dynamic event and created another will reuse the previous events type number. This is where bad things can happen. After the above loop finishes, the kprobes/foo event which reads the do_sys_openat2 function call's first parameter as an integer. # echo 1 > kprobes/foo/enable # cat /etc/passwd > /dev/null # cat trace cat-2211 [005] .... 2007.849603: foo: (do_sys_openat2+0x0/0x130) arg1=4294967196 cat-2211 [005] .... 2007.849620: foo: (do_sys_openat2+0x0/0x130) arg1=4294967196 cat-2211 [005] .... 2007.849838: foo: (do_sys_openat2+0x0/0x130) arg1=4294967196 cat-2211 [005] .... 2007.849880: foo: (do_sys_openat2+0x0/0x130) arg1=4294967196 # echo 0 > kprobes/foo/enable Now if we delete the kprobe and create a new one that reads a string: # echo 'p:kprobes/foo do_sys_openat2 +0($arg2):string' > kprobe_events And now we can the trace: # cat trace sendmail-1942 [002] ..... 530.136320: foo: (do_sys_openat2+0x0/0x240) arg1= cat-2046 [004] ..... 530.930817: foo: (do_sys_openat2+0x0/0x240) arg1="��" cat-2046 [004] ..... 530.930961: foo: (do_sys_openat2+0x0/0x240) arg1="��" cat-2046 [004] ..... 530.934278: foo: (do_sys_openat2+0x0/0x240) arg1="��" cat-2046 [004] ..... 530.934563: foo: (do_sys_openat2+0x0/0x240) arg1="��" bash-1515 [007] ..... 534.299093: foo: (do_sys_openat2+0x0/0x240) arg1="kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk��@��4Z��;Y��U And dmesg has: ================================================================== BUG: KASAN: use-after-free in string+0xd4/0x1c0 Read of size 1 at addr ffff88805fdbbfa0 by task cat/2049 CPU: 0 PID: 2049 Comm: cat Not tainted 6.1.0-rc6-test+ #641 Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 v03.03 07/14/2016 Call Trace: <TASK> dump_stack_lvl+0x5b/0x77 print_report+0x17f/0x47b kasan_report+0xad/0x130 string+0xd4/0x1c0 vsnprintf+0x500/0x840 seq_buf_vprintf+0x62/0xc0 trace_seq_printf+0x10e/0x1e0 print_type_string+0x90/0xa0 print_kprobe_event+0x16b/0x290 print_trace_line+0x451/0x8e0 s_show+0x72/0x1f0 seq_read_iter+0x58e/0x750 seq_read+0x115/0x160 vfs_read+0x11d/0x460 ksys_read+0xa9/0x130 do_syscall_64+0x3a/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7fc2e972ade2 Code: c0 e9 b2 fe ff ff 50 48 8d 3d b2 3f 0a 00 e8 05 f0 01 00 0f 1f 44 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 0f 05 <48> 3d 00 f0 ff ff 77 56 c3 0f 1f 44 00 00 48 83 ec 28 48 89 54 24 RSP: 002b:00007ffc64e687c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 RAX: ffffffffffffffda RBX: 0000000000020000 RCX: 00007fc2e972ade2 RDX: 0000000000020000 RSI: 00007fc2e980d000 RDI: 0000000000000003 RBP: 00007fc2e980d000 R08: 00007fc2e980c010 R09: 0000000000000000 R10: 0000000000000022 R11: 0000000000000246 R12: 0000000000020f00 R13: 0000000000000003 R14: 0000000000020000 R15: 0000000000020000 </TASK> The buggy address belongs to the physical page: page:ffffea00017f6ec0 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x5fdbb flags: 0xfffffc0000000(node=0|zone=1|lastcpupid=0x1fffff) raw: 000fffffc0000000 0000000000000000 ffffea00017f6ec8 0000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff88805fdbbe80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88805fdbbf00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >ffff88805fdbbf80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff88805fdbc000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88805fdbc080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ================================================================== This was found when Zheng Yejian sent a patch to convert the event type number assignment to use IDA, which gives the next available number, and this bug showed up in the fuzz testing by Yujie Liu and the kernel test robot. But after further analysis, I found that this behavior is the same as when the event type numbers go past the 16bit max (and the above shows that). As modules have a similar issue, but is dealt with by setting a "WAS_ENABLED" flag when a module event is enabled, and when the module is freed, if any of its events were enabled, the ring buffer that holds that event is also cleared, to prevent reading stale events. The same can be done for dynamic events. If any dynamic event that is being removed was enabled, then make sure the buffers they were enabled in are now cleared. Link: https://lkml.kernel.org/r/20221123171434.545706e3@gandalf.local.home Link: https://lore.kernel.org/all/20221110020319.1259291-1-zhengyejian1@huawei.co… Cc: stable(a)vger.kernel.org Cc: Andrew Morton <akpm(a)linux-foundation.org> Depends-on: e18eb8783ec49 ("tracing: Add tracing_reset_all_online_cpus_unlocked() function") Depends-on: 5448d44c38557 ("tracing: Add unified dynamic event framework") Depends-on: 6212dd29683ee ("tracing/kprobes: Use dyn_event framework for kprobe events") Depends-on: 065e63f951432 ("tracing: Only have rmmod clear buffers that its events were active in") Depends-on: 575380da8b469 ("tracing: Only clear trace buffer on module unload if event was traced") Fixes: 77b44d1b7c283 ("tracing/kprobes: Rename Kprobe-tracer to kprobe-event") Reported-by: Zheng Yejian <zhengyejian1(a)huawei.com> Reported-by: Yujie Liu <yujie.liu(a)intel.com> Reported-by: kernel test robot <yujie.liu(a)intel.com> Acked-by: Masami Hiramatsu (Google) <mhiramat(a)kernel.org> Signed-off-by: Steven Rostedt (Google) <rostedt(a)goodmis.org> diff --git a/kernel/trace/trace_dynevent.c b/kernel/trace/trace_dynevent.c index 154996684fb5..4376887e0d8a 100644 --- a/kernel/trace/trace_dynevent.c +++ b/kernel/trace/trace_dynevent.c @@ -118,6 +118,7 @@ int dyn_event_release(const char *raw_command, struct dyn_event_operations *type if (ret) break; } + tracing_reset_all_online_cpus(); mutex_unlock(&event_mutex); out: argv_free(argv); @@ -214,6 +215,7 @@ int dyn_events_release_all(struct dyn_event_operations *type) break; } out: + tracing_reset_all_online_cpus(); mutex_unlock(&event_mutex); return ret; diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c index 78cd19e31dba..f71ea6e79b3c 100644 --- a/kernel/trace/trace_events.c +++ b/kernel/trace/trace_events.c @@ -2880,7 +2880,10 @@ static int probe_remove_event_call(struct trace_event_call *call) * TRACE_REG_UNREGISTER. */ if (file->flags & EVENT_FILE_FL_ENABLED) - return -EBUSY; + goto busy; + + if (file->flags & EVENT_FILE_FL_WAS_ENABLED) + tr->clear_trace = true; /* * The do_for_each_event_file_safe() is * a double loop. After finding the call for this @@ -2893,6 +2896,12 @@ static int probe_remove_event_call(struct trace_event_call *call) __trace_remove_event_call(call); return 0; + busy: + /* No need to clear the trace now */ + list_for_each_entry(tr, &ftrace_trace_arrays, list) { + tr->clear_trace = false; + } + return -EBUSY; } /* Remove an event_call */

1 year, 9 months

4
7
0 0

[PATCH] Fix data race in mark_rt_mutex_waiters

by Hernan Ponce de Leon

From: Hernan Ponce de Leon <hernanl.leon(a)huawei.com> Following the defition of data race in tools/memory-model/linux-kernel.cat the dartagnan tool https://github.com/hernanponcedeleon/Dat3M reported a race between mark_rt_mutex_waiters and rt_mutex_cmpxchg_release. Commit 23f78d4a03c5 ("[PATCH] pi-futex: rt mutex core") later removed in commit d0aa7a70bf03 ("futex_requeue_pi optimization") and reverted in commit bd197234b0a6 ("Revert "futex_requeue_pi optimization"") The original commit introduced the data race. Cc: stable(a)vger.kernel.org # v2.6.18.x Fixes: 23f78d4a03c5 ("[PATCH] pi-futex: rt mutex core") Signed-off-by: Hernan Ponce de Leon <hernanl.leon(a)huawei.com> --- kernel/locking/rtmutex.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c index 010cf4e6d0b8..7ed9472edd48 100644 --- a/kernel/locking/rtmutex.c +++ b/kernel/locking/rtmutex.c @@ -235,7 +235,7 @@ static __always_inline void mark_rt_mutex_waiters(struct rt_mutex_base *lock) unsigned long owner, *p = (unsigned long *) &lock->owner; do { - owner = *p; + owner = READ_ONCE(*p); } while (cmpxchg_relaxed(p, owner, owner | RT_MUTEX_HAS_WAITERS) != owner); -- 2.25.1

1 year, 9 months

9
23
0 0

[PATCH v2] Input: xen-kbdfront - drop keys to shrink modalias

by Jason Andryuk

xen kbdfront registers itself as being able to deliver *any* key since it doesn't know what keys the backend may produce. Unfortunately, the generated modalias gets too large and uevent creation fails with -ENOMEM. This can lead to gdm not using the keyboard since there is no seat associated [1] and the debian installer crashing [2]. Trim the ranges of key capabilities by removing some BTN_* ranges. While doing this, some neighboring undefined ranges are removed to trim it further. An upper limit of KEY_KBD_LCD_MENU5 is still too large. Use an upper limit of KEY_BRIGHTNESS_MENU. This removes: BTN_DPAD_UP(0x220)..BTN_DPAD_RIGHT(0x223) Empty space 0x224..0x229 Empty space 0x28a..0x28f KEY_MACRO1(0x290)..KEY_MACRO30(0x2ad) KEY_MACRO_RECORD_START 0x2b0 KEY_MACRO_RECORD_STOP 0x2b1 KEY_MACRO_PRESET_CYCLE 0x2b2 KEY_MACRO_PRESET1(0x2b3)..KEY_MACRO_PRESET3(0xb5) Empty space 0x2b6..0x2b7 KEY_KBD_LCD_MENU1(0x2b8)..KEY_KBD_LCD_MENU5(0x2bc) Empty space 0x2bd..0x2bf BTN_TRIGGER_HAPPY(0x2c0)..BTN_TRIGGER_HAPPY40(0x2e7) Empty space 0x2e8..0x2ff The modalias shrinks from 2082 to 1550 bytes. A chunk of keys need to be removed to allow the keyboard to be used. This may break some functionality, but the hope is these macro keys are uncommon and don't affect any users. [1] https://github.com/systemd/systemd/issues/22944 [2] https://lore.kernel.org/xen-devel/87o8dw52jc.fsf@vps.thesusis.net/T/ Cc: Phillip Susi <phill(a)thesusis.net> Cc: stable(a)vger.kernel.org Signed-off-by: Jason Andryuk <jandryuk(a)gmail.com> --- drivers/input/misc/xen-kbdfront.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) v2: Remove more keys: v1 didn't remove enough and modalias was still broken. diff --git a/drivers/input/misc/xen-kbdfront.c b/drivers/input/misc/xen-kbdfront.c index 8d8ebdc2039b..4ecb579df748 100644 --- a/drivers/input/misc/xen-kbdfront.c +++ b/drivers/input/misc/xen-kbdfront.c @@ -256,7 +256,14 @@ static int xenkbd_probe(struct xenbus_device *dev, __set_bit(EV_KEY, kbd->evbit); for (i = KEY_ESC; i < KEY_UNKNOWN; i++) __set_bit(i, kbd->keybit); - for (i = KEY_OK; i < KEY_MAX; i++) + /* In theory we want to go KEY_OK..KEY_MAX, but that grows the + * modalias line too long. There is a gap of buttons from + * BTN_DPAD_UP..BTN_DPAD_RIGHT and KEY_ALS_TOGGLE is the next + * defined. Then continue up to KEY_BRIGHTNESS_MENU as an upper + * limit. */ + for (i = KEY_OK; i < BTN_DPAD_UP; i++) + __set_bit(i, kbd->keybit); + for (i = KEY_ALS_TOGGLE; i <= KEY_BRIGHTNESS_MENU; i++) __set_bit(i, kbd->keybit); ret = input_register_device(kbd); -- 2.38.1

1 year, 9 months

2
4
0 0

Google Pixelbook EVE, no sound in kernel 6.1.x

by Sasa Ostrouska

Hi all, sorry if I put somebody in CC who is not the correct one. I have a google pixelbook and using it with Fedora 37. The last few kernels supplied by fedora 37, 6.1.6, 6.1.7 but also some earlier have no working sound. I see the last kernel for me with working sound is 6.0.18. On my pixelbook this is showing in dmesg: [ 7.623064] snd_soc_skl 0000:00:1f.3: ASoC: no sink widget found for AEC Capture [ 7.623070] snd_soc_skl 0000:00:1f.3: ASoC: Failed to add route echo_ref_out cpr 7 -> direct -> AEC Capture [ 7.623083] kbl_r5514_5663_max kbl_r5514_5663_max: ASoC: Parent card not yet available, widget card binding deferred [ 8.090716] NET: Registered PF_QIPCRTR protocol family [ 8.273905] rt5663 i2c-10EC5663:00: sysclk < 384 x fs, disable i2s asrc [ 8.275043] HDMI HDA Codec ehdaudio0D2: hdac_hdmi_present_sense: disconnect for pin:port 5:0 [ 8.275165] HDMI HDA Codec ehdaudio0D2: hdac_hdmi_present_sense: disconnect for pin:port 6:0 [ 8.275291] HDMI HDA Codec ehdaudio0D2: hdac_hdmi_present_sense: disconnect for pin:port 7:0 [ 8.278569] input: kbl-r5514-5663-max Headset Jack as /devices/platform/kbl_r5514_5663_max/sound/card0/input30 [ 8.278771] input: kbl-r5514-5663-max HDMI/DP,pcm=6 Jack as /devices/platform/kbl_r5514_5663_max/sound/card0/input31 [ 8.278875] input: kbl-r5514-5663-max HDMI/DP,pcm=7 Jack as /devices/platform/kbl_r5514_5663_max/sound/card0/input32 [ 8.891244] iwlwifi 0000:01:00.0: Applying debug destination EXTERNAL_DRAM [ 8.902009] r8152 2-2.1:1.0 enp0s20f0u2u1: carrier on [ 8.977070] iwlwifi 0000:01:00.0: Applying debug destination EXTERNAL_DRAM [ 8.978496] iwlwifi 0000:01:00.0: FW already configured (0) - re-configuring [ 8.991112] IPv6: ADDRCONF(NETDEV_CHANGE): enp0s20f0u2u1: link becomes ready [ 9.027053] iwlwifi 0000:01:00.0: Applying debug destination EXTERNAL_DRAM [ 9.112264] iwlwifi 0000:01:00.0: Applying debug destination EXTERNAL_DRAM [ 9.113562] iwlwifi 0000:01:00.0: FW already configured (0) - re-configuring [ 14.579846] HDMI HDA Codec ehdaudio0D2: No connections found for pin:port 5:0 Can please somebody help with this issue ? Also in the latests kernels the shutdown stops and the machine does not halt. It stays forever waiting for something to happen it seems. If you need more details please dont hesitate to contact me. And please CC me as I am not subscribed in these miling lists. Rgds Sasa

1 year, 10 months

4
14
0 0

[PATCH 2/7] usb: xhci: Check endpoint is valid before dereferencing it

by Mathias Nyman

From: Jimmy Hu <hhhuuu(a)google.com> When the host controller is not responding, all URBs queued to all endpoints need to be killed. This can cause a kernel panic if we dereference an invalid endpoint. Fix this by using xhci_get_virt_ep() helper to find the endpoint and checking if the endpoint is valid before dereferencing it. [233311.853271] xhci-hcd xhci-hcd.1.auto: xHCI host controller not responding, assume dead [233311.853393] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000e8 [233311.853964] pc : xhci_hc_died+0x10c/0x270 [233311.853971] lr : xhci_hc_died+0x1ac/0x270 [233311.854077] Call trace: [233311.854085] xhci_hc_died+0x10c/0x270 [233311.854093] xhci_stop_endpoint_command_watchdog+0x100/0x1a4 [233311.854105] call_timer_fn+0x50/0x2d4 [233311.854112] expire_timers+0xac/0x2e4 [233311.854118] run_timer_softirq+0x300/0xabc [233311.854127] __do_softirq+0x148/0x528 [233311.854135] irq_exit+0x194/0x1a8 [233311.854143] __handle_domain_irq+0x164/0x1d0 [233311.854149] gic_handle_irq.22273+0x10c/0x188 [233311.854156] el1_irq+0xfc/0x1a8 [233311.854175] lpm_cpuidle_enter+0x25c/0x418 [msm_pm] [233311.854185] cpuidle_enter_state+0x1f0/0x764 [233311.854194] do_idle+0x594/0x6ac [233311.854201] cpu_startup_entry+0x7c/0x80 [233311.854209] secondary_start_kernel+0x170/0x198 Fixes: 50e8725e7c42 ("xhci: Refactor command watchdog and fix split string.") Cc: stable(a)vger.kernel.org Signed-off-by: Jimmy Hu <hhhuuu(a)google.com> Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com> --- drivers/usb/host/xhci-ring.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c index ddc30037f9ce..f5b0e1ce22af 100644 --- a/drivers/usb/host/xhci-ring.c +++ b/drivers/usb/host/xhci-ring.c @@ -1169,7 +1169,10 @@ static void xhci_kill_endpoint_urbs(struct xhci_hcd *xhci, struct xhci_virt_ep *ep; struct xhci_ring *ring; - ep = &xhci->devs[slot_id]->eps[ep_index]; + ep = xhci_get_virt_ep(xhci, slot_id, ep_index); + if (!ep) + return; + if ((ep->ep_state & EP_HAS_STREAMS) || (ep->ep_state & EP_GETTING_NO_STREAMS)) { int stream_id; -- 2.25.1

1 year, 10 months

4
6
0 0

tcpci module in Kernel 5.15.74 with PTN5110 not working correctly

by Christian Bach

Hello For a few weeks now I am trying to make the PTN5110 chip work with the new Kernel 5.15.74. The same hardware setup was working with the 4.19.72 Kernel. The steps I took so far are as follows: 1. Study the Documentation and look at example Device Tree's in the Kernel 2. Try out different Device Tree configurations derived from the Documentation and examples 3. I did look on Stackoverflow, the NXP and other forums for any similar issue but could not find any 4. Updating the Kernel to the newest Version I was able to find: 5.15.74 (Hash: f0bee94053065c7cb8eacadfdd6bf739a2042b35 in Repo: git://git.yoctoproject.org/linux-yocto.git;branch=v5.15/standard/base) 5. Downgrade to the earliest Kernel possible: v5.10-rc1 (Hash: 3650b228f83adda7e5ee532e2b90429c03f7b9ec in Repo: git://git.yoctoproject.org/linux-yocto.git;branch=v5.15/standard/base) None of those steps had any effect. Every time I plug in a USB-A to USB-C cable the Kernel gets stuck in the ISR until I unplug the cable. (Attaching a full USB-PD capable Power Source over a USB-C cable works fine) This results in an unreasonable high CPU usage (most of the times the CPU gets blocked completely). I did analyze the I2C bus and found that the old Kernel did change many configurations after the A-C cable got attached while the new Kernel does nothing (please see logs below). I also did compare what happens on the I2C bus during chip initialization but did not find any mentionable differences. My HW setup is an i.mx6ul with the PTN5110 attached on I2C4. ================================================= My device tree looks like this: / { regulators { compatible = "simple-bus"; #address-cells = <1>; #size-cells = <0>; reg_usb_otg1_vbus: regulator@2 { compatible = "regulator-fixed"; reg = <2>; regulator-name = "usb_otg1_vbus"; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_usb_otg1_vbus>; regulator-min-microvolt = <5000000>; regulator-max-microvolt = <5000000>; gpio = <&gpio2 8 GPIO_ACTIVE_HIGH>; enable-active-high; status = "okay"; }; }; }; &usbotg1 { /*pinctrl-names = "default"; pinctrl-0 = <&pinctrl_usbotg1>;*/ dr_mode = "otg"; status = "okay"; disable-over-current; vbus-supply = <&reg_usb_otg1_vbus>; }; &i2c4 { clock-frequency = <100000>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_i2c4>; status = "okay"; usb_pd: ptn5110@50 { compatible = "nxp,ptn5110"; reg = <0x50>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_usb_pd>; interrupt-parent = <&gpio2>; interrupts = <11 IRQ_TYPE_LEVEL_LOW>; wakeup-source; usb_con: connector { compatible = "usb-c-connector"; label = "USB-C"; data-role = "dual"; power-role = "dual"; try-power-role = "sink"; source-pdos = <PDO_FIXED(VSAFE5V, 2000, PDO_FIXED_USB_COMM | PDO_FIXED_DUAL_ROLE)>; sink-pdos = <PDO_FIXED(VSAFE5V, 2000, PDO_FIXED_USB_COMM | PDO_FIXED_DUAL_ROLE) //PDO_FIXED(VSAFE5V, 3000, 0) //PDO_FIXED(9000, 3000, 0) PDO_FIXED(12000, 3000, 0) PDO_FIXED(20000, 3000, 0)>; //PDO_FIXED(20000, 5000, 0)>; op-sink-microwatt = <10000000>; }; }; }; &iomuxc { pinctrl_i2c4: i2c4grp { fsl,pins = < MX6UL_PAD_UART2_TX_DATA__I2C4_SCL 0x4001b8b0 MX6UL_PAD_UART2_RX_DATA__I2C4_SDA 0x4001b8b0 >; }; pinctrl_usb_pd: usbpdgrp { fsl,pins = < MX6UL_PAD_ENET2_TX_DATA0__GPIO2_IO11 0x0001b020 /* Alert Interrupt */ MX6UL_PAD_ENET2_TX_CLK__GPIO2_IO14 0x0001b020 /* Fault Interrupt */ >; }; pinctrl_usb_otg1_vbus: usbotg1 { fsl,pins = < MX6UL_PAD_ENET2_RX_DATA0__GPIO2_IO08 0x000000b9 MX6UL_PAD_ENET2_RX_DATA1__USB_OTG1_OC 0x000010b0 >; }; }; ================================================= I2C Log on plug in event of Kernel 5.15.68: Direction | Address | Data ------------------------------- Read | 10 | 02 22 Write | 10 | 02 22 Read | 14 | 04 Read | 10 | 02 02 Write | 10 | 02 02 Read | 1E | 0C Read | 14 | 04 Read | 10 | 03 02 Write | 10 | 03 02 Read | 1E | 0C Read | 1A | 4A Read | 14 | 04 Read | 1D | 11 Read | 1E | 0C Pause for 200ms Read | 1A | 4A Read | 1A | 4A Read | 1D | 11 Write | 1A | 0E Write | 19 | 00 Write | 2E | 02 Write | 23 | 66 Write | 23 | 55 Write | 2F | 21 Pause for 300ms Write | 51 | 02 Write | 52 | 00 00 Write | 50 | 25 Read | 10 | 50 02 Write | 10 | 50 02 Read | 10 | 00 02 Write | 10 | 00 02 Write | 72 | 8C 00 Read | 1C | 60 Read | 10 | 00 02 Write | 10 | 00 02 Write | 2F | 00 Read | 1C | 60 Read | 10 | 00 02 Write | 10 | 00 02 Write | 2E | 02 Read | 10 | 00 02 Write | 10 | 00 02 Read | 10 | 00 02 Write | 10 | 00 02 Read | 10 | 00 02 Write | 10 | 00 02 Read | 10 | 00 02 Write | 10 | 00 02 (It will loop like this until the cable gets detached) I2C Log on plug in event of Kernel 5.15.68: Direction | Address | Data ------------------------------- Read | 10 | 02 22 Write | 10 | 02 22 Read | 14 | 04 Read | 10 | 02 02 Write | 10 | 02 02 Read | 1E | 0C Read | 14 | 04 Read | 10 | 02 02 Write | 10 | 02 02 Read | 1E | 0C Read | 14 | 04 Read | 1E | 0C Pause for 200ms Read | 10 | 01 02 Write | 10 | 01 02 Read | 1D | 11 Pause for 250ms Read | 1A | 4A Write | 1A | 4E Write | 19 | 00 Write | 2E | 02 Write | 23 | 66 Write | 23 | 55 Write | 2F | 21 Pause for 4ms Write | 51 | 02 Write | 52 | 00 00 Write | 50 | 35 Read | 10 | 50 02 Write | 10 | 50 02 Read | 10 | 00 02 Write | 10 | 00 02 Write | 2F | 00 Read | 10 | 00 02 Write | 10 | 00 02 Read | 1C | 60 Read | 10 | 00 02 Write | 10 | 00 02 Write | 23 | 66 Read | 10 | 02 02 Write | 10 | 02 02 Write | 23 | 44 Read | 14 | FF Write | 2E | 02 Read | 1E | 0C Write | 10 | FF FF Write | 14 | 04 Write | 23 | 33 Write | 12 | 7F 00 Write | 2F | 00 Write | 23 | 66 Write | 23 | 44 Read | 1C | 60 Read | 1A | 4E Write | 1A | 4E Write | 19 | 00 Write | 2E | 02 Read | 1E | 0C Read | 1D | 11 Write | 2F | 00 Write | 23 | 66 Write | 23 | 44 Read | 1C | 60 Read | 1A | 4E Write | 1A | 4E Write | 19 | 00 Write | 2E | 02 Write | 1A | 0F Read | 10 | 01 02 Write | 10 | 01 02 Read | 1D | 00 Write | 1A | 4A Write | 23 | 99 Read | 10 | 01 02 Write | 10 | 01 02 Read | 1D | 11 (no more communication after this point) -- Dipl. El-Ing. FH Christian Bach, Projektleiter Direct +41 43 456 16 96 . http://www.scs.ch Supercomputing Systems AG . Technoparkstrasse 1 . CH-8005 Zürich

1 year, 10 months

3
9
0 0

[PATCH 0/6] hwpoison, shmem, hugetlb: fix data loss issue 5.10.y

by Mike Kravetz

This is a request for adding the following patches to stable 5.10.y. Poisoned shmem and hugetlb pages are removed from the pagecache. Subsequent access to the offset in the file results in a NEW zero filled page. Application code does not get notified of the data loss, and the only 'clue' is a message in the system log. Data loss has been experienced by real users. This was addressed upstream. Most commits were marked for backports, but some were not. This was discussed here [1] and here [2]. Patches apply cleanly to v5.4.224 and pass tests checking for this specific data loss issue. LTP mm tests show no regressions. All patches except 4 "mm: hwpoison: handle non-anonymous THP correctly" required a small bit of change to apply correctly: mostly for context. linux-mm Cc'ed as it would be great to get at least an ACK from others familiar with this issue. [1] https://lore.kernel.org/linux-mm/Y2UTUNBHVY5U9si2@monkey/ [2] https://lore.kernel.org/stable/20221114131403.GA3807058@u2004/ James Houghton (1): hugetlbfs: don't delete error page from pagecache Yang Shi (5): mm: hwpoison: remove the unnecessary THP check mm: filemap: check if THP has hwpoisoned subpage for PMD page fault mm: hwpoison: refactor refcount check handling mm: hwpoison: handle non-anonymous THP correctly mm: shmem: don't truncate page if memory failure happens fs/hugetlbfs/inode.c | 13 ++-- include/linux/page-flags.h | 23 ++++++ mm/huge_memory.c | 2 + mm/hugetlb.c | 4 + mm/memory-failure.c | 153 ++++++++++++++++++++++++------------- mm/memory.c | 9 +++ mm/page_alloc.c | 4 +- mm/shmem.c | 51 +++++++++++-- 8 files changed, 191 insertions(+), 68 deletions(-) -- 2.38.1

1 year, 10 months

2
7
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror January 2023