Received: by 2002:a05:6359:c8b:b0:c7:702f:21d4 with SMTP id go11csp170215rwb; Wed, 21 Sep 2022 19:49:27 -0700 (PDT) X-Google-Smtp-Source: AMsMyM5+JNQsmdmAmK5RonuSMnQ/PL/JspxYUaglPtApz5sUiV1F4HxAXGpHssF76OkxBHeocTTL X-Received: by 2002:a05:6402:3549:b0:454:414e:a7fd with SMTP id f9-20020a056402354900b00454414ea7fdmr1082195edd.69.1663814967183; Wed, 21 Sep 2022 19:49:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1663814967; cv=none; d=google.com; s=arc-20160816; b=uWZa1tu5lENfGEwJiomxm9KJnL17ta4SV39IDkiGAhfrWNeXpPrzQO2HVhnxtBsA9O 66a9TXvVJNJCX5VQLE/mzzOVrUaFTZHmDsENX+zFpWrJHALduB4pVyG8YVop77Oh2Iml m6tZjdgglBim5s78UrE0/alpBAoQWSrf0Hqf+Dd2itmydEvNch+XYQkcWMcdYoYU1LNu mFlRGH1xKHLkd6Tp8TrGQeCHzVuNK3ayt34+3AFqMnnXRWBQwqVxhCVgT/svFWjywPyS 4wFkHUrUj4c/F+FUUND4ppK5yhN7/daLXg3gcUrqrHee1ox+JZ058BKYJI1VUGBTjzf4 B60Q== 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=c7hfnxoSS6uJD2Tv8ZxVkzjzf5sfEKgnnlmQaZ0kknk=; b=cfG/wxKr8PhMQ6yZ+Nupi4OwD9ke1aVHQYh1UaLrU9/QuTy43HzUFj2s2sxwKg/NsW qD8znRl8aVRA8BK4nn4y0JfPdAqOZX72Z3rG11CyuzLTbDGeECsCoVruR+awVsKbj8ud ctJH2BE7DS3YStZGmUB+TMZmbMxhil6tDWn1axeOivdjop4mVL3KsJLNZE0cy+eJloWu 1vxw32RttSePE8q3Idp6vczKZ+I4ZCdFFymifLJT+oUfUrEuP8YuX5BpajxzarZOKLcQ zMCbJvXySLh8TFnls1LKFS5w7EhzV050wiPnP3XXbkffDZ3JUdrJsh2iBdYTP3SNWs8y m2ow== 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 j21-20020a50ed15000000b0044eab363b67si3479029eds.130.2022.09.21.19.48.59; Wed, 21 Sep 2022 19:49:26 -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 S230035AbiIVCEm (ORCPT + 99 others); Wed, 21 Sep 2022 22:04:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33600 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229916AbiIVCEj (ORCPT ); Wed, 21 Sep 2022 22:04:39 -0400 Received: from out199-4.us.a.mail.aliyun.com (out199-4.us.a.mail.aliyun.com [47.90.199.4]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 14D9013CD5; Wed, 21 Sep 2022 19:04:36 -0700 (PDT) X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R511e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=ay29a033018046049;MF=ziyangzhang@linux.alibaba.com;NM=1;PH=DS;RN=6;SR=0;TI=SMTPD_---0VQQCF9u_1663812271; Received: from 30.97.56.134(mailfrom:ZiyangZhang@linux.alibaba.com fp:SMTPD_---0VQQCF9u_1663812271) by smtp.aliyun-inc.com; Thu, 22 Sep 2022 10:04:32 +0800 Message-ID: <19edc1a4-91ef-2384-2fc1-82f57303cc17@linux.alibaba.com> Date: Thu, 22 Sep 2022 10:04:29 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.13.0 Subject: Re: [PATCH V4 4/8] ublk_drv: requeue rqs with recovery feature enabled 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: <20220921095849.84988-1-ZiyangZhang@linux.alibaba.com> <20220921095849.84988-5-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=-13.6 required=5.0 tests=BAYES_00, ENV_AND_HDR_SPF_MATCH,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS, 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/9/22 08:28, Ming Lei wrote: > On Wed, Sep 21, 2022 at 05:58:45PM +0800, ZiyangZhang wrote: >> With recovery feature enabled, in ublk_queue_rq or task work >> (in exit_task_work or fallback wq), we requeue rqs instead of >> ending(aborting) them. Besides, No matter recovery feature is enabled >> or disabled, we schedule monitor_work immediately. >> >> Signed-off-by: ZiyangZhang >> --- >> drivers/block/ublk_drv.c | 31 +++++++++++++++++++++++++++++-- >> 1 file changed, 29 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/block/ublk_drv.c b/drivers/block/ublk_drv.c >> index 3bdac4bdf46f..b940e490ebab 100644 >> --- a/drivers/block/ublk_drv.c >> +++ b/drivers/block/ublk_drv.c >> @@ -655,6 +655,19 @@ static void ubq_complete_io_cmd(struct ublk_io *io, int res) >> >> #define UBLK_REQUEUE_DELAY_MS 3 >> >> +static inline void __ublk_abort_rq_in_task_work(struct ublk_queue *ubq, >> + struct request *rq) >> +{ >> + pr_devel("%s: %s q_id %d tag %d io_flags %x.\n", __func__, >> + (ublk_queue_can_use_recovery(ubq)) ? "requeue" : "abort", >> + ubq->q_id, rq->tag, ubq->ios[rq->tag].flags); >> + /* We cannot process this rq so just requeue it. */ >> + if (ublk_queue_can_use_recovery(ubq)) >> + blk_mq_requeue_request(rq, false); >> + else >> + blk_mq_end_request(rq, BLK_STS_IOERR); >> +} >> + >> static inline void __ublk_rq_task_work(struct request *req) >> { >> struct ublk_queue *ubq = req->mq_hctx->driver_data; >> @@ -677,7 +690,7 @@ static inline void __ublk_rq_task_work(struct request *req) >> * (2) current->flags & PF_EXITING. >> */ >> if (unlikely(current != ubq->ubq_daemon || current->flags & PF_EXITING)) { >> - blk_mq_end_request(req, BLK_STS_IOERR); >> + __ublk_abort_rq_in_task_work(ubq, req); >> mod_delayed_work(system_wq, &ub->monitor_work, 0); >> return; >> } >> @@ -752,6 +765,20 @@ static void ublk_rq_task_work_fn(struct callback_head *work) >> __ublk_rq_task_work(req); >> } >> >> +static inline blk_status_t __ublk_abort_rq(struct ublk_queue *ubq, >> + struct request *rq) >> +{ >> + pr_devel("%s: %s q_id %d tag %d io_flags %x.\n", __func__, >> + (ublk_queue_can_use_recovery(ubq)) ? "requeue" : "abort", >> + ubq->q_id, rq->tag, ubq->ios[rq->tag].flags); >> + /* We cannot process this rq so just requeue it. */ >> + if (ublk_queue_can_use_recovery(ubq)) { >> + blk_mq_requeue_request(rq, false); >> + return BLK_STS_OK; >> + } >> + return BLK_STS_IOERR; >> +} >> + > > Please remove the two added logging, otherwise this patch looks fine. OK, will do so in V5. Regards, Zhang