| Message ID | 20201009152116.35184-1-jamie@nuviainc.com |
|---|---|
| State | New |
| Headers | show |
| Series | ACPI: debug: don't allow debugging when ACPI is disabled | expand |
On 2020/10/9 23:21, Jamie Iles wrote: > If ACPI is disabled then loading the acpi_dbg module will result in the > following splat when lock debugging is enabled. > > DEBUG_LOCKS_WARN_ON(lock->magic != lock) > WARNING: CPU: 0 PID: 1 at kernel/locking/mutex.c:938 __mutex_lock+0xa10/0x1290 > Kernel panic - not syncing: panic_on_warn set ... > CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.9.0-rc8+ #103 > Hardware name: linux,dummy-virt (DT) > Call trace: > dump_backtrace+0x0/0x4d8 > show_stack+0x34/0x48 > dump_stack+0x174/0x1f8 > panic+0x360/0x7a0 > __warn+0x244/0x2ec > report_bug+0x240/0x398 > bug_handler+0x50/0xc0 > call_break_hook+0x160/0x1d8 > brk_handler+0x30/0xc0 > do_debug_exception+0x184/0x340 > el1_dbg+0x48/0xb0 > el1_sync_handler+0x170/0x1c8 > el1_sync+0x80/0x100 > __mutex_lock+0xa10/0x1290 > mutex_lock_nested+0x6c/0xc0 > acpi_register_debugger+0x40/0x88 > acpi_aml_init+0xc4/0x114 > do_one_initcall+0x24c/0xb10 > kernel_init_freeable+0x690/0x728 > kernel_init+0x20/0x1e8 > ret_from_fork+0x10/0x18 That's because the mutex acpi_debugger.lock will not be initialized as acpi_debugger_init() is not called if ACPI is disabled. If you add above commit log then make it easier to be understood. > > Fail module loading to avoid this and any subsequent problems that might > arise by trying to debug AML when ACPI is disabled. > It's better to add a fix tag: Fixes: 8cfb0cdf07e2 ("ACPI / debugger: Add IO interface to access debugger functionalities") > Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> > Signed-off-by: Jamie Iles <jamie@nuviainc.com> > --- > drivers/acpi/acpi_dbg.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/acpi/acpi_dbg.c b/drivers/acpi/acpi_dbg.c > index 6041974c7627..fb7290338593 100644 > --- a/drivers/acpi/acpi_dbg.c > +++ b/drivers/acpi/acpi_dbg.c > @@ -749,6 +749,9 @@ static int __init acpi_aml_init(void) > { > int ret; > > + if (acpi_disabled) > + return -ENODEV; > + > /* Initialize AML IO interface */ > mutex_init(&acpi_aml_io.lock); > init_waitqueue_head(&acpi_aml_io.wait); With above comments addressed, feel free to add Reviewed-by: Hanjun Guo <guohanjun@huawei.com> Thanks Hanjun
diff --git a/drivers/acpi/acpi_dbg.c b/drivers/acpi/acpi_dbg.c index 6041974c7627..fb7290338593 100644 --- a/drivers/acpi/acpi_dbg.c +++ b/drivers/acpi/acpi_dbg.c @@ -749,6 +749,9 @@ static int __init acpi_aml_init(void) { int ret; + if (acpi_disabled) + return -ENODEV; + /* Initialize AML IO interface */ mutex_init(&acpi_aml_io.lock); init_waitqueue_head(&acpi_aml_io.wait);
If ACPI is disabled then loading the acpi_dbg module will result in the following splat when lock debugging is enabled. DEBUG_LOCKS_WARN_ON(lock->magic != lock) WARNING: CPU: 0 PID: 1 at kernel/locking/mutex.c:938 __mutex_lock+0xa10/0x1290 Kernel panic - not syncing: panic_on_warn set ... CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.9.0-rc8+ #103 Hardware name: linux,dummy-virt (DT) Call trace: dump_backtrace+0x0/0x4d8 show_stack+0x34/0x48 dump_stack+0x174/0x1f8 panic+0x360/0x7a0 __warn+0x244/0x2ec report_bug+0x240/0x398 bug_handler+0x50/0xc0 call_break_hook+0x160/0x1d8 brk_handler+0x30/0xc0 do_debug_exception+0x184/0x340 el1_dbg+0x48/0xb0 el1_sync_handler+0x170/0x1c8 el1_sync+0x80/0x100 __mutex_lock+0xa10/0x1290 mutex_lock_nested+0x6c/0xc0 acpi_register_debugger+0x40/0x88 acpi_aml_init+0xc4/0x114 do_one_initcall+0x24c/0xb10 kernel_init_freeable+0x690/0x728 kernel_init+0x20/0x1e8 ret_from_fork+0x10/0x18 Fail module loading to avoid this and any subsequent problems that might arise by trying to debug AML when ACPI is disabled. Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> Signed-off-by: Jamie Iles <jamie@nuviainc.com> --- drivers/acpi/acpi_dbg.c | 3 +++ 1 file changed, 3 insertions(+)