From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from dggsgout12.his.huawei.com (dggsgout12.his.huawei.com [45.249.212.56]) (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 2FE1D19EED3 for ; Sat, 29 Nov 2025 03:52:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.249.212.56 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764388359; cv=none; b=IVOM0k3MiNuJ0lfO75TGoDqvp5bOvvRQdWKMzT0dLUrNpuMpIB/Xjnti3OXwpOFpBGhuWmGwSPU17QkGHuzPZ1JwfSH3UOab7obcY5TCOglP1bplJlqXeNH7tYflCPjI5/z6+eMXb6fBim4ln/vDGtVF5c9TVUiU6ikn/Z/1C+k= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764388359; c=relaxed/simple; bh=5ZlswCwMue9v7mIidXk+ViKZvYsVoJKUa160ABKIRi0=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=bQDzKL6SM+hzt3MHkP403yYSNWzff291DIE0PRM9aKtjcd7P0o1a807L6wu1Z5CInW2pXMCy2EzhupI04fRr+Aer/UbgIcBAosPH7VS4OKxtmK0xdEi1xfKSy8fGX8p+TnWV3+O+m66HEcrf7Nk6uH8npVNB56WzkhMmMN7O5OA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com; spf=pass smtp.mailfrom=huaweicloud.com; arc=none smtp.client-ip=45.249.212.56 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huaweicloud.com Received: from mail.maildlp.com (unknown [172.19.93.142]) by dggsgout12.his.huawei.com (SkyGuard) with ESMTPS id 4dJGSQ4cHNzKHMMN for ; Sat, 29 Nov 2025 11:51:50 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.75]) by mail.maildlp.com (Postfix) with ESMTP id 63EF91A07C0 for ; Sat, 29 Nov 2025 11:52:33 +0800 (CST) Received: from [10.174.178.72] (unknown [10.174.178.72]) by APP2 (Coremail) with SMTP id Syh0CgBHpXv_bSppsQOKCQ--.57352S3; Sat, 29 Nov 2025 11:52:33 +0800 (CST) Message-ID: <78fc451c-27a7-4156-a1a0-ea2fdd601403@huaweicloud.com> Date: Sat, 29 Nov 2025 11:52:31 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: CVE-2025-40146: blk-mq: fix potential deadlock while nr_requests grown To: Nilay Shroff , Greg KH Cc: cve@kernel.org, linux-kernel@vger.kernel.org, yukuai@fnnas.com, ming.lei@redhat.com, "zhangyi (F)" , Hou Tao , yangerkun , zhengqixing@huawei.com 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> <9ef3f966-c9bc-2da0-3fbf-a926eee740c9@huawei.com> <8ad23abf-b5d2-4a16-a8bd-28df4ab6823f@linux.ibm.com> From: Zheng Qixing In-Reply-To: <8ad23abf-b5d2-4a16-a8bd-28df4ab6823f@linux.ibm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-CM-TRANSID:Syh0CgBHpXv_bSppsQOKCQ--.57352S3 X-Coremail-Antispam: 1UD129KBjvJXoW7Kr43AF13tF4rWFyDJr1UJrb_yoW8ZrWxpF sYkw1vkFZ5Jr95G34ktw48Wa4rWan8Zay8Gw13WrykZrsIqF92grZ7CFyYvFy8WryrZFW0 vr909F93Gay2ya7anT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUkEb4IE77IF4wAFF20E14v26r4j6ryUM7CY07I20VC2zVCF04k2 6cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rwA2F7IY1VAKz4 vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Ar0_tr1l84ACjcxK6xIIjxv20xvEc7Cj xVAFwI0_Cr0_Gr1UM28EF7xvwVC2z280aVAFwI0_GcCE3s1l84ACjcxK6I8E87Iv6xkF7I 0E14v26rxl6s0DM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI64kE6c02F40E x7xfMcIj6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x 0Yz7v_Jr0_Gr1lF7xvr2IY64vIr41lFIxGxcIEc7CjxVA2Y2ka0xkIwI1lc7CjxVAaw2AF wI0_Jw0_GFyl42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxVAqx4 xG67AKxVWUJVWUGwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r1q6r43 MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I 0E14v26r1j6r4UMIIF0xvE42xK8VAvwI8IcIk0rVWUJVWUCwCI42IY6I8E87Iv67AKxVWU JVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r1j6r4UYxBIdaVFxhVjvjDU0xZFpf9x07UAwI DUUUUU= X-CM-SenderInfo: x2kh0wptl0x03j6k3tpzhluzxrxghudrp/ Commit 28307d938fb2 ("percpu: make pcpu_alloc() aware of current gfp context") has fixed a reclaim recursion for scoped GFP_NOFS context by avoiding taking pcpu_alloc_mutex. @@ -1569,6 +1569,12 @@ static void __percpu *pcpu_alloc(size_t size, size_t align, bool reserved, void __percpu *ptr; size_t bits, bit_align; + gfp = current_gfp_context(gfp); + /* whitelisted flags that can be passed to the backing allocators */ + pcpu_gfp = gfp & (GFP_KERNEL | __GFP_NORETRY | __GFP_NOWARN); + is_atomic = (gfp & GFP_KERNEL) != GFP_KERNEL; + do_warn = !(gfp & __GFP_NOWARN); Commit 9a5b183941b5 ("mm, percpu: do not consider sleepable allocations atomic") fixes premature allocation failures in certain scenarios. However, this change made it possible to acquire the pcpu_alloc_mutex under GFP_NOIO scope. @@ -1745,7 +1745,7 @@ void __percpu *pcpu_alloc_noprof(size_t size, size_t align, bool reserved, gfp = current_gfp_context(gfp); /* whitelisted flags that can be passed to the backing allocators */ pcpu_gfp = gfp & (GFP_KERNEL | __GFP_NORETRY | __GFP_NOWARN); - is_atomic = (gfp & GFP_KERNEL) != GFP_KERNEL; + is_atomic = !gfpflags_allow_blocking(gfp); do_warn = !(gfp & __GFP_NOWARN); Here's the relevant commit timeline: e3a2b3f931f5 ("blk-mq: allow changing of queue depth through sysfs") v3.16-rc1 28307d938fb2 ("percpu: make pcpu_alloc() aware of current gfp context") v5.7-rc5 9a5b183941b5 ("mm, percpu: do not consider sleepable allocations atomic") v6.15-rc1 b86433721f46 ("blk-mq: fix potential deadlock while nr_requests grown") v6.18-rc1 This means that in the Linux master branch, this deadlock issue *did not exist* during the version window from v5.7-rc5 to v6.15-rc1. After analyzing the LTS versions, I found that linux-5.7.y through linux-6.13.y should also not have this deadlock issue. If you have any questions or concerns, please feel free to discuss further. Best regards, Qixing