From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from canpmsgout10.his.huawei.com (canpmsgout10.his.huawei.com [113.46.200.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AF21A2D3228 for ; Fri, 28 Nov 2025 06:33:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.225 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764311624; cv=none; b=jbYDkdPRXDrEguosPn1Y66gfn9MIePOmBS2aXkLV1y5QvXKcAGtSpFQNQQmNYeqozskKdvYunq4bpBqOzQ6F7OKaD4wEaYnhNU7cJImmWt4zq15COJCTQ4hT1D1hOpql/cFElL0XmFSZOZt/El+3wfzA0+IUm+Xw+PS/GdtIsSk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764311624; c=relaxed/simple; bh=kC1eZsCfTd0DEQC+rMYk4bZnRMh5mepJhyVGvmRwh68=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=YBCuJnKwQfjgtRuN+aeK3K+/eqAq8hUfiSqzPByJYgb5LBEtzZ9o+ZgU72CSLOtufKbeOf5FWcfU0D3TB/LuoElDLbbSKztZIdjyfvCh0hDBovV/dj5GO87c5q9B15EQFnYZOzrmJjw5QBcBcZPAYTpyGj3Iw+tlbwu22MnYONE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=PKDf/bgD; arc=none smtp.client-ip=113.46.200.225 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="PKDf/bgD" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=mqdueO7+9BUEPtt+khR9tP8SJbCTU7v9TlnzqowLWWM=; b=PKDf/bgDHkTk73H6UVNfejw8GwEd1M4gafw6UFMzcb5cLf75uZjNb5YuxqrGIsxwcf7lRC8hB 9IOUQUZSdqGrF6On2gfTqgKqfOPHxuE0RM0/PfBJxprd1SbTG6EpHgTn8U4jA5GxOIyNX6z1fIj hOmTbiqAoRwPbfTwAbwHFuk= Received: from mail.maildlp.com (unknown [172.19.88.214]) by canpmsgout10.his.huawei.com (SkyGuard) with ESMTPS id 4dHk3V3KsKz1K96Y; Fri, 28 Nov 2025 14:31:50 +0800 (CST) Received: from kwepemf100006.china.huawei.com (unknown [7.202.181.220]) by mail.maildlp.com (Postfix) with ESMTPS id DFA471A016C; Fri, 28 Nov 2025 14:33:37 +0800 (CST) Received: from [10.174.177.210] (10.174.177.210) by kwepemf100006.china.huawei.com (7.202.181.220) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.36; Fri, 28 Nov 2025 14:33:37 +0800 Message-ID: <9ef3f966-c9bc-2da0-3fbf-a926eee740c9@huawei.com> Date: Fri, 28 Nov 2025 14:33:36 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.5.1 Subject: Re: CVE-2025-40146: blk-mq: fix potential deadlock while nr_requests grown To: Nilay Shroff , Zheng Qixing , Greg KH CC: , , , , "zhangyi (F)" , Hou Tao References: <2025111256-CVE-2025-40146-b919@gregkh> <15fb6eed-e107-4ef7-a569-3328a02e2c39@huaweicloud.com> <2025112730-semicolon-verse-164a@gregkh> <82df4ae1-2940-4214-b46e-a2f8242b3582@huaweicloud.com> <813a7d60-6211-4048-9267-ec4bd4a75f73@linux.ibm.com> From: yangerkun In-Reply-To: <813a7d60-6211-4048-9267-ec4bd4a75f73@linux.ibm.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: kwepems500002.china.huawei.com (7.221.188.17) To kwepemf100006.china.huawei.com (7.202.181.220) 在 2025/11/28 13:20, Nilay Shroff 写道: > > > On 11/28/25 6:45 AM, Zheng Qixing wrote: >> >> 在 2025/11/27 21:39, Greg KH 写道: >>> On Thu, Nov 27, 2025 at 09:22:42PM +0800, Zheng Qixing wrote: >>>> Hi, >>>> >>>> Commit b86433721f46 ("blk-mq: fix potential deadlock while nr_requests >>>> grown")  aims to avoid a deadlock issue when the queue is frozen and memory >>>> reclaim is triggered. >>>> >>>> However, the sysfs nr_requests update path is already under a >>>> memalloc_noio_save() region while the queue is frozen (via >>>> blk_mq_freeze_queue()). >>> Did the lockdep splat in >>> https://lore.kernel.org/all/0659ea8d-a463-47c8-9180-43c719e106eb@linux.ibm.com/ >>> not describe the issue here that the commit is attempting to solve? >>> >>> thanks, >>> >>> greg k-h >> >> >> The deadlock issue described in this link is about elevator switch path, but the patch modifies sysfs nr_requests update path. >> >> I didn't identify any potential deadlock issues on this path. If I misunderstood something, could someone help clarify? >> >> > Let me clarify the confusion here. > > The deadlock reported in [1] requires updates across multiple code paths. There are > three distinct paths that need to be fixed to avoid the deadlock. While the report > in [1] only exposed the issue in one of these paths, we already knew that all three > paths needed changes to fully resolve the problem: > > 1. Elevator change path (via sysfs attribute) that triggers a scheduler tags update > 2. Elevator change path triggered by an nr_hw_queues update which also triggers a > scheduler tags update > 3. Scheduler tags update triggered through the nr_requests sysfs attribute (please > note when nr_requests grows beyond current queue depth it triggers scheduler > tags update) commit b86433721f46d934940528f28d49c1dedb690df1 (HEAD -> master) Author: Yu Kuai Date: Wed Sep 10 16:04:43 2025 +0800 blk-mq: fix potential deadlock while nr_requests grown Allocate and free sched_tags while queue is freezed can deadlock[1], this is a long term problem, hence allocate memory before freezing queue and free memory after queue is unfreezed. [1] https://lore.kernel.org/all/0659ea8d-a463-47c8-9180-43c719e106eb@linux.ibm.com/ Fixes: e3a2b3f931f5 ("blk-mq: allow changing of queue depth through sysfs") Signed-off-by: Yu Kuai Reviewed-by: Nilay Shroff Signed-off-by: Jens Axboe We are assume that what's the problem Yu describe is when we update nr_request, we may need some memory allocation(nr_requests grows). And the memory allocation may trigger some memory reclaim, and fall into another I/O process, and since the request_queue has been freezen, there exist deadlock. But after checking the source code, there exist queue_requests_store->blk_mq_freeze_queue->memalloc_noio_save, the whole process which may trigger memory allocation won't trigger I/O process. So deadlock can not happened... And if that's true, this patch does not fix any problem. Thanks, Erkun. > > The first two code paths were addressed by: > commit f5a6604f7a44 (“block: fix lockdep warning caused by lock dependency in > elv_iosched_store”), and commit 04225d13aef1 (“block: fix potential deadlock while > running nr_hw_queue update”) respectively. > > The third code path was fixed by: > commit b86433721f46 (“blk-mq: fix potential deadlock while nr_requests grown”). > > Ideally, all of these commits should be referenced as collectively fixing the lockdep > splat reported in [1]. I hope this clarifies the situation. Please let me know if you > have any further questions. > > [1] https://lore.kernel.org/all/0659ea8d-a463-47c8-9180-43c719e106eb@linux.ibm.com/ > > Thanks, > --Nilay >