ACPICA: Add AML_NO_OPERAND_RESOLVE flag to Timer
Subsystems (5)
Sasha Levin
maintainerPATCH 1/5 ACPICA: Add AML_NO_OPERAND_RESOLVE flag to Timer
From: Abhishek Mainkar <[email protected]>
[ Upstream commit 3a21ffdbc825e0919db9da0e27ee5ff2cc8a863e ]
ACPICA commit 90310989a0790032f5a0140741ff09b545af4bc5
According to the ACPI specification 19.6.134, no argument is required to be passed for ASL Timer instruction. For taking care of no argument, AML_NO_OPERAND_RESOLVE flag is added to ASL Timer instruction opcode.
When ASL timer instruction interpreted by ACPI interpreter, getting error. After adding AML_NO_OPERAND_RESOLVE flag to ASL Timer instruction opcode, issue is not observed.
=============================================================
UBSAN: array-index-out-of-bounds in acpica/dswexec.c:401:12 index -1 is out of range for type 'union acpi_operand_object *[9]' CPU: 37 PID: 1678 Comm: cat Not tainted 6.0.0-dev-th500-6.0.y-1+bcf8c46459e407-generic-64k HW name: NVIDIA BIOS v1.1.1-d7acbfc-dirty 12/19/2022 Call trace: dump_backtrace+0xe0/0x130 show_stack+0x20/0x60 dump_stack_lvl+0x68/0x84 dump_stack+0x18/0x34 ubsan_epilogue+0x10/0x50 __ubsan_handle_out_of_bounds+0x80/0x90 acpi_ds_exec_end_op+0x1bc/0x6d8 acpi_ps_parse_loop+0x57c/0x618 acpi_ps_parse_aml+0x1e0/0x4b4 acpi_ps_execute_method+0x24c/0x2b8 acpi_ns_evaluate+0x3a8/0x4bc acpi_evaluate_object+0x15c/0x37c acpi_evaluate_integer+0x54/0x15c show_power+0x8c/0x12c [acpi_power_meter]
--- drivers/acpi/acpica/psopcode.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/acpi/acpica/psopcode.c +1 -1
@@ -603,7 +603,7 @@ const struct acpi_opcode_info acpi_gbl_aml_op_info[AML_NUM_OPCODES] = {/* 7E */ ACPI_OP ("Timer" ,ARGP_TIMER_OP ,ARGI_TIMER_OP ,ACPI_TYPE_ANY ,AML_CLASS_EXECUTE ,AML_TYPE_EXEC_0A_0T_1R , - AML_FLAGS_EXEC_0A_0T_1R), + AML_FLAGS_EXEC_0A_0T_1R | AML_NO_OPERAND_RESOLVE),/* ACPI 5.0 opcodes */
Signature · 1 line
2.40.1
Sasha Levin
maintainerPATCH 2/5 kernel/fork: beware of __put_task_struct() calling context
From: Wander Lairson Costa <[email protected]>
[ Upstream commit d243b34459cea30cfe5f3a9b2feb44e7daff9938 ]
Under PREEMPT_RT, __put_task_struct() indirectly acquires sleeping locks. Therefore, it can't be called from an non-preemptible context.
One practical example is splat inside inactive_task_timer(), which is called in a interrupt context:
CPU: 1 PID: 2848 Comm: life Kdump: loaded Tainted: G W --------- Hardware name: HP ProLiant DL388p Gen8, BIOS P70 07/15/2012 Call Trace: dump_stack_lvl+0x57/0x7d mark_lock_irq.cold+0x33/0xba mark_lock+0x1e7/0x400 mark_usage+0x11d/0x140 __lock_acquire+0x30d/0x930 lock_acquire.part.0+0x9c/0x210 rt_spin_lock+0x27/0xe0 refill_obj_stock+0x3d/0x3a0 kmem_cache_free+0x357/0x560 inactive_task_timer+0x1ad/0x340 __run_hrtimer+0x8a/0x1a0 __hrtimer_run_queues+0x91/0x130 hrtimer_interrupt+0x10f/0x220 __sysvec_apic_timer_interrupt+0x7b/0xd0 sysvec_apic_timer_interrupt+0x4f/0xd0 asm_sysvec_apic_timer_interrupt+0x12/0x20 RIP: 0033:0x7fff196bf6f5
Instead of calling __put_task_struct() directly, we defer it using call_rcu(). A more natural approach would use a workqueue, but since in PREEMPT_RT, we can't allocate dynamic memory from atomic context, the code would become more complex because we would need to put the work_struct instance in the task_struct and initialize it when we allocate a new task_struct.
The issue is reproducible with stress-ng:
while true; do
stress-ng --sched deadline --sched-period 1000000000 \ --sched-runtime 800000000 --sched-deadline \ 1000000000 --mmapfork 23 -t 20
done
--- include/linux/sched/task.h | 28 +++++++++++++++++++++++++++- kernel/fork.c | 8 ++++++++ 2 files changed, 35 insertions(+), 1 deletion(-)
include/linux/sched/task.h +27 -1
@@ -113,10 +113,36 @@ static inline struct task_struct *get_task_struct(struct task_struct *t) }extern void __put_task_struct (struct task_struct *t); +extern void __put_task_struct_rcu_cb (struct rcu_head *rhp);static inline void put_task_struct (struct task_struct *t) { -if (refcount_dec_and_test (&t->usage)) +if (!refcount_dec_and_test (&t->usage)) +return ; + +/* +* under PREEMPT_RT, we can't call put_task_struct +* in atomic context because it will indirectly +* acquire sleeping locks. +* +* call_rcu() will schedule delayed_put_task_struct_rcu() +* to be called in process context. +* +* __put_task_struct() is called when +* refcount_dec_and_test(&t->usage) succeeds. +* +* This means that it can't "conflict" with +* put_task_struct_rcu_user() which abuses ->rcu the same +* way; rcu_users has a reference so task->usage can't be +* zero after rcu_users 1 -> 0 transition. +* +* delayed_free_task() also uses ->rcu, but it is only called +* when it fails to fork a process. Therefore, there is no +* way it can conflict with put_task_struct(). +*/ +if (IS_ENABLED (CONFIG_PREEMPT_RT ) && !preemptible ()) +call_rcu (&t->rcu, __put_task_struct_rcu_cb); +else __put_task_struct (t); }
kernel/fork.c +8 -0
@@ -749,6 +749,14 @@ void __put_task_struct(struct task_struct *tsk) }EXPORT_SYMBOL_GPL (__put_task_struct); +void __put_task_struct_rcu_cb (struct rcu_head *rhp) +{ + struct task_struct *task = container_of(rhp, struct task_struct, rcu); + +__put_task_struct (task); +} +EXPORT_SYMBOL_GPL (__put_task_struct_rcu_cb); +void __init __weak arch_task_cache_init (void ) { }/*
Signature · 1 line
2.40.1
Sasha Levin
maintainerPATCH 3/5 ACPI: video: Add backlight=native DMI quirk for Lenovo Ideapad Z470
In reply to Sasha LevinFrom: "Jiri Slaby (SUSE)" <[email protected]>
[ Upstream commit 96b709be183c56293933ef45b8b75f8af268c6de ]
The Lenovo Ideapad Z470 predates Windows 8, so it defaults to using acpi_video for backlight control. But this is not functional on this model.
Add a DMI quirk to use the native backlight interface which works.
--- drivers/acpi/video_detect.c | 9 +++++++++ 1 file changed, 9 insertions(+)
drivers/acpi/video_detect.c +9 -0
@@ -310,6 +310,15 @@ static const struct dmi_system_id video_detect_dmi_table[] = { DMI_MATCH(DMI_BOARD_NAME, "Lenovo IdeaPad S405"), }, }, + { +/* https://bugzilla.suse.com/show_bug.cgi?id=1208724 */ + .callback = video_detect_force_native, +/* Lenovo Ideapad Z470 */ + .matches = { +DMI_MATCH (DMI_SYS_VENDOR ,"LENOVO" ), + DMI_MATCH(DMI_PRODUCT_VERSION, "IdeaPad Z470"), + }, + }, {/* https://bugzilla.redhat.com/show_bug.cgi?id=1187004 */ .callback = video_detect_force_native,
Signature · 1 line
2.40.1
Sasha Levin
maintainerPATCH 4/5 perf/smmuv3: Enable HiSilicon Erratum 162001900 quirk for HIP08/09
In reply to Sasha LevinFrom: Yicong Yang <[email protected]>
[ Upstream commit 0242737dc4eb9f6e9a5ea594b3f93efa0b12f28d ]
Some HiSilicon SMMU PMCG suffers the erratum 162001900 that the PMU disable control sometimes fail to disable the counters. This will lead to error or inaccurate data since before we enable the counters the counter's still counting for the event used in last perf session.
This patch tries to fix this by hardening the global disable process. Before disable the PMU, writing an invalid event type (0xffff) to focibly stop the counters. Correspondingly restore each events on pmu::pmu_enable().
--- Documentation/arm64/silicon-errata.rst | 3 ++ drivers/acpi/arm64/iort.c | 5 ++- drivers/perf/arm_smmuv3_pmu.c | 46 +++++++++++++++++++++++++- include/linux/acpi_iort.h | 1 + 4 files changed, 53 insertions(+), 2 deletions(-)
Documentation/arm64/silicon-errata.rst +3 -0
@@ -134,6 +134,9 @@ stable kernels. +----------------+-----------------+-----------------+-----------------------------+ | Hisilicon | Hip08 SMMU PMCG | #162001800 | N/A | +----------------+-----------------+-----------------+-----------------------------+ +| Hisilicon | Hip08 SMMU PMCG | #162001900 | N/A | +| | Hip09 SMMU PMCG | | | ++----------------+-----------------+-----------------+-----------------------------+ +----------------+-----------------+-----------------+-----------------------------+ | Qualcomm Tech. | Kryo/Falkor v1 | E1003 | QCOM_FALKOR_ERRATUM_1003 | +----------------+-----------------+-----------------+-----------------------------+
drivers/acpi/arm64/iort.c +4 -1
@@ -1393,7 +1393,10 @@ static void __init arm_smmu_v3_pmcg_init_resources(struct resource *res,static struct acpi_platform_list pmcg_plat_info[]__initdata = {/* HiSilicon Hip08 Platform */ {"HISI " ,"HIP08 " ,0 ,ACPI_SIG_IORT , greater_than_or_equal, -"Erratum #162001800" ,IORT_SMMU_V3_PMCG_HISI_HIP08 }, +"Erratum #162001800, Erratum #162001900" ,IORT_SMMU_V3_PMCG_HISI_HIP08 }, +/* HiSilicon Hip09 Platform */ + {"HISI " ,"HIP09 " ,0 ,ACPI_SIG_IORT , greater_than_or_equal, +"Erratum #162001900" ,IORT_SMMU_V3_PMCG_HISI_HIP09 }, { } };
drivers/perf/arm_smmuv3_pmu.c +45 -1
76 lines not on this page · raw message
include/linux/acpi_iort.h +1 -0
@@ -21,6 +21,7 @@*/ #define IORT_SMMU_V3_PMCG_GENERIC 0x00000000/* Generic SMMUv3 PMCG */ #define IORT_SMMU_V3_PMCG_HISI_HIP08 0x00000001/* HiSilicon HIP08 PMCG */ +#define IORT_SMMU_V3_PMCG_HISI_HIP09 0x00000002/* HiSilicon HIP09 PMCG */ int iort_register_domain_token (int trans_id,phys_addr_t base,struct fwnode_handle *fw_node);
Signature · 7 lines
2.40.1 _______________________________________________ linux-arm-kernel mailing list [email protected] http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Sasha Levin
maintainerPATCH 5/5 hw_breakpoint: fix single-stepping when using bpf_overflow_handler
In reply to Sasha LevinFrom: Tomislav Novak <[email protected]>
[ Upstream commit d11a69873d9a7435fe6a48531e165ab80a8b1221 ]
Arm platforms use is_default_overflow_handler() to determine if the hw_breakpoint code should single-step over the breakpoint trigger or let the custom handler deal with it.
Since bpf_overflow_handler() currently isn't recognized as a default handler, attaching a BPF program to a PERF_TYPE_BREAKPOINT event causes it to keep firing (the instruction triggering the data abort exception is never skipped). For example:
# bpftrace -e 'watchpoint:0x10000:4:w { print("hit") }' -c ./test
Attaching 1 probe...
hit
hit
[...]
^C(./test performs a single 4-byte store to 0x10000)
This patch replaces the check with uses_default_overflow_handler(), which accounts for the bpf_overflow_handler() case by also testing if one of the perf_event_output functions gets invoked indirectly, via orig_default_handler.
--- arch/arm/kernel/hw_breakpoint.c | 8 ++++---- arch/arm64/kernel/hw_breakpoint.c | 4 ++-- include/linux/perf_event.h | 22 +++++++++++++++++++--- 3 files changed, 25 insertions(+), 9 deletions(-)
arch/arm/kernel/hw_breakpoint.c +4 -4
@@ -623,7 +623,7 @@ int hw_breakpoint_arch_parse(struct perf_event *bp, hw->address &= ~alignment_mask; hw->ctrl.len <<= offset; -if (is_default_overflow_handler (bp)) { +if (uses_default_overflow_handler (bp)) {/* * Mismatch breakpoints are required for single-stepping * breakpoints.
@@ -795,7 +795,7 @@ static void watchpoint_handler(unsigned long addr, unsigned int fsr,* Otherwise, insert a temporary mismatch breakpoint so that * we can single-step over the watchpoint trigger. */ -if (!is_default_overflow_handler (wp)) +if (!uses_default_overflow_handler (wp))continue ; step:enable_single_step (wp,instruction_pointer (regs));
@@ -808,7 +808,7 @@ static void watchpoint_handler(unsigned long addr, unsigned int fsr, info->trigger = addr;pr_debug ("watchpoint fired: address = 0x%x\n" , info->trigger);perf_bp_event (wp, regs); -if (is_default_overflow_handler (wp)) +if (uses_default_overflow_handler (wp))enable_single_step (wp,instruction_pointer (regs)); }
@@ -883,7 +883,7 @@ static void breakpoint_handler(unsigned long unknown, struct pt_regs *regs) info->trigger = addr;pr_debug ("breakpoint fired: address = 0x%x\n" , addr);perf_bp_event (bp, regs); -if (is_default_overflow_handler (bp)) +if (uses_default_overflow_handler (bp))enable_single_step (bp, addr); goto unlock; }
arch/arm64/kernel/hw_breakpoint.c +2 -2
@@ -654,7 +654,7 @@ static int breakpoint_handler(unsigned long unused, unsigned int esr,perf_bp_event (bp, regs);/* Do we need to handle the stepping? */ -if (is_default_overflow_handler (bp)) +if (uses_default_overflow_handler (bp)) step =1 ; unlock:rcu_read_unlock ();
@@ -733,7 +733,7 @@ static u64 get_distance_from_watchpoint(unsigned long addr, u64 val,static int watchpoint_report (struct perf_event *wp,unsigned long addr,struct pt_regs *regs) { -int step =is_default_overflow_handler (wp); +int step =uses_default_overflow_handler (wp);struct arch_hw_breakpoint *info =counter_arch_bp (wp); info->trigger = addr;
include/linux/perf_event.h +19 -3
@@ -1018,15 +1018,31 @@ extern int perf_event_output(struct perf_event *event, struct pt_regs *regs);static inline bool -is_default_overflow_handler (struct perf_event *event) +__is_default_overflow_handler (perf_overflow_handler_t overflow_handler) { -if (likely (event->overflow_handler == perf_event_output_forward)) +if (likely (overflow_handler == perf_event_output_forward))return true; -if (unlikely (event->overflow_handler == perf_event_output_backward)) +if (unlikely (overflow_handler == perf_event_output_backward))return true;return false; } +#define is_default_overflow_handler (event) \ + __is_default_overflow_handler((event)->overflow_handler) + +#ifdef CONFIG_BPF_SYSCALL +static inline bool uses_default_overflow_handler (struct perf_event *event) +{ +if (likely (is_default_overflow_handler (event))) +return true; + +return __is_default_overflow_handler (event->orig_overflow_handler); +} +#else +#define uses_default_overflow_handler (event) \ + is_default_overflow_handler(event) +#endif + extern void perf_event_header__init_id(struct perf_event_header *header, struct perf_sample_data *data,
Signature · 1 line
2.40.1