On Sat, 2 Dec 2023 17:19:25 +0800
Yu Kuai [off-list ref] wrote:

Hi,

在 2023/12/02 17:01, Edward Adam Davis 写道:

quoted

The reproducer involves running test programs on multiple processors separately,
in order to enter blkdev_ioctl() and ultimately reach blk_trace_ioctl() through
two different paths, triggering an AA deadlock.

	CPU0						CPU1
	---						---
	mutex_lock(&q->debugfs_mutex)			mutex_lock(&q->debugfs_mutex)
	mutex_lock(&q->debugfs_mutex)			mutex_lock(&q->debugfs_mutex)


The first path:
blkdev_ioctl()->
	blk_trace_ioctl()->
		mutex_lock(&q->debugfs_mutex)

The second path:
blkdev_ioctl()->				
	blkdev_common_ioctl()->
		blk_trace_ioctl()->
			mutex_lock(&q->debugfs_mutex)  

I still don't understand how this AA deadlock is triggered, does the
'debugfs_mutex' already held before calling blk_trace_ioctl()?

Right, I don't see where the mutex is taken twice. You don't need two
paths for an AA lock, you only need one.

quoted

The solution I have proposed is to exit blk_trace_ioctl() to avoid AA locks if
a task has already obtained debugfs_mutex.

Fixes: 0d345996e4cb ("x86/kernel: increase kcov coverage under arch/x86/kernel folder")

How does it fix the above? I don't see how the above is even related to this.

-- Steve

quoted

Reported-and-tested-by: syzbot+ed812ed461471ab17a0c@syzkaller.appspotmail.com
Signed-off-by: Edward Adam Davis <redacted>
---
  kernel/trace/blktrace.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/kernel/trace/blktrace.c b/kernel/trace/blktrace.c