Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) client-ip=23.128.96.33;
Subject: Re: [PATCH next] trace/blktrace: fix task hung in blk_trace_ioctl
To:     Edward Adam Davis <eadavis@qq.com>,
        syzbot+ed812ed461471ab17a0c@syzkaller.appspotmail.com
Cc:     akpm@linux-foundation.org, axboe@kernel.dk, dvyukov@google.com,
        linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
        linux-trace-kernel@vger.kernel.org, mhiramat@kernel.org,
        pengfei.xu@intel.com, rostedt@goodmis.org,
        syzkaller-bugs@googlegroups.com, "yukuai (C)" <yukuai3@huawei.com>
References: <00000000000047eb7e060b652d9a@google.com>
 <tencent_6537E04AAC74F976B567603CEB377A96FA09@qq.com>
From:   Yu Kuai <yukuai1@huaweicloud.com>
Message-ID: <5116cbb4-2c85-2459-5499-56c95bb42d16@huaweicloud.com>
Date:   Sat, 2 Dec 2023 17:19:25 +0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101
 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <tencent_6537E04AAC74F976B567603CEB377A96FA09@qq.com>
Content-Type: text/plain; charset=gbk; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk

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@syzkaller.appspotmail.com
> Signed-off-by: Edward Adam Davis <eadavis@qq.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:
>