Received: by 2002:a05:6358:45e:b0:b5:b6eb:e1f9 with SMTP id 30csp2695873rwe; Sun, 28 Aug 2022 20:07:14 -0700 (PDT) X-Google-Smtp-Source: AA6agR48To00E2svP0Nd1CuUD/5qutACPSeFQz5WOs/l0G91xfR9hvbHKNG1q5PM5qiObXzO3T9u X-Received: by 2002:a05:6402:33c5:b0:447:e4a3:c930 with SMTP id a5-20020a05640233c500b00447e4a3c930mr10677749edc.401.1661742434706; Sun, 28 Aug 2022 20:07:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1661742434; cv=none; d=google.com; s=arc-20160816; b=RPm7yRdZxJTdGzQGNboGveFmcg05nKmNkQAmm2XHHDToXHOmImCZ3WCVZGXFa6yilk y42R/Ay922W1ZSOyaNrOitORbvxkxI1xNQqSfscvAdq6ctmbmui22sVvX09SRb4ONcsE ZlnT7ASKoNB+3e01AAgw4NMoc01Q4gpz+gUf+NVN+pLBRhYT4AW7o4R4xe4cFV0KyWwX KbbMexHrI7MElTHI0s0s788AR93W1Bk+NoKUj/rAV+dxkUVnoGmVJ5diKq2NPUjrHVcC Si8OfCEaLrm7yLp+IOqmD9GI3ndLFbWF5epIU39Me6S5TTpfyeGWF8UaFh3IZ/4Fpsy7 JdyA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=J3eYJm2AtdKAUutUhamGeD2WJMAiL0MgHbUn5Jwkdx4=; b=zPtdmk9DO9ytVAHkDvqujvx3jInvfhEXxVeatfc4ichMb544B4CXY1xqjRx6ovmwZx eVypzB2Xb4yiIg5QjHYuen7ABqnLE/yO8D2HEE/NOUJiIY3TifRaTAf7djfSkJw+IZTu f7wx6UgVnqHXPDrh4zKDPm+ahc76X24ITt0k2/K2bRL9xfuMXKy6S+556tvAdaTdpI2u HyVcfUMxIHYpKQlY8JvwyN6lbJv4WeQCp3fdmcPZupOgtGACLYxgTCciOemwQD2y6z4j AIH9aEpYew/boEsf07j+7kzUo2V1+SlQGZmHJ2J+JqLK2WvWNmlaeutyS2s6GUOCGTS7 zU2Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=JIOTRJry; 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=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id ky13-20020a170907778d00b0072f97d98a50si5210197ejc.945.2022.08.28.20.06.49; Sun, 28 Aug 2022 20:07:14 -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; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=JIOTRJry; 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=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229622AbiH2DB3 (ORCPT + 99 others); Sun, 28 Aug 2022 23:01:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34552 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229668AbiH2DBY (ORCPT ); Sun, 28 Aug 2022 23:01:24 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E78CA3D58D for ; Sun, 28 Aug 2022 20:01:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1661742083; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=J3eYJm2AtdKAUutUhamGeD2WJMAiL0MgHbUn5Jwkdx4=; b=JIOTRJry34y/PCAYw/ZyvgdsC2siIM0nIxumieq1Di3CdvjfNzbuWHJsKyepLFfFPN2sFA 6UYSh58LK+zxOAUCZXhta1o3+VMl6nlCLX1Zign1IIQPkuBdvaSC0UV8swjlSR2CTW5TEK VdHw4swCPDfxBJhsJhv/bTyhSx20t2o= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-307-Ob_JffuqOqiPVcKJZWhIjw-1; Sun, 28 Aug 2022 23:01:19 -0400 X-MC-Unique: Ob_JffuqOqiPVcKJZWhIjw-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 24EDD3C11059; Mon, 29 Aug 2022 03:01:19 +0000 (UTC) Received: from T590 (ovpn-8-18.pek2.redhat.com [10.72.8.18]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 195F62166B26; Mon, 29 Aug 2022 03:01:14 +0000 (UTC) Date: Mon, 29 Aug 2022 11:01:11 +0800 From: Ming Lei To: ZiyangZhang Cc: axboe@kernel.dk, xiaoguang.wang@linux.alibaba.com, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, joseph.qi@linux.alibaba.com Subject: Re: [RFC PATCH 2/9] ublk_drv: refactor ublk_cancel_queue() Message-ID: References: <20220824054744.77812-1-ZiyangZhang@linux.alibaba.com> <20220824054744.77812-3-ZiyangZhang@linux.alibaba.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220824054744.77812-3-ZiyangZhang@linux.alibaba.com> X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW, SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE 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 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, Ming