Received: by 2002:a05:6602:18e:0:0:0:0 with SMTP id m14csp4638133ioo; Tue, 31 May 2022 08:27:36 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzZZmP8uuKOXqhpixwI2bH7EK91daBgJjpj8OpjP7NWqopT12C80fGqcag2v18jJN67vyIa X-Received: by 2002:a17:902:e74e:b0:162:4ef1:2a77 with SMTP id p14-20020a170902e74e00b001624ef12a77mr36345048plf.48.1654010856257; Tue, 31 May 2022 08:27:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1654010856; cv=none; d=google.com; s=arc-20160816; b=QBSFAcELssoktQwywzm0dy/rx4YTL7e6fLOM+3E4vLh5ZXJwYyd8gSuPxrgd7n0V1F FrmrEps0GAkto/aidjIryW+HJIAhTYD7Tx2dhdPt0kO6kZG27jbmqHwigcNe1DGqyPgn lFiERi2GEMM5Xe2LkEcH+HhxEUKgU74s6q0zDX41N1nsMbnCgyyghgzo1G1Oxo9auhho pYRMnsd/wl/dP1CqOTYFPk8qvnRUCGftxHEAhGeRJcisCkUMQxz+d/F34tig2fAA5oTM WpIgCR6UwvLW9dFIXGPI8mzRNLzW6oJwoKbHZx5UfP9ZLwHzOZ/7tcHi3uN1Qkbsdylm pREA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=nJ7OOSCN98yB0sIpjIHaap4dzLFr4vuS5Ec7vmpxd68=; b=y/0BfuodGav23z9yabBlpEEyI7O0FtuP8AAha228BLHzUjA+BJ81BmUzku3YRWALZG xUski0brih/AKC9F/hYhTlh4GXzD6tEI85UTK8LWybmvs6KIgMG8sk2F8NWdfE7YKRk1 Ro/ur1Tn6hzH+10UEoDho5LKqHAKb80ixBXQrBFP2dlNyTNa9Eyx5j8qyWWaYO28gdVo EmPAbIpBB3Hhd/JIxEma+27yDLAXo7C1WQ7samiaYXMzkZBhndrDG92lqlYjCCnhw8W5 8VFAd+4CAKPRF9dXYCsYS0SCn+npD4ZvW3tOeQidPxOWE/+ZR7HYDWltyrP2MIxlyyRN ip2A== 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 Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id f19-20020a631f13000000b003fa34f0053esi20170566pgf.228.2022.05.31.08.27.23; Tue, 31 May 2022 08:27:36 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233296AbiE3HHM (ORCPT + 99 others); Mon, 30 May 2022 03:07:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35002 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233294AbiE3HHL (ORCPT ); Mon, 30 May 2022 03:07:11 -0400 Received: from jabberwock.ucw.cz (jabberwock.ucw.cz [46.255.230.98]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CA0DF62E7; Mon, 30 May 2022 00:07:02 -0700 (PDT) Received: by jabberwock.ucw.cz (Postfix, from userid 1017) id 7C4DF1C0B8A; Mon, 30 May 2022 09:07:01 +0200 (CEST) Date: Mon, 30 May 2022 09:07:00 +0200 From: Pavel Machek To: Ming Lei Cc: 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: <20220530070700.GF1363@bug> References: <20220509092312.254354-1-ming.lei@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220509092312.254354-1-ming.lei@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,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 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? What are restriction on ubdsrv? What happens when it needs to allocate memory, or is swapped out? Have mm people seen this? Best regards, Pavel