[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <5116cbb4-2c85-2459-5499-56c95bb42d16@huaweicloud.com>
Date: Sat, 2 Dec 2023 17:19:25 +0800
From: Yu Kuai <yukuai1@...weicloud.com>
To: Edward Adam Davis <eadavis@...com>,
syzbot+ed812ed461471ab17a0c@...kaller.appspotmail.com
Cc: akpm@...ux-foundation.org, axboe@...nel.dk, dvyukov@...gle.com,
linux-block@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-trace-kernel@...r.kernel.org, mhiramat@...nel.org,
pengfei.xu@...el.com, rostedt@...dmis.org,
syzkaller-bugs@...glegroups.com, "yukuai (C)" <yukuai3@...wei.com>
Subject: Re: [PATCH next] trace/blktrace: fix task hung in blk_trace_ioctl
Hi,
在 2023/12/02 17:01, Edward Adam Davis 写道:
> 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()?
>
> 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")
> Reported-and-tested-by: syzbot+ed812ed461471ab17a0c@...kaller.appspotmail.com
> Signed-off-by: Edward Adam Davis <eadavis@...com>
> ---
> kernel/trace/blktrace.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/trace/blktrace.c b/kernel/trace/blktrace.c
> index 54ade89a1ad2..34e5bce42b1e 100644
> --- a/kernel/trace/blktrace.c
> +++ b/kernel/trace/blktrace.c
> @@ -735,7 +735,8 @@ int blk_trace_ioctl(struct block_device *bdev, unsigned cmd, char __user *arg)
> int ret, start = 0;
> char b[BDEVNAME_SIZE];
>
> - mutex_lock(&q->debugfs_mutex);
> + if (!mutex_trylock(&q->debugfs_mutex))
> + return -EBUSY;
This is absolutely not a proper fix, a lot of user case will fail after
this patch.
Thanks,
Kuai
>
> switch (cmd) {
> case BLKTRACESETUP:
>
Powered by blists - more mailing lists