linux-kernel - Re: [PATCH next] trace/blktrace: fix task hung in blk_trace

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

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:
>