Received: by 2002:a05:6359:c8b:b0:c7:702f:21d4 with SMTP id go11csp3342427rwb; Mon, 19 Sep 2022 20:16:22 -0700 (PDT) X-Google-Smtp-Source: AMsMyM4jpOpHj+H4ZpXXQOsoGxq15BE6xm9Ln3ij24DjrpEwcjCH1S+XsyY2AvgdomBbA8mr4Qpu X-Received: by 2002:a05:6402:ca9:b0:44e:d8f3:3d0e with SMTP id cn9-20020a0564020ca900b0044ed8f33d0emr18174606edb.397.1663643782100; Mon, 19 Sep 2022 20:16:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1663643782; cv=none; d=google.com; s=arc-20160816; b=jcieMXKjb6EkT/cZo+pUchSJHZyhNHp2XH2JADHdtD1B8H45yENnHjcVRbNUKPaM+n 1WisHP3MCFKi9A+UpMDN6POKGVAonAvTUxgnOu75mJKJdbXwuu+Zjjt0c1in8HndsHOy z1MZ1Qrxkuuc5MeuvWPB89ifu46vzf4gn8uK7H4UlNUeFwh1IKrefnaZRlsfgfOniKKS dBYxytipFVplcII+qWuduRB2Tged1WNsHERU82CXneoNTDGZmHLtnnfC6QnyGCaLw6a2 Esek0/X/zcDctVctE8cLIulnWmReEq00b3U5xDDoAa7s5n9MrLuURlm9QRhcObML4Kny bTcA== 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=/c07mniWr5G9tThtZCp5Pu9qD37FGE78F51vpVd8pAw=; b=YN8o+r7H+6cf81GUmYPxvkvSKokm2pF9oQvgCS9yzWpOw5dhFK75pgnLy+IO45vdfM 8oUNKvcUYCDSS6McPL94Z6QxrWX04J1q2P0vCGWXIDbIiI9wtVVjZM5hD1lzTv9xeEps WSY7E2ssbvd9PIARWJEgoZXUevlZXYzrhWBpqVPfb/9HhmfZK5v8ERncEn4TW+awqhz7 zQIbzlroXv1Nw1sQCd2u3Hg5jOHeFQWF4TOOhcgmZiDDY1XXYqj5/DlQq2oqx/q69JB+ khFhJikF383TGnXB2pkCYR0w4IPn1vYhjWbrA73slvQdH3jBVt14gi7NjfnXGxr9gyLP qI0Q== 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 o5-20020a056402038500b0044816be3ec8si412998edv.435.2022.09.19.20.15.56; Mon, 19 Sep 2022 20:16:22 -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 S230221AbiITCmT (ORCPT + 99 others); Mon, 19 Sep 2022 22:42:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44966 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230177AbiITCmJ (ORCPT ); Mon, 19 Sep 2022 22:42:09 -0400 Received: from out30-54.freemail.mail.aliyun.com (out30-54.freemail.mail.aliyun.com [115.124.30.54]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6A2DC3C16E; Mon, 19 Sep 2022 19:42:03 -0700 (PDT) X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R181e4;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_---0VQGxJtb_1663641719; Received: from 30.97.56.91(mailfrom:ZiyangZhang@linux.alibaba.com fp:SMTPD_---0VQGxJtb_1663641719) by smtp.aliyun-inc.com; Tue, 20 Sep 2022 10:42:00 +0800 Message-ID: <341e500b-487d-f16a-8ba6-399e2972b685@linux.alibaba.com> Date: Tue, 20 Sep 2022 10:41:57 +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 V3 6/7] ublk_drv: add START_USER_RECOVERY and END_USER_RECOVERY support 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: <20220913041707.197334-1-ZiyangZhang@linux.alibaba.com> <20220913041707.197334-7-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=-10.9 required=5.0 tests=BAYES_00, ENV_AND_HDR_SPF_MATCH,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,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/19 21:03, Ming Lei wrote: > On Tue, Sep 13, 2022 at 12:17:06PM +0800, ZiyangZhang wrote: >> START_USER_RECOVERY and END_USER_RECOVERY are two new control commands >> to support user recovery feature. >> >> After a crash, user should send START_USER_RECOVERY, it will: >> (1) check if (a)current ublk_device is UBLK_S_DEV_QUIESCED which was >> set by quiesce_work and (b)the file struct is released. >> (2) reinit all ubqs, including: >> (a) put the task_struct and reset ->ubq_daemon to NULL. >> (b) reset all ublk_io. >> (3) reset ub->mm to NULL. >> >> Then, user should start a new process and send FETCH_REQ on each >> ubq_daemon. >> >> Finally, user should send END_USER_RECOVERY, it will: >> (1) wait for all new ubq_daemons getting ready. >> (2) update ublksrv_pid >> (3) unquiesce the request queue and expect incoming ublk_queue_rq() >> (4) convert ub's state to UBLK_S_DEV_LIVE >> >> Note: we can handle STOP_DEV between START_USER_RECOVERY and >> END_USER_RECOVERY. This is helpful to users who cannot start new process >> after sending START_USER_RECOVERY ctrl-cmd. >> >> Signed-off-by: ZiyangZhang >> --- >> drivers/block/ublk_drv.c | 116 +++++++++++++++++++++++++++++++++++++++ >> 1 file changed, 116 insertions(+) >> >> diff --git a/drivers/block/ublk_drv.c b/drivers/block/ublk_drv.c >> index 4409a130d0b6..3a3af80ee938 100644 >> --- a/drivers/block/ublk_drv.c >> +++ b/drivers/block/ublk_drv.c >> @@ -1961,6 +1961,116 @@ static int ublk_ctrl_set_params(struct io_uring_cmd *cmd) >> return ret; >> } >> >> +static void ublk_queue_reinit(struct ublk_device *ub, struct ublk_queue *ubq) >> +{ >> + int i; >> + >> + WARN_ON_ONCE(!(ubq->ubq_daemon && ubq_daemon_is_dying(ubq))); >> + /* All old ioucmds have to be completed */ >> + WARN_ON_ONCE(ubq->nr_io_ready); >> + pr_devel("%s: prepare for recovering qid %d\n", __func__, ubq->q_id); >> + /* old daemon is PF_EXITING, put it now */ >> + put_task_struct(ubq->ubq_daemon); >> + /* We have to reset it to NULL, otherwise ub won't accept new FETCH_REQ */ >> + ubq->ubq_daemon = NULL; >> + >> + for (i = 0; i < ubq->q_depth; i++) { >> + struct ublk_io *io = &ubq->ios[i]; >> + >> + /* forget everything now and be ready for new FETCH_REQ */ >> + io->flags = 0; >> + io->cmd = NULL; >> + io->addr = 0; >> + } >> +} >> + >> +static int ublk_ctrl_start_recovery(struct io_uring_cmd *cmd) >> +{ >> + struct ublksrv_ctrl_cmd *header = (struct ublksrv_ctrl_cmd *)cmd->cmd; >> + struct ublk_device *ub; >> + int ret = -EINVAL; >> + int i; >> + >> + ub = ublk_get_device_from_id(header->dev_id); >> + if (!ub) >> + return ret; >> + >> + mutex_lock(&ub->mutex); >> + if (!ublk_can_use_recovery(ub)) >> + goto out_unlock; >> + /* >> + * START_RECOVERY is only allowd after: >> + * >> + * (1) UB_STATE_OPEN is not set, which means the dying process is exited >> + * and related io_uring ctx is freed so file struct of /dev/ublkcX is >> + * released. >> + * >> + * (2) UBLK_S_DEV_QUIESCED is set, which means the quiesce_work: >> + * (a)has quiesced request queue >> + * (b)has requeued every inflight rqs whose io_flags is ACTIVE >> + * (c)has requeued/aborted every inflight rqs whose io_flags is NOT ACTIVE >> + * (d)has completed/camceled all ioucmds owned by ther dying process >> + */ >> + if (test_bit(UB_STATE_OPEN, &ub->state) || >> + ub->dev_info.state != UBLK_S_DEV_QUIESCED) { >> + ret = -EBUSY; >> + goto out_unlock; >> + } >> + pr_devel("%s: start recovery for dev id %d.\n", __func__, header->dev_id); >> + for (i = 0; i < ub->dev_info.nr_hw_queues; i++) >> + ublk_queue_reinit(ub, ublk_get_queue(ub, i)); >> + /* set to NULL, otherwise new ubq_daemon cannot mmap the io_cmd_buf */ >> + ub->mm = NULL; >> + ub->nr_queues_ready = 0; > > I am wondering why you don't move the above(queue reinit, clearing ub->mm) > into ublk_ch_release(), and looks it is more clean to clear this stuff > there. Meantime I guess one control command might be enough for user > recovery. OK, START_USER_RECOVERY just does cleanup stuff for a new process and ublk_ch_release() does the similar thing since it is always called when chardev is released. And our new process must open the chardev after it is released. So (queue reinit, clearing ub->mm) can be done in ublk_ch_release(). Regards, Zhang.