From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 9952BC4451C for ; Fri, 17 Jul 2026 19:12:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type:In-Reply-To:From:References:Cc:To:Subject:MIME-Version:Date: Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=89syRlJ5f4RK2+c7tG9GpAaWSoEXbJLopmcI9DrtT/U=; b=XuKVLdDOr56Akh22SaOMzCzjDo gCI29PR4zfuTS97PQWlcmQhnMEb8WH/gwn8C85S8FJjCjy63/RGkeomVJTJx65MXYCZiHgWH4xz2j DJVrY4NjQHt005Xm/cNMDbZRfciV57d5Bgv7/NF+KWHn7dS9GHM6RyCVMkUhSF5hGiriBfxTM20La sPSKMSl53sYLKGPzsClS2Ftj3+QLihd2ZCvl422F+lRpiHnk0WyEBKtMdAzHqKDRFHneeiZiFZ8he ZAd0tWQKh4lCjB1q2URahFmdQrliMCBRutvFKYTG7ZrfCYvy62ADQtmwvb34Sv/lOxbzK8rIMB2Ub NrksGWvA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wknzR-000000036GE-0jGa; Fri, 17 Jul 2026 19:12:53 +0000 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1wknzO-000000036F9-1fsw for linux-nvme@lists.infradead.org; Fri, 17 Jul 2026 19:12:51 +0000 Received: from pps.filterd (m0360072.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 66HHC7Ka2614668; Fri, 17 Jul 2026 19:12:19 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s=pp1; bh=89syRl J5f4RK2+c7tG9GpAaWSoEXbJLopmcI9DrtT/U=; b=fdBaiNGG7XZZAsG80ct/Cv Rj9WKL4P0I5LixUez6dRnGyWWJ7f6qoIc+WsUsUBVLmOUYVpUBMd7GlaCEKjYM1/ cAISyCWZHv5BwOL1ifokD4bGa5OKiIasYS4DTzQQa2fIFCcuEP2FM7W3J2cIJqeC /XEDVP4GbRRiTEqrT/WXj3Lp88VPkjKIRzpLLhHv+sim0DaBdldOnPOcWspa4T38 BkheyhLFbpafLcxWcOkayh2PcPkx8NcprfXliAAhrq29c9iCCT4/K2BLn84NoKCs VTW7ntRTYvRLOfmEB9eAK+gsFMz6oWN/u+r737IBSk7SJw9/nEhXY2gAZFgSnWHA == Received: from ppma23.wdc07v.mail.ibm.com (5d.69.3da9.ip4.static.sl-reverse.com [169.61.105.93]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 4fbegc70p6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 17 Jul 2026 19:12:18 +0000 (GMT) Received: from pps.filterd (ppma23.wdc07v.mail.ibm.com [127.0.0.1]) by ppma23.wdc07v.mail.ibm.com (8.18.1.7/8.18.1.7) with ESMTP id 66HJ4aCZ010039; Fri, 17 Jul 2026 19:12:17 GMT Received: from smtprelay02.dal12v.mail.ibm.com ([172.16.1.4]) by ppma23.wdc07v.mail.ibm.com (PPS) with ESMTPS id 4fc1nhtyk6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 17 Jul 2026 19:12:17 +0000 (GMT) Received: from smtpav06.dal12v.mail.ibm.com (smtpav06.dal12v.mail.ibm.com [10.241.53.105]) by smtprelay02.dal12v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 66HJCHoU57737610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 17 Jul 2026 19:12:17 GMT Received: from smtpav06.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id EDEA258055; Fri, 17 Jul 2026 19:12:16 +0000 (GMT) Received: from smtpav06.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 1255758043; Fri, 17 Jul 2026 19:12:10 +0000 (GMT) Received: from [9.43.55.154] (unknown [9.43.55.154]) by smtpav06.dal12v.mail.ibm.com (Postfix) with ESMTP; Fri, 17 Jul 2026 19:12:09 +0000 (GMT) Message-ID: <6baae2af-640e-48bd-9909-977cd316c8d5@linux.ibm.com> Date: Sat, 18 Jul 2026 00:42:08 +0530 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH v1 01/17] nvme-multipath: retarget failedover bios from requeue work To: Yu Kuai , Jens Axboe , Tejun Heo Cc: Christoph Hellwig , Keith Busch , Sagi Grimberg , Alasdair Kergon , Benjamin Marzinski , Mike Snitzer , Mikulas Patocka , Dongsheng Yang , Zheng Gu , Coly Li , Kent Overstreet , Josef Bacik , Yu Kuai , linux-block@vger.kernel.org, cgroups@vger.kernel.org, linux-nvme@lists.infradead.org, dm-devel@lists.linux.dev, linux-bcache@vger.kernel.org References: <20260704195124.1375075-1-yukuai@kernel.org> <20260704195124.1375075-2-yukuai@kernel.org> Content-Language: en-US From: Nilay Shroff In-Reply-To: <20260704195124.1375075-2-yukuai@kernel.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-Reinject: loops=2 maxloops=12 X-Authority-Analysis: v=2.4 cv=fOcJG5ae c=1 sm=1 tr=0 ts=6a5a7e92 cx=c_pps a=3Bg1Hr4SwmMryq2xdFQyZA==:117 a=3Bg1Hr4SwmMryq2xdFQyZA==:17 a=IkcTkHD0fZMA:10 a=RAioF0-LDSMA:10 a=VkNPw1HP01LnGYTKEx00:22 a=RnoormkPH1_aCDwRdu11:22 a=RzCfie-kr_QcCd8fBx8p:22 a=wsQ0yCsUK8wXSUUBpyMA:9 a=QEXdDO2ut3YA:10 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwNzE3MDE5NiBTYWx0ZWRfX7GLK2X+oF4UK iJeThXVkVapenyQ1sH1yQzUwapeLUMHpI0huFWOiHtJfQNJGfI1AW9PqYDCDJaalWjLAb5fPOLi rObNeXLBOt23K3q1VQphIm/q44BHhUb9tYA9yJ+jGMcMoxH546Qrp45+rZ9OWW8bOIV28gOnzf8 YgqxtHlNjs7EY8LYjgAz+w66QLqDLzNJRWLr3bU7ynTQdHWaMF+Rkzoo4jx2tSCcl/6BwzxuJAL 2cKIAIrg1RbOmDJqWsbBrZTxCYTe3hXA/nWJpCOFre1tVC80M4KK457ZHB65LrwjL+HtcCTA45l dy7OS19z1Md04qd8NHRRFI+S3gEtVTPbXBB6IAtwJ0evAH48I8RQQBAsRfnayc1UQ3VW6qZ3IAa K/uOHo/6hE9GO6Ge/WtkDU1Ihthtt2FYikg6ANYHtALL0Nm7Cop0K3ps9nDTseCQvXPyu/Mjmkr VqllyeAwrX0XtQN112w== X-Proofpoint-Spam-Info: AW1haW4tMjYwNzE3MDE5NiBTYWx0ZWRfX3W6AXglZxwK2 ueNSOqrmJUmdULiSN5cujIrGd1QIfi3DG8VyU8jYE1kNRBV1DK8ufGsGy4tT9OWcTt+Ji7SZxpY Q1H/NhS0jSlO20cMPivcrWp3EeohKfM= X-Proofpoint-GUID: qvRav-GNQoR5chPggKb6TgLJfY8amvqg X-Proofpoint-ORIG-GUID: ya_YvUqv2298obSTDavdmuJY0HegvuO_ X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-07-17_05,2026-07-17_01,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 bulkscore=0 impostorscore=0 suspectscore=0 adultscore=0 priorityscore=1501 malwarescore=0 clxscore=1011 phishscore=0 lowpriorityscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2607170196 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.9.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20260717_121250_561660_3F371B0D X-CRM114-Status: GOOD ( 28.34 ) X-BeenThere: linux-nvme@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "Linux-nvme" Errors-To: linux-nvme-bounces+linux-nvme=archiver.kernel.org@lists.infradead.org On 7/5/26 1:21 AM, Yu Kuai wrote: > From: Yu Kuai > > bio_set_dev() is about to become explicitly sleepable because it can > associate the bio with a blkg for the destination queue. NVMe failover > can run from request completion context, and nvme_failover_req() also holds > head->requeue_lock with interrupts disabled while it steals bios from the > failed request. Calling bio_set_dev() there is not safe once the helper is > allowed to sleep. > > The requeue lock only protects head->requeue_list. Keep the list > manipulation under that lock, but defer retargeting to nvme_requeue_work(), > which already drains the list from process context before resubmitting each > bio. The bios remain private to the requeue list until the worker pops > them, so moving the device switch there preserves the existing retry flow > while avoiding a sleepable helper in completion context. > > Signed-off-by: Yu Kuai > --- > drivers/nvme/host/multipath.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/drivers/nvme/host/multipath.c b/drivers/nvme/host/multipath.c > index 9b9a657fa330..76baa180ae1c 100644 > --- a/drivers/nvme/host/multipath.c > +++ b/drivers/nvme/host/multipath.c > @@ -149,7 +149,6 @@ void nvme_failover_req(struct request *req) > struct nvme_ns *ns = req->q->queuedata; > u16 status = nvme_req(req)->status & NVME_SCT_SC_MASK; > unsigned long flags; > - struct bio *bio; > > nvme_mpath_clear_current_path(ns); > atomic_long_inc(&ns->failover); > @@ -165,8 +164,6 @@ void nvme_failover_req(struct request *req) > } > > spin_lock_irqsave(&ns->head->requeue_lock, flags); > - for (bio = req->bio; bio; bio = bio->bi_next) > - bio_set_dev(bio, ns->head->disk->part0); > blk_steal_bios(&ns->head->requeue_list, req); > spin_unlock_irqrestore(&ns->head->requeue_lock, flags); > > @@ -684,6 +681,7 @@ static void nvme_requeue_work(struct work_struct *work) > next = bio->bi_next; > bio->bi_next = NULL; > > + bio_set_dev(bio, head->disk->part0); > submit_bio_noacct(bio); What happens if bio_set_dev() fails to associate a blkg? From what I understand, bio_associate_blkg() may fail, leaving bio->bi_blkg set to NULL. Later, submit_bio_noacct() can invoke blkcg-related helpers such as blk_should_throtl(), which expect a valid bio->bi_blkg. However if bio->bi_blkg is NULL then accessing it without NULL check could crash the kernel. This is probably not a bug introduced with your changes, but you may want to check it. The question is, is bio_associate_blkg() guaranteed never to fail, or should the failure be handled explicitly before the bio is resubmitted? I also skimmed through the rest of the series. However, as Christoph mentioned in an earlier thread, we may be moving away from non-blocking blkg allocation altogether. If that's the direction we're taking, this series will likely need to be reworked. I'd therefore prefer to wait for the next revision before reviewing the other patches. Thanks, --Nilay