From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on gnuweeb.org X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_PASS,SPF_SOFTFAIL, UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.6 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9218CC433EF for ; Tue, 17 May 2022 10:01:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233269AbiEQKBJ (ORCPT ); Tue, 17 May 2022 06:01:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53272 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S245633AbiEQKBF (ORCPT ); Tue, 17 May 2022 06:01:05 -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 B245B41F91; Tue, 17 May 2022 03:01:01 -0700 (PDT) X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R741e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e04423;MF=ziyangzhang@linux.alibaba.com;NM=1;PH=DS;RN=9;SR=0;TI=SMTPD_---0VDUBn8Y_1652781657; Received: from 30.39.94.219(mailfrom:ZiyangZhang@linux.alibaba.com fp:SMTPD_---0VDUBn8Y_1652781657) by smtp.aliyun-inc.com(127.0.0.1); Tue, 17 May 2022 18:00:58 +0800 Message-ID: <55d724a8-ed7d-ae92-ca6d-3582e13587db@linux.alibaba.com> Date: Tue, 17 May 2022 18:00: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.8.1 Subject: Re: [PATCH V2 1/1] ubd: add io_uring based userspace block driver Content-Language: en-US To: Ming Lei Cc: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, Harris James R , io-uring@vger.kernel.org, Gabriel Krisman Bertazi , Xiaoguang Wang , Stefan Hajnoczi , Jens Axboe References: <20220517055358.3164431-1-ming.lei@redhat.com> <20220517055358.3164431-2-ming.lei@redhat.com> From: Ziyang Zhang In-Reply-To: <20220517055358.3164431-2-ming.lei@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: io-uring@vger.kernel.org On 2022/5/17 13:53, Ming Lei wrote: > + > +static void ubd_cancel_queue(struct ubd_queue *ubq) > +{ > + int i; > + > + for (i = 0; i < ubq->q_depth; i++) { > + struct ubd_io *io = &ubq->ios[i]; > + > + if (io->flags & UBD_IO_FLAG_ACTIVE) { > + io->flags &= ~UBD_IO_FLAG_ACTIVE; > + io_uring_cmd_done(io->cmd, UBD_IO_RES_ABORT, 0); > + } > + } > +} Hi Ming, When ubdsrv sends STOP_DEV and all active IOs in ubd_drv are done(UBD_IO_RES_ABORT), there may be still some IOs handled by ubdsrv(UBD_IO_FLAG_ACTIVE not set). When these IOs complete and return to ubd_drv, how to handle them? I find that UBD_IO_FETCH_REQ are still set, so will these IOs be issued to ubdsrv again or canceled? (I see ubd_drv fails IOs when the daemon is dying but maybe here the daemon is still alive) > + > +/* Cancel all pending commands, must be called after del_gendisk() returns */ > +static void ubd_cancel_dev(struct ubd_device *ub) > +{ > + int i; > + > + for (i = 0; i < ub->dev_info.nr_hw_queues; i++) > + ubd_cancel_queue(ubd_get_queue(ub, i)); > +} > + > +static void ubd_stop_dev(struct ubd_device *ub) > +{ > + mutex_lock(&ub->mutex); > + if (!disk_live(ub->ub_disk)) > + goto unlock; > + > + del_gendisk(ub->ub_disk); > + ub->dev_info.state = UBD_S_DEV_DEAD; > + ub->dev_info.ubdsrv_pid = -1; > + ubd_cancel_dev(ub); > + unlock: > + mutex_unlock(&ub->mutex); > + cancel_delayed_work_sync(&ub->monitor_work); > +} > + > +static int ubd_ctrl_stop_dev(struct ubd_device *ub) > +{ > + ubd_stop_dev(ub); > + return 0; > +} > +