Select Git revision
Search by author
- Any Author
- authors
-
Alexander Arndt
aarndt
-
Andreas Findeklee afindeklee
-
Annette Kobou akobou
-
Armin Mück amueck
-
**** project_143_bot_c8bbc40375b18788e4765d3c396612d5
-
Daniel Ehrler dehrler
-
Devran Ölcer doelcer
-
Dieter Scheufele dscheufele
-
Dietmar Kolbus dkolbus
-
Dominik Wurster Wurster
-
Eberhard Stoll estoll
-
Florian Mayer fmayer
-
Frieder Schrempf
fschrempf
-
Julian Bauknecht jbauknecht
-
Jó Bitsch jbitsch
-
Jürgen Kling
jgkling
-
Klemenz Christof kchristof
-
Lukas Loosli lloosli
-
Marc Gonser mgonser
-
Markus Abegg mabegg
- Dec 05, 2024
-
-
Marco Elver authored
[ Upstream commit 5c1806c41ce0a0110db5dd4c483cf2dc28b3ddf0 ] While fuzzing an arm64 kernel, Alexander Potapenko reported: | BUG: KCSAN: data-race in ktime_get_mono_fast_ns / timekeeping_update | | write to 0xffffffc082e74248 of 56 bytes by interrupt on cpu 0: | update_fast_timekeeper kernel/time/timekeeping.c:430 [inline] | timekeeping_update+0x1d8/0x2d8 kernel/time/timekeeping.c:768 | timekeeping_advance+0x9e8/0xb78 kernel/time/timekeeping.c:2344 | update_wall_time+0x18/0x38 kernel/time/timekeeping.c:2360 | [...] | | read to 0xffffffc082e74258 of 8 bytes by task 5260 on cpu 1: | __ktime_get_fast_ns kernel/time/timekeeping.c:372 [inline] | ktime_get_mono_fast_ns+0x88/0x174 kernel/time/timekeeping.c:489 | init_srcu_struct_fields+0x40c/0x530 kernel/rcu/srcutree.c:263 | init_srcu_struct+0x14/0x20 kernel/rcu/srcutree.c:311 | [...] | | value changed: 0x000002f875d33266 -> 0x000002f877416866 | | Reported by Kernel Concurrency Sanitizer on: | CPU: 1 UID: 0 PID: 5260 Comm: syz.2.7483 Not tainted 6.12.0-rc3-dirty #78 This is a false positive data race between a seqcount latch writer and a reader accessing stale data. Since its introduction, KCSAN has never understood the seqcount_latch interface (due to being unannotated). Unlike the regular seqlock interface, the seqcount_latch interface for latch writers never has had a well-defined critical section, making it difficult to teach tooling where the critical section starts and ends. Introduce an instrumentable (non-raw) seqcount_latch interface, with which we can clearly denote writer critical sections. This both helps readability and tooling like KCSAN to understand when the writer is done updating all latch copies. Fixes: 88ecd153 ("seqlock, kcsan: Add annotations for KCSAN") Reported-by:
Alexander Potapenko <glider@google.com> Co-developed-by:
"Peter Zijlstra (Intel)" <peterz@infradead.org> Signed-off-by:
Marco Elver <elver@google.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Uros Bizjak authored
[ Upstream commit 25cf4fbb596d730476afcc0fb87a9d708db14078 ] x86_32 __arch_{,try_}cmpxchg64_emu()() macros use CALL instruction inside asm statement. Use ALT_OUTPUT_SP() macro to add required dependence on %esp register. Fixes: 79e1dd05 ("x86: Provide an alternative() based cmpxchg64()") Signed-off-by:Uros Bizjak <ubizjak@gmail.com> Signed-off-by:
-
Uros Bizjak authored
[ Upstream commit 8b64db9733c2e4d30fd068d0b9dcef7b4424b035 ] CONFIG_X86_CMPXCHG64 variant of x86_32 __alternative_atomic64() macro uses CALL instruction inside asm statement. Use ALT_OUTPUT_SP() macro to add required dependence on %esp register. Fixes: 819165fb ("x86: Adjust asm constraints in atomic64 wrappers") Signed-off-by:
-
Thomas Gleixner authored
[ Upstream commit 1d4199cbbe95efaba51304cfd844bd0ccd224e61 ] __run_timer_base() checks base::next_expiry without holding base::lock. That can race with a remote CPU updating next_expiry under the lock. This is an intentional and harmless data race, but lacks a READ_ONCE(), so KCSAN complains about this. Add the missing READ_ONCE(). All other places are covered already. Fixes: 79f8b28e ("timers: Annotate possible non critical data race of next_expiry") Reported-by:
kernel test robot <oliver.sang@intel.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Reviewed-by:
Frederic Weisbecker <frederic@kernel.org> Link: https://lore.kernel.org/all/87a5emyqk0.ffs@tglx Closes: https://lore.kernel.org/oe-lkp/202410301205.ef8e9743-lkp@intel.com Signed-off-by:
-
Miguel Ojeda authored
[ Upstream commit 92b043fd995a63a57aae29ff85a39b6f30cd440c ] The details about the handling of the "normal" values were moved to the _msecs_to_jiffies() helpers in commit ca42aaf0 ("time: Refactor msecs_to_jiffies"). However, the same commit still mentioned __msecs_to_jiffies() in the added documentation. Thus point to _msecs_to_jiffies() instead. Fixes: ca42aaf0 ("time: Refactor msecs_to_jiffies") Signed-off-by:
Miguel Ojeda <ojeda@kernel.org> Signed-off-by:
-
Miguel Ojeda authored
[ Upstream commit b05aefc1f5886c8aece650c9c1639c87b976191a ] The documentation's intention is to compare msecs_to_jiffies() (first sentence) with __msecs_to_jiffies() (second sentence), which is what the original documentation did. One of the cleanups in commit f3cb8080 ("time: Fix various kernel-doc problems") may have thought the paragraph was talking about the latter since that is what it is being documented. Thus revert that part of the change. Fixes: f3cb8080 ("time: Fix various kernel-doc problems") Signed-off-by:
-
Uros Bizjak authored
[ Upstream commit f730fd535fc51573f982fad629f2fc6b4a0cde2f ] Guard functions in local_lock.h are defined using DEFINE_GUARD() and DEFINE_LOCK_GUARD_1() macros having lock type defined as pointer in the percpu address space. The functions, defined by these macros return value in generic address space, causing: cleanup.h:157:18: error: return from pointer to non-enclosed address space and cleanup.h:214:18: error: return from pointer to non-enclosed address space when strict percpu checks are enabled. Add explicit casts to remove address space of the returned pointer. Found by GCC's named address space checks. Fixes: e4ab322f ("cleanup: Add conditional guard support") Signed-off-by:
-
Carlos Llamas authored
[ Upstream commit 56ac7bd2c58a4e93d19f0ccb181035d075b315d3 ] This reverts commit c02904f0. Such commit assumed that only two symbols are relevant for the symbol size calculation. However, this can lead to an incorrect symbol size calculation when there are mapping symbols emitted by readelf. For instance, when feeding 'update_irq_load_avg+0x1c/0x1c4', faddr2line might need to process the following readelf lines: 784284: ffffffc0081cca30 428 FUNC GLOBAL DEFAULT 2 update_irq_load_avg 87319: ffffffc0081ccb0c 0 NOTYPE LOCAL DEFAULT 2 $x.62522 87321: ffffffc0081ccbdc 0 NOTYPE LOCAL DEFAULT 2 $x.62524 87323: ffffffc0081ccbe0 0 NOTYPE LOCAL DEFAULT 2 $x.62526 87325: ffffffc0081ccbe4 0 NOTYPE LOCAL DEFAULT 2 $x.62528 87327: ffffffc0081ccbe8 0 NOTYPE LOCAL DEFAULT 2 $x.62530 87329: ffffffc0081ccbec 0 NOTYPE LOCAL DEFAULT 2 $x.62532 87331: ffffffc0081ccbf0 0 NOTYPE LOCAL DEFAULT 2 $x.62534 87332: ffffffc0081ccbf4 0 NOTYPE LOCAL DEFAULT 2 $x.62535 783403: ffffffc0081ccbf4 424 FUNC GLOBAL DEFAULT 2 sched_pelt_multiplier The symbol size of 'update_irq_load_avg' should be calculated with the address of 'sched_pelt_multiplier', after skipping the mapping symbols seen in between. However, the offending commit cuts the list short and faddr2line incorrectly assumes 'update_irq_load_avg' is the last symbol in the section, resulting in: $ scripts/faddr2line vmlinux update_irq_load_avg+0x1c/0x1c4 skipping update_irq_load_avg address at 0xffffffc0081cca4c due to size mismatch (0x1c4 != 0x3ff9a59988) no match for update_irq_load_avg+0x1c/0x1c4 After reverting the commit the issue is resolved: $ scripts/faddr2line vmlinux update_irq_load_avg+0x1c/0x1c4 update_irq_load_avg+0x1c/0x1c4: cpu_of at kernel/sched/sched.h:1109 (inlined by) update_irq_load_avg at kernel/sched/pelt.c:481 Fixes: c02904f0 ("scripts/faddr2line: Check only two symbols when calculating symbol size") Signed-off-by:
Carlos Llamas <cmllamas@google.com> Acked-by:
Will Deacon <will@kernel.org> Acked-by:
Brian Johannesmeyer <bjohannesmeyer@gmail.com> Signed-off-by:
Josh Poimboeuf <jpoimboe@kernel.org> Signed-off-by:
-
Zheng Yejian authored
[ Upstream commit 3bf19a0fb690022ec22ce87a5afeb1030cbcb56c ] When arch_stack_walk_reliable() is called to unwind for newly forked tasks, the return value is negative which means the call stack is unreliable. This obviously does not meet expectations. The root cause is that after commit 3aec4ecb ("x86: Rewrite ret_from_fork() in C"), the 'ret_addr' of newly forked task is changed to 'ret_from_fork_asm' (see copy_thread()), then at the start of the unwind, it is incorrectly interprets not as a "signal" one because 'ret_from_fork' is still used to determine the initial "signal" (see __unwind_start()). Then the address gets incorrectly decremented in the call to orc_find() (see unwind_next_frame()) and resulting in the incorrect ORC data. To fix it, check 'ret_from_fork_asm' rather than 'ret_from_fork' in __unwind_start(). Fixes: 3aec4ecb ("x86: Rewrite ret_from_fork() in C") Signed-off-by:
Zheng Yejian <zhengyejian@huaweicloud.com> Signed-off-by:
-
Daniel Lezcano authored
[ Upstream commit 7569406e95f2353070d88ebc88e8c13698542317 ] The function thermal_genl_auto() does not free the allocated message in the error path. Fix that by putting a out label and jump to it which will free the message instead of directly returning an error. Fixes: 47c4b0de ("tools/lib/thermal: Add a thermal library") Reported-by:
Lukasz Luba <lukasz.luba@arm.com> Signed-off-by:
Daniel Lezcano <daniel.lezcano@linaro.org> Reviewed-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Daniel Lezcano authored
[ Upstream commit 24b216b2d13568c703a76137ef54a2a9531a71d8 ] The thermal netlink has been extended with more commands which require an encoding with more information. The generic encoding function puts the thermal zone id with the command name. It is the unique parameters. The next changes will provide more parameters to the command. Set the scene for those new parameters by making the encoding function more generic. Signed-off-by:
-
Uladzislau Rezki (Sony) authored
[ Upstream commit 812a1c3b9f7c36d9255f0d29d0a3d324e2f52321 ] A static analyzer for C, Smatch, reports and triggers below warnings: kernel/rcu/rcuscale.c:1215 rcu_scale_init() warn: inconsistent returns 'global &fullstop_mutex'. The checker complains about, we do not unlock the "fullstop_mutex" mutex, in case of hitting below error path: <snip> ... if (WARN_ON_ONCE(jiffies_at_lazy_cb - jif_start < 2 * HZ)) { pr_alert("ERROR: call_rcu() CBs are not being lazy as expected!\n"); WARN_ON_ONCE(1); return -1; ^^^^^^^^^^ ... <snip> it happens because "-1" is returned right away instead of doing a proper unwinding. Fix it by jumping to "unwind" label instead of returning -1. Reported-by:Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by:
Paul E. McKenney <paulmck@kernel.org> Reviewed-by:
Neeraj Upadhyay <Neeraj.Upadhyay@amd.com> Closes: https://lore.kernel.org/rcu/ZxfTrHuEGtgnOYWp@pc636/T/ Fixes: 084e04ff ("rcuscale: Add laziness and kfree tests") Signed-off-by:
Uladzislau Rezki (Sony) <urezki@gmail.com> Signed-off-by:
-
Christophe JAILLET authored
[ Upstream commit 572b7cf08403b6c67dfe0dc3e0f2efb42443254f ] If do_cpt_init() fails, a previous dma_alloc_coherent() call needs to be undone. Add the needed dma_free_coherent() before returning. Fixes: 9e2c7d99 ("crypto: cavium - Add Support for Octeon-tx CPT Engine") Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Chen Ridong authored
[ Upstream commit 19630cf57233e845b6ac57c9c969a4888925467b ] The ahash_init functions may return fails. The ahash_hmac_init should not return ok when ahash_init returns error. For an example, ahash_init will return -ENOMEM when allocation memory is error. Fixes: 9d12ba86 ("crypto: brcm - Add Broadcom SPU driver") Signed-off-by:
Chen Ridong <chenridong@huawei.com> Signed-off-by:
-
Chen Ridong authored
[ Upstream commit b64140c74e954f1db6eae5548ca3a1f41b6fad79 ] The caam_rsa_set_priv_key_form did not check for memory allocation errors. Add the checks to the caam_rsa_set_priv_key_form functions. Fixes: 52e26d77 ("crypto: caam - add support for RSA key form 2") Signed-off-by:
Gaurav Jain <gaurav.jain@nxp.com> Reviewed-by:
Horia Geantă <horia.geanta@nxp.com> Signed-off-by:
-
Rafael J. Wysocki authored
[ Upstream commit 0104dcdaad3a7afd141e79a5fb817a92ada910ac ] Variables annotated with __free() need to be initialized if the function can return before they get updated for the first time or the attempt to free the memory pointed to by them upon function return may crash the kernel. Fix this issue in some places in the thermal testing code. Fixes: f6a034f2 ("thermal: Introduce a debugfs-based testing facility") Reported-by:
-
Rafael J. Wysocki authored
[ Upstream commit 1c426fd09ca85fb77f120f7933e39eb9df99a39a ] Use DEFINE_FREE() to define a __free function for dropping thermal zone template reference counters and use it along with __free() to simplify code in some places. No intentional functional impact. Signed-off-by:
-
Lifeng Zheng authored
[ Upstream commit 2388b266c9fcc7c9169ba85c7f9ebe325b7622d7 ] Since commit 60949b7b ("ACPI: CPPC: Fix MASK_VAL() usage"), _CPC registers cannot be changed from 1 to 0. It turns out that there is an extra OR after MASK_VAL_WRITE(), which has already ORed prev_val with the register mask. Remove the extra OR to fix the problem. Fixes: 60949b7b ("ACPI: CPPC: Fix MASK_VAL() usage") Signed-off-by:
Lifeng Zheng <zhenglifeng1@huawei.com> Link: https://patch.msgid.link/20241113103309.761031-1-zhenglifeng1@huawei.com [ rjw: Subject and changelog edits ] Signed-off-by:
-
Pei Xiao authored
[ Upstream commit 57ee12b6c514146c19b6a159013b48727a012960 ] DIV_ROUND_CLOSEST() after kstrtoul() results in an overflow if a large number such as 18446744073709551615 is provided by the user. Fix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations. Signed-off-by:
Pei Xiao <xiaopei01@kylinos.cn> Fixes: c3963bc0 ("hwmon: (nct6775) Split core and platform driver") Message-ID: <7d5084cea33f7c0fd0578c59adfff71f93de94d9.1731375425.git.xiaopei01@kylinos.cn> Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Jerome Brunet authored
[ Upstream commit 509c3a362675bc995771df74d545548f98e37621 ] pmbus_write_smbalert_mask() ignores the errors if the chip can't set smbalert mask the standard way. It is not necessarily a problem for the irq support if the chip is otherwise properly setup but it may leave an uncleared fault behind. pmbus_core will pick the fault on the next register_check(). The register check will fails regardless of the actual register support by the chip. This leads to missing attributes or debugfs entries for chips that should provide them. We cannot rely on register_check() as PMBUS_SMBALERT_MASK may be read-only. Unconditionally clear the page fault after setting PMBUS_SMBALERT_MASK to avoid the problem. Suggested-by:
Jerome Brunet <jbrunet@baylibre.com> Message-ID: <20241105-tps25990-v4-5-0e312ac70b62@baylibre.com> Signed-off-by:
-
Zqiang authored
[ Upstream commit 2996980e20b7a54a1869df15b3445374b850b155 ] Currently, running rcutorture test with torture_type=rcu fwd_progress=8 n_barrier_cbs=8 nocbs_nthreads=8 nocbs_toggle=100 onoff_interval=60 test_boost=2, will trigger the following warning: WARNING: CPU: 19 PID: 100 at kernel/rcu/tree_nocb.h:1061 rcu_nocb_rdp_deoffload+0x292/0x2a0 RIP: 0010:rcu_nocb_rdp_deoffload+0x292/0x2a0 Call Trace: <TASK> ? __warn+0x7e/0x120 ? rcu_nocb_rdp_deoffload+0x292/0x2a0 ? report_bug+0x18e/0x1a0 ? handle_bug+0x3d/0x70 ? exc_invalid_op+0x18/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? rcu_nocb_rdp_deoffload+0x292/0x2a0 rcu_nocb_cpu_deoffload+0x70/0xa0 rcu_nocb_toggle+0x136/0x1c0 ? __pfx_rcu_nocb_toggle+0x10/0x10 kthread+0xd1/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2f/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> CPU0 CPU2 CPU3 //rcu_nocb_toggle //nocb_cb_wait //rcutorture // deoffload CPU1 // process CPU1's rdp rcu_barrier() rcu_segcblist_entrain() rcu_segcblist_add_len(1); // len == 2 // enqueue barrier // callback to CPU1's // rdp->cblist rcu_do_batch() // invoke CPU1's rdp->cblist // callback rcu_barrier_callback() rcu_barrier() mutex_lock(&rcu_state.barrier_mutex); // still see len == 2 // enqueue barrier callback // to CPU1's rdp->cblist rcu_segcblist_entrain() rcu_segcblist_add_len(1); // len == 3 // decrement len rcu_segcblist_add_len(-2); kthread_parkme() // CPU1's rdp->cblist len == 1 // Warn because there is // still a pending barrier // trigger warning WARN_ON_ONCE(rcu_segcblist_n_cbs(&rdp->cblist)); cpus_read_unlock(); // wait CPU1 to comes online and // invoke barrier callback on // CPU1 rdp's->cblist wait_for_completion(&rcu_state.barrier_completion); // deoffload CPU4 cpus_read_lock() rcu_barrier() mutex_lock(&rcu_state.barrier_mutex); // block on barrier_mutex // wait rcu_barrier() on // CPU3 to unlock barrier_mutex // but CPU3 unlock barrier_mutex // need to wait CPU1 comes online // when CPU1 going online will block on cpus_write_lock The above scenario will not only trigger a WARN_ON_ONCE(), but also trigger a deadlock. Thanks to nocb locking, a second racing rcu_barrier() on an offline CPU will either observe the decremented callback counter down to 0 and spare the callback enqueue, or rcuo will observe the new callback and keep rdp->nocb_cb_sleep to false. Therefore check rdp->nocb_cb_sleep before parking to make sure no further rcu_barrier() is waiting on the rdp. Fixes: 1fcb932c ("rcu/nocb: Simplify (de-)offloading state machine") Suggested-by:Zqiang <qiang.zhang1211@gmail.com> Reviewed-by:
-
Uladzislau Rezki (Sony) authored
[ Upstream commit a23da88c6c80e41e0503e0b481a22c9eea63f263 ] KCSAN reports a data race when access the krcp->monitor_work.timer.expires variable in the schedule_delayed_monitor_work() function: <snip> BUG: KCSAN: data-race in __mod_timer / kvfree_call_rcu read to 0xffff888237d1cce8 of 8 bytes by task 10149 on cpu 1: schedule_delayed_monitor_work kernel/rcu/tree.c:3520 [inline] kvfree_call_rcu+0x3b8/0x510 kernel/rcu/tree.c:3839 trie_update_elem+0x47c/0x620 kernel/bpf/lpm_trie.c:441 bpf_map_update_value+0x324/0x350 kernel/bpf/syscall.c:203 generic_map_update_batch+0x401/0x520 kernel/bpf/syscall.c:1849 bpf_map_do_batch+0x28c/0x3f0 kernel/bpf/syscall.c:5143 __sys_bpf+0x2e5/0x7a0 __do_sys_bpf kernel/bpf/syscall.c:5741 [inline] __se_sys_bpf kernel/bpf/syscall.c:5739 [inline] __x64_sys_bpf+0x43/0x50 kernel/bpf/syscall.c:5739 x64_sys_call+0x2625/0x2d60 arch/x86/include/generated/asm/syscalls_64.h:322 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xc9/0x1c0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f write to 0xffff888237d1cce8 of 8 bytes by task 56 on cpu 0: __mod_timer+0x578/0x7f0 kernel/time/timer.c:1173 add_timer_global+0x51/0x70 kernel/time/timer.c:1330 __queue_delayed_work+0x127/0x1a0 kernel/workqueue.c:2523 queue_delayed_work_on+0xdf/0x190 kernel/workqueue.c:2552 queue_delayed_work include/linux/workqueue.h:677 [inline] schedule_delayed_monitor_work kernel/rcu/tree.c:3525 [inline] kfree_rcu_monitor+0x5e8/0x660 kernel/rcu/tree.c:3643 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0x483/0x9a0 kernel/workqueue.c:3310 worker_thread+0x51d/0x6f0 kernel/workqueue.c:3391 kthread+0x1d1/0x210 kernel/kthread.c:389 ret_from_fork+0x4b/0x60 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Reported by Kernel Concurrency Sanitizer on: CPU: 0 UID: 0 PID: 56 Comm: kworker/u8:4 Not tainted 6.12.0-rc2-syzkaller-00050-g5b7c893ed5ed #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: events_unbound kfree_rcu_monitor <snip> kfree_rcu_monitor() rearms the work if a "krcp" has to be still offloaded and this is done without holding krcp->lock, whereas the kvfree_call_rcu() holds it. Fix it by acquiring the "krcp->lock" for kfree_rcu_monitor() so both functions do not race anymore. Reported-by:
<syzbot+061d370693bdd99f9d34@syzkaller.appspotmail.com> Link: https://lore.kernel.org/lkml/ZxZ68KmHDQYU0yfD@pc636/T/ Fixes: 8fc5494a ("rcu/kvfree: Move need_offload_krc() out of krcp->lock") Signed-off-by:
-
Michal Schmidt authored
[ Upstream commit 0ea3acbc804c2d5a165442cdf9c0526f4d324888 ] Code after the return statement is dead. Enable preemption before returning from srcu_drive_gp(). This will be important when/if PREEMPT_AUTO (lazy resched) gets merged. Fixes: 65b4a595 ("srcu: Make Tiny SRCU explicitly disable preemption") Reviewed-by:
Michal Schmidt <mschmidt@redhat.com> Reviewed-by:
-
Baruch Siach authored
[ Upstream commit 4a09e358922381f9b258e863bcd9c910584203b9 ] The stall warning prints 16 bits since commit 17147677 ("context_tracking: Convert state to atomic_t"). Fixes: 17147677 ("context_tracking: Convert state to atomic_t") Signed-off-by:
Baruch Siach <baruch@tkos.co.il> Reviewed-by:
Neeraj Upadhyay <neeraj.upadhyay@kernel.org> Signed-off-by:
-
Christian Loehle authored
[ Upstream commit 70d8b6485b0bcd135b6699fc4252d2272818d1fb ] Ensure sugov_eas_rebuild_sd() is always called when sugov_init() succeeds. The out goto initialized sugov without forcing the rebuild. Previously the missing call to sugov_eas_rebuild_sd() could lead to EAS not being enabled on boot when it should have been, because it requires all policies to be controlled by schedutil while they might not have been initialized yet. Fixes: e7a1b32e ("cpufreq: Rebuild sched-domains when removing cpufreq driver") Signed-off-by:
Christian Loehle <christian.loehle@arm.com> Link: https://patch.msgid.link/35e572d9-1152-406a-9e34-2525f7548af9@arm.com Signed-off-by:
-
Li Huafei authored
[ Upstream commit a10549fcce2913be7dc581562ffd8ea35653853e ] The commit 320406cb ("crypto: inside-secure - Replace generic aes with libaes") replaced crypto_alloc_cipher() with kmalloc(), but did not modify the handling of the return value. When kmalloc() returns NULL, PTR_ERR_OR_ZERO(NULL) returns 0, but in fact, the memory allocation has failed, and -ENOMEM should be returned. Fixes: 320406cb ("crypto: inside-secure - Replace generic aes with libaes") Signed-off-by:
Li Huafei <lihuafei1@huawei.com> Acked-by:
Antoine Tenart <atenart@kernel.org> Signed-off-by:
-
Wang Hai authored
[ Upstream commit d8920a722a8cec625267c09ed40af8fd433d7f9a ] The adf_init_aer() won't destroy device_reset_wq when alloc_workqueue() for device_sriov_wq failed. Add destroy_workqueue for device_reset_wq to fix this issue. Fixes: 4469f9b2 ("crypto: qat - re-enable sriov after pf reset") Signed-off-by:
Wang Hai <wanghai38@huawei.com> Signed-off-by:
-
Orange Kao authored
[ Upstream commit fefaae90398d38a1100ccd73b46ab55ff4610fba ] The segmentation fault happens because: During modprobe: 1. In igen6_probe(), igen6_pvt will be allocated with kzalloc() 2. In igen6_register_mci(), mci->pvt_info will point to &igen6_pvt->imc[mc] During rmmod: 1. In mci_release() in edac_mc.c, it will kfree(mci->pvt_info) 2. In igen6_remove(), it will kfree(igen6_pvt); Fix this issue by setting mci->pvt_info to NULL to avoid the double kfree. Fixes: 10590a9d ("EDAC/igen6: Add EDAC driver for Intel client SoCs using IBECC") Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219360 Signed-off-by:
Orange Kao <orange@aiven.io> Signed-off-by:
Tony Luck <tony.luck@intel.com> Link: https://lore.kernel.org/r/20241104124237.124109-2-orange@aiven.io Signed-off-by:
-
Weili Qian authored
[ Upstream commit c418ba6baca3ae10ffaf47b0803d2a9e6bf1af96 ] If an error indicating that the device needs to be reset is reported, disable the error reporting before device reset is complete, enable the error reporting after the reset is complete to prevent the same error from being reported repeatedly. Fixes: eaebf4c3 ("crypto: hisilicon - Unify hardware error init/uninit into QM") Signed-off-by:
Weili Qian <qianweili@huawei.com> Signed-off-by:
-
Gautham R. Shenoy authored
[ Upstream commit 0c411b39e4f4ce8861301fa201cb4f817751311e ] The amd-pstate driver sets CPPC_REQ.min_perf to CPPC_REQ.max_perf when in active mode with performance governor. Typically CPPC_REQ.max_perf is set to CPPC.highest_perf. This causes frequency throttling on power-limited platforms which causes performance regressions on certain classes of workloads. Hence, set the CPPC_REQ.min_perf to the CPPC.nominal_perf or CPPC_REQ.max_perf, whichever is lower of the two. Fixes: ffa5096a ("cpufreq: amd-pstate: implement Pstate EPP support for the AMD processors") Signed-off-by:
Gautham R. Shenoy <gautham.shenoy@amd.com> Reviewed-by:
Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20241021101836.9047-2-gautham.shenoy@amd.com Signed-off-by:
-
Mario Limonciello authored
[ Upstream commit 67c08d303e0a1a5665b3f198037c9fae2d808090 ] When boost is changed the CPPC value is changed in amd_pstate_cpu_boost_update() but then changed again when refresh_frequency_limits() and all it's callbacks occur. The first is a pointless write, so instead just update the limits for the policy and let the policy refresh anchor everything properly. Fixes: c8c68c38 ("cpufreq: amd-pstate: initialize core precision boost state") Reviewed-by:
Perry Yuan <perry.yuan@amd.com> Tested-by:
Dhananjay Ugwekar <dhananjay.ugwekar@amd.com> Link: https://lore.kernel.org/r/20241012174519.897-2-mario.limonciello@amd.com Signed-off-by:
-
Everest K.C authored
[ Upstream commit 53d91ca76b6c426c546542a44c78507b42008c9e ] The while loop breaks in the first run because of incorrect if condition. It also causes the statements after the if to appear dead. Fix this by changing the condition from if(timeout--) to if(!timeout--). This bug was reported by Coverity Scan. Report: CID 1600859: (#1 of 1): Logically dead code (DEADCODE) dead_error_line: Execution cannot reach this statement: udelay(30UL); Fixes: 9e2c7d99 ("crypto: cavium - Add Support for Octeon-tx CPT Engine") Signed-off-by:
Everest K.C. <everestkc@everestkc.com.np> Signed-off-by:
-
Yi Yang authored
[ Upstream commit 662f2f13e66d3883b9238b0b96b17886179e60e2 ] Since commit 8f4f68e7 ("crypto: pcrypt - Fix hungtask for PADATA_RESET"), the pcrypt encryption and decryption operations return -EAGAIN when the CPU goes online or offline. In alg_test(), a WARN is generated when pcrypt_aead_decrypt() or pcrypt_aead_encrypt() returns -EAGAIN, the unnecessary panic will occur when panic_on_warn set 1. Fix this issue by calling crypto layer directly without parallelization in that case. Fixes: 8f4f68e7 ("crypto: pcrypt - Fix hungtask for PADATA_RESET") Signed-off-by:
Yi Yang <yiyang13@huawei.com> Signed-off-by:
-
Qiuxu Zhuo authored
[ Upstream commit a36667037a0c0e36c59407f8ae636295390239a5 ] The Granite Rapids CPUs with Flat2LM memory configurations may mistakenly report near-memory errors as far-memory errors, resulting in the invalid decoded ADXL results: EDAC skx: Bad imc -1 Fix this incorrect far-memory error source indicator by prefetching the decoded far-memory controller ID, and adjust the error source indicator to near-memory if the far-memory controller ID is invalid. Fixes: ba987eaa ("EDAC/i10nm: Add Intel Granite Rapids server support") Signed-off-by:
Qiuxu Zhuo <qiuxu.zhuo@intel.com> Signed-off-by:
Diego Garcia Rodriguez <diego.garcia.rodriguez@intel.com> Link: https://lore.kernel.org/r/20241015072236.24543-3-qiuxu.zhuo@intel.com Signed-off-by:
-
Qiuxu Zhuo authored
[ Upstream commit 2397f795735219caa9c2fe61e7bcdd0652e670d3 ] The current skx_common determines whether the memory error source is the near memory of the 2LM system and then retrieves the decoded error results from the ADXL components (near-memory vs. far-memory) accordingly. However, some memory controllers may have limitations in correctly reporting the memory error source, leading to the retrieval of incorrect decoded parts from the ADXL. To address these limitations, instead of simply determining whether the memory error is from the near memory of the 2LM system, it is necessary to distinguish the memory error source details as follows: Memory error from the near memory of the 2LM system. Memory error from the far memory of the 2LM system. Memory error from the 1LM system. Not a memory error. This will enable the i10nm_edac driver to take appropriate actions for those memory controllers that have limitations in reporting the memory error source. Fixes: ba987eaa ("EDAC/i10nm: Add Intel Granite Rapids server support") Signed-off-by:
-
Priyanka Singh authored
[ Upstream commit 9ec22ac4fe766c6abba845290d5139a3fbe0153b ] Fix undefined behavior caused by left-shifting a negative value in the expression: cap_high ^ (1 << (bad_data_bit - 32)) The variable bad_data_bit ranges from 0 to 63. When it is less than 32, bad_data_bit - 32 becomes negative, and left-shifting by a negative value in C is undefined behavior. Fix this by combining cap_high and cap_low into a 64-bit variable. [ bp: Massage commit message, simplify error bits handling. ] Fixes: ea2eb9a8 ("EDAC, fsl-ddr: Separate FSL DDR driver from MPC85xx") Signed-off-by:Priyanka Singh <priyanka.singh@nxp.com> Signed-off-by:
Li Yang <leoyang.li@nxp.com> Signed-off-by:
Frank Li <Frank.Li@nxp.com> Signed-off-by:
Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/20241016-imx95_edac-v3-3-86ae6fc2756a@nxp.com Signed-off-by:
-
Rafael J. Wysocki authored
[ Upstream commit cdf771ab476bd9acb0948f3088a277d5c3cacc6b ] If the registration of a thermal zone takes place at the time when system suspend is started, thermal_pm_notify() can run before the new thermal zone is added to thermal_tz_list and its "suspended" flag will not be set. Consequently, if __thermal_zone_device_update() is called for that thermal zone, it will not return early as expected which may cause some destructive interference with the system suspend or resume flow to occur. To avoid that, make thermal_zone_init_complete() introduced previously set the "suspended" flag for new thermal zones if it runs during system suspend or resume. Fixes: 4e814173 ("thermal: core: Fix thermal zone suspend-resume synchronization") Signed-off-by:
-
Rafael J. Wysocki authored
[ Upstream commit 7837fa8115e0273d3cfbd3d17b3f7b7291ceac08 ] After thermal_zone_device_register_with_trips() has called device_register() and it has registered the new thermal zone device with the driver core, user space may access its sysfs attributes and, among other things, it may enable the thermal zone before it is ready. To address this, introduce a new thermal zone state flag for initialization and set it before calling device_register() in thermal_zone_device_register_with_trips(). This causes __thermal_zone_device_update() to return early until the new flag is cleared. To clear it when the thermal zone is ready, introduce a new function called thermal_zone_init_complete() that will also invoke __thermal_zone_device_update() after clearing that flag (both under the thernal zone lock) and make thermal_zone_device_register_with_trips() call the new function instead of checking need_update and calling thermal_zone_device_update() when it is set. After this change, if user space enables the thermal zone prematurely, __thermal_zone_device_update() will return early for it until thermal_zone_init_complete() is called. In turn, if the thermal zone is not enabled by user space before thermal_zone_init_complete() is called, the __thermal_zone_device_update() call in it will return early because the thermal zone has not been enabled yet, but that function will be invoked again by thermal_zone_device_set_mode() when the thermal zone is enabled and it will not return early this time. The checking of need_update is not necessary any more because the __thermal_zone_device_update() calls potentially triggered by cooling device binding take place before calling thermal_zone_init_complete(), so they all will return early, which means that thermal_zone_init_complete() must call __thermal_zone_device_update() in case the thermal zone is enabled prematurely by user space. Fixes: 203d3d4a ("the generic thermal sysfs driver") Signed-off-by:
-
Rafael J. Wysocki authored
[ Upstream commit 26c9ab8090cda1eb3d42f491cc32d227404897da ] Instead of using two separate fields in struct thermal_zone_device for representing flags related to thermal zone suspend, represent them explicitly as bits in one u8 "state" field. Subsequently, that field will be used for addressing race conditions related to thermal zone initialization and exit. No intentional functional impact. Signed-off-by:
-
Rafael J. Wysocki authored
[ Upstream commit 7ddca5885718c2683d75689aa065c9a3bb317e5a ] Move the code run for each thermal zone by the thermal PM notify handler to separate functions. This will help to make some subsequent changes look somewhat more straightforward, among other things. No intentional functional impact. Signed-off-by:
-
