From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B477CC433EF for ; Mon, 6 Jun 2022 02:15:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240339AbiFFCPn (ORCPT ); Sun, 5 Jun 2022 22:15:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38036 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232360AbiFFCPm (ORCPT ); Sun, 5 Jun 2022 22:15:42 -0400 Received: from out30-42.freemail.mail.aliyun.com (out30-42.freemail.mail.aliyun.com [115.124.30.42]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2332D366A4; Sun, 5 Jun 2022 19:15:39 -0700 (PDT) X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R541e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e04423;MF=hsiangkao@linux.alibaba.com;NM=1;PH=DS;RN=9;SR=0;TI=SMTPD_---0VFPsTeZ_1654481735; Received: from B-P7TQMD6M-0146.local(mailfrom:hsiangkao@linux.alibaba.com fp:SMTPD_---0VFPsTeZ_1654481735) by smtp.aliyun-inc.com(127.0.0.1); Mon, 06 Jun 2022 10:15:37 +0800 Date: Mon, 6 Jun 2022 10:15:35 +0800 From: Gao Xiang To: Ming Lei Cc: Pavel Machek , Jens Axboe , linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, io-uring@vger.kernel.org, Gabriel Krisman Bertazi , ZiyangZhang , Xiaoguang Wang Subject: Re: [RFC PATCH] ubd: add io_uring based userspace block driver Message-ID: Mail-Followup-To: Ming Lei , Pavel Machek , Jens Axboe , linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, io-uring@vger.kernel.org, Gabriel Krisman Bertazi , ZiyangZhang , Xiaoguang Wang References: <20220509092312.254354-1-ming.lei@redhat.com> <20220530070700.GF1363@bug> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org On Thu, Jun 02, 2022 at 11:19:42AM +0800, Ming Lei wrote: > Hello Pavel, > > On Mon, May 30, 2022 at 09:07:00AM +0200, Pavel Machek wrote: > > Hi! > > > > > This is the driver part of userspace block driver(ubd driver), the other > > > part is userspace daemon part(ubdsrv)[1]. > > > > > @@ -0,0 +1,1193 @@ > > > +// SPDX-License-Identifier: GPL-2.0-or-later > > > +/* > > > + * Userspace block device - block device which IO is handled from userspace > > > + * > > > + * Take full use of io_uring passthrough command for communicating with > > > + * ubd userspace daemon(ubdsrvd) for handling basic IO request. > > > > > + > > > +static inline unsigned int ubd_req_build_flags(struct request *req) > > > +{ > > ... > > > + if (req->cmd_flags & REQ_SWAP) > > > + flags |= UBD_IO_F_SWAP; > > > + > > > + return flags; > > > +} > > > > Does it work? How do you guarantee operation will be deadlock-free with swapping and > > writebacks going on? > > The above is just for providing command flags to user side, so that the > user side can understand/handle the request better. > > prtrl(PR_SET_IO_FLUSHER) has been merged for avoiding the deadlock. > I've pointed out a case before that (I think) PR_SET_IO_FLUSHER doesn't work: https://lore.kernel.org/all/YhbYOeMUv5+U1XdQ@B-P7TQMD6M-0146.local I don't think handling writeback in the userspace under the direct reclaim context is _safe_ honestly. Because userspace program can call any system call under direct reclaim, which can interconnect to another process context and wait for it. yet I don't look into ubd implementation. Thanks, Gao Xiang