Received: by 2002:a05:6358:45e:b0:b5:b6eb:e1f9 with SMTP id 30csp2776024rwe; Sun, 28 Aug 2022 22:51:45 -0700 (PDT) X-Google-Smtp-Source: AA6agR7jvOBYKd7osrA019uIA4sOuDMZ/c9umImjP5c2leP3tBce0bR72Rxu/NvFN+hRUU4/qABz X-Received: by 2002:a17:902:f80f:b0:174:e9a9:7b84 with SMTP id ix15-20020a170902f80f00b00174e9a97b84mr939704plb.47.1661752305573; Sun, 28 Aug 2022 22:51:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1661752305; cv=none; d=google.com; s=arc-20160816; b=CIEIPB6XttyASvX9eitn4v/hhBRCXN74ZX9OYJZTMqcRt18LLu6ViZAPDIld9mH46G KQo6hyRsJAMVtcbvSKzuFRSIdCCw5zOME5LG/acN/nKhPWNbyYk4gzw5htcnw7wrHAq1 jX6RKyXB7fcSGLLn2oya3YkyY0M6H7PzGRgA855pzEH9iAiQxU/muAHYQ58P+5vHxdy7 TCQOrHTOhk91GmkJmBI7v0oSHJ+XlKu8YES5Phus/148udXZmsPL8U0Avo56aL8wS1mU YeTeNsqQ0LwwogVLCfMSUw/fY6rQRCO3+G5K/b38AxZoOsnpJND6dq0vNL2ibm3yfex4 4U/g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id; bh=dn7LqlC/UNWRhaxrmweupnM95lEYl6ojH/UTXbXJl+w=; b=rAyJFNqd8aD03qUD0NJO25DedF4e6bqWE8jBttgETPPnbAXcKO1z6m9nBZo375Fli4 HUlHRh73sHfGVDWkCNdHMPjZfvh5XDgqkgN29dlsSACmlRUaGDMEfIgSfHqYu23hku6Y mr+dmkvYN3we2HNMiU8tMAX2Zb1YnSZ46KTih1hnWauYk6I6O0JYWWc30ETrnfmuzxp5 QvDZu08pG9dG3y7KmTebG4ixBdRh4uE3PLCA7Zu+5VNaE6eTIfptPfHZEpv2u9lLGTyd Y8rP9qz3hWoReKvevgtao+rIshvaMcK0d3PflddWSJcfe5vgmZIhev6YI93i/qDhQ3RC uN+A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id 4-20020a631844000000b00411b6615b04si8569185pgy.599.2022.08.28.22.51.34; Sun, 28 Aug 2022 22:51:45 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229472AbiH2Eue (ORCPT + 99 others); Mon, 29 Aug 2022 00:50:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51336 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229577AbiH2Euc (ORCPT ); Mon, 29 Aug 2022 00:50:32 -0400 Received: from out30-130.freemail.mail.aliyun.com (out30-130.freemail.mail.aliyun.com [115.124.30.130]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BF6B025C5B; Sun, 28 Aug 2022 21:50:30 -0700 (PDT) X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R211e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=ay29a033018045168;MF=ziyangzhang@linux.alibaba.com;NM=1;PH=DS;RN=6;SR=0;TI=SMTPD_---0VNWpuCO_1661748626; Received: from 30.97.56.171(mailfrom:ZiyangZhang@linux.alibaba.com fp:SMTPD_---0VNWpuCO_1661748626) by smtp.aliyun-inc.com; Mon, 29 Aug 2022 12:50:27 +0800 Message-ID: Date: Mon, 29 Aug 2022 12:50:26 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.12.0 Subject: Re: [RFC PATCH 2/9] ublk_drv: refactor ublk_cancel_queue() Content-Language: en-US To: Ming Lei Cc: axboe@kernel.dk, xiaoguang.wang@linux.alibaba.com, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, joseph.qi@linux.alibaba.com References: <20220824054744.77812-1-ZiyangZhang@linux.alibaba.com> <20220824054744.77812-3-ZiyangZhang@linux.alibaba.com> From: Ziyang Zhang In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-9.9 required=5.0 tests=BAYES_00, ENV_AND_HDR_SPF_MATCH,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE,UNPARSEABLE_RELAY,USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2022/8/29 11:01, Ming Lei wrote: > On Wed, Aug 24, 2022 at 01:47:37PM +0800, ZiyangZhang wrote: >> Assume only a few FETCH_REQ ioucmds are sent to ublk_drv, then the >> ubq_daemon exits, We have to call io_uring_cmd_done() for all ioucmds >> received so that io_uring ctx will not leak. >> >> ublk_cancel_queue() may be called before START_DEV or after STOP_DEV, >> we decrease ubq->nr_io_ready and clear UBLK_IO_FLAG_ACTIVE so that we >> won't call io_uring_cmd_done() twice for one ioucmd to avoid UAF. Also >> clearing UBLK_IO_FLAG_ACTIVE makes the code more reasonable. >> >> Signed-off-by: ZiyangZhang >> --- >> drivers/block/ublk_drv.c | 11 ++++++++--- >> 1 file changed, 8 insertions(+), 3 deletions(-) >> >> diff --git a/drivers/block/ublk_drv.c b/drivers/block/ublk_drv.c >> index c39b67d7133d..e08f636b0b9d 100644 >> --- a/drivers/block/ublk_drv.c >> +++ b/drivers/block/ublk_drv.c >> @@ -967,18 +967,23 @@ static void ublk_cancel_queue(struct ublk_queue *ubq) >> { >> int i; >> >> - if (!ublk_queue_ready(ubq)) >> + if (!ubq->nr_io_ready) >> return; >> >> for (i = 0; i < ubq->q_depth; i++) { >> struct ublk_io *io = &ubq->ios[i]; >> >> - if (io->flags & UBLK_IO_FLAG_ACTIVE) >> + if (io->flags & UBLK_IO_FLAG_ACTIVE) { >> + pr_devel("%s: done old cmd: qid %d tag %d\n", >> + __func__, ubq->q_id, i); >> io_uring_cmd_done(io->cmd, UBLK_IO_RES_ABORT, 0); >> + io->flags &= ~UBLK_IO_FLAG_ACTIVE; >> + ubq->nr_io_ready--; >> + } >> } >> >> /* all io commands are canceled */ >> - ubq->nr_io_ready = 0; >> + WARN_ON_ONCE(ubq->nr_io_ready); > > The change looks fine, but suggest to add comment like the > following given the above WARN_ON_ONCE() change isn't obvious. > > ``` > 1) ublk_cancel_dev() is called before sending START_DEV(), ->mutex > provides protection on above update. > > 2) ublk_cancel_dev() is called after sending START_DEV(), disk is > deleted first, UBLK_IO_RES_ABORT is returned so that any new io > command can't be issued to driver, so updating on io flags and > nr_io_ready is safe here > > Also ->nr_io_ready is guaranteed to become zero after ublk_cance_queue > returns since request queue is either frozen or not present in both two cases. > > ``` > Thanks for your advice, Ming. Regards, Zhang