Re: [PATCH 1/2] sched/debug: Don't disable IRQ when acquiring sched_debug_lock

From: Waiman Long
Date: Mon Mar 29 2021 - 10:24:11 EST


On 3/29/21 6:23 AM, Daniel Thompson wrote:
On Sat, Mar 27, 2021 at 07:25:28PM -0400, Waiman Long wrote:
The sched_debug_lock was used only in print_cpu(). The
print_cpu() function has two callers - sched_debug_show() and
sysrq_sched_debug_show(). Both of them are invoked by user action
(sched_debug file and sysrq-t). As print_cpu() won't be called from
interrupt context at all, there is no point in disabling IRQ when
acquiring sched_debug_lock.
This looks like it introduces a deadlock risk if sysrq-t triggers from an
interrupt context. Has the behaviour of sysrq changed recently or will
tools like MAGIC_SYSRQ_SERIAL still trigger from interrupt context?

You are right. It looks like that if CONFIG_MAGIC_SYSRQ_SERIAL is set, it is possible for sysrq information dump to happen in an interrupt context. I missed that in my initial analysis. However, doing the time consuming info dump with interrupt disabled for an extended period of time is not a good idea.

Still with my second patch to minimize the size of the critical sections, it will minimize the chance of causing trouble except when doing it directly from the console.

Thanks,
Longman