Message ID | 20230624230950.2272-1-demi@invisiblethingslab.com |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:994d:0:b0:3d9:f83d:47d9 with SMTP id k13csp6640615vqr; Sat, 24 Jun 2023 16:18:04 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ4hAJmQwl12jbaM8VW64q2JIaElhCNQ50YR5FX/k9fVnedzrrB014/ddEl0bbE/InsjQ4rA X-Received: by 2002:a05:6808:2385:b0:3a0:6208:b185 with SMTP id bp5-20020a056808238500b003a06208b185mr10414613oib.49.1687648683769; Sat, 24 Jun 2023 16:18:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1687648683; cv=none; d=google.com; s=arc-20160816; b=dOxwPMOeqjOYV0q7Lc5HoppuAWq13OCVvCMHqtm9YdgvPMQ4A+ADmeM2e41j7siMdw MaNPCmYtur8qxCLUTdkVZ58S1scX6zggp/MKtydsP1zwOepmMkwkjIcBKhJhpg/8qsTv uJvuTsxbF4aa3x1T4y50suYlCT/cnVEa4BkyTOlbBM+JoIbTMjEUe+ypk7F9wIKFkwXl NoCs7gDBeLWwWnKxDLZSL6ojzqaB9cRLcrJaCZBbACphirPuHq3zq3RrdmhgCv6iKbhc QCz8gDGiCMAmgucjZh1G6mKDEp6WiDWMZvEgpOeqYYoZj8S7+x9KWfT0XNv/UsnrDthO eOog== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:feedback-id:dkim-signature :dkim-signature; bh=LsDkS9pGWUmtwQ/it8iQoRg4trvNKXyKWbwxvK6Qf4Y=; fh=ilKYNij4GbkL73Vw412lTCleAypti6/OwfflBBUJP2g=; b=fNitINeyyVeDLOb7qRd+x5FrWqiHE37TBVAtfT08g2ck1cfsWwakY/cg/9a2yXp3/L YIxa4eFPho0VyargtX0inw/V0yb32lWVB7RkyCPOEmQ6W/Oq94yrT8f3ARKEbizSVwOS aILGzQ95rwpVbDOs1IY2QsxszAJk4Tz0a6B8K9vVYhLJvv6SX1I+ONvJ1Gf1wDWkArlj FM3PEz5u3CE1ebqPXUp1LNtpeJg2D4D0d1BzHY+SEyo12KbWxAy3bF8JkLEMxiuBDMy9 yHfOK6AtwOOB5s0VhlFWdRGYR5x9MFsgRhVPsfCdRFk6DsCckdHOHGQ9xDFtjJT10nt7 NJfg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@invisiblethingslab.com header.s=fm2 header.b=Z311eWtd; dkim=pass header.i=@messagingengine.com header.s=fm2 header.b=BeuHP9Je; 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: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id i13-20020a17090ad34d00b0025ea380f868si4713524pjx.2.2023.06.24.16.17.49; Sat, 24 Jun 2023 16:18:03 -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; dkim=pass header.i=@invisiblethingslab.com header.s=fm2 header.b=Z311eWtd; dkim=pass header.i=@messagingengine.com header.s=fm2 header.b=BeuHP9Je; 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 S229864AbjFXXKA (ORCPT <rfc822;duw91626@gmail.com> + 99 others); Sat, 24 Jun 2023 19:10:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47882 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229496AbjFXXJ6 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Sat, 24 Jun 2023 19:09:58 -0400 Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BDF261710 for <linux-kernel@vger.kernel.org>; Sat, 24 Jun 2023 16:09:55 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id BCE7C3200065; Sat, 24 Jun 2023 19:09:54 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Sat, 24 Jun 2023 19:09:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= invisiblethingslab.com; h=cc:cc:content-transfer-encoding :content-type:date:date:from:from:in-reply-to:message-id :mime-version:reply-to:sender:subject:subject:to:to; s=fm2; t= 1687648194; x=1687734594; bh=LsDkS9pGWUmtwQ/it8iQoRg4trvNKXyKWbw xvK6Qf4Y=; b=Z311eWtdfZZdzMVJY+cCZ4lLbj3VY+FRSq2D2T0UIYzSufoOb9p k3+6s1l4CdzztiC0Gwlxw00CTb7nhlby9pdXzU5sWF06hi2A7WRUXu1jC7RTqniZ Y06oxQcRl5qvBoZois5eF5O9rlaZP/5zDps3kJsuDJQJ2BLOKdve6VJWv1fcNDGh vP1HfwuEIQUCsEFy7ZzuBQIfWKWW473SxPyxEXLIcKh0w2OQ7Fk7ZI+34YCxfV71 CXRHHVZWDxXRamyH3MWhAe4m3dR17+aHxdKk9a6gG6MMcmhrn3vhz+ITPls2Mk72 qdpRdnwL1kopuAgGJcjL/CL4nugRriUeK0Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:message-id:mime-version:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; t=1687648194; x=1687734594; bh=LsDkS9pGWUmtw Q/it8iQoRg4trvNKXyKWbwxvK6Qf4Y=; b=BeuHP9JePZWfv1KjmffHIRYH+8JE0 v7HZyAmM0LZj3IswHZc2R1rVlldK02aRQ3RTI5UPXadIG23OS4df7kg35HFB3M2l kv9Elk+8dtLR7yZ1UH7Fv8+gzyjYGDIYJXrWcpe9ZXpNjt5kvyzLKPdITL9M8yHN 3SSJt9wuoyWo2UUB9s/9EzDcB1ZwmTnpkTkI/sL/fF6rura8j4fGCwZzRgIsjNsw wrIqBB3SjR4dG9wohZns/1gVofR/hNdyKsqX/o5hoaeNXZdTlyFuEXvh76gsJf75 FievnyafQ/NipfFKo4vUVSGxCWIxr78IS0E6rpl6/+4uiep/jYgnEJc9w== X-ME-Sender: <xms:wneXZOzpDMXyHB5nNGihQDlwEvm80EBrOvlC7u8oELUKq-ClfMJzsw> <xme:wneXZKS9LxYIa9-xfvtRxMt6OM-kuGBdL8LsQFY_EmJqoyji-fY9IxSbm0TiZhfHL Tv0d-eq0TN7a14> X-ME-Received: <xmr:wneXZAVvRVlejMu023IVEBvLIgwq7HKeE6-hP_ws8zk4QswXOjZP5OiFHLzRNOeZg191CheYFpA> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrgeegkedgudekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufffkofgggfestdekredtredttdenucfhrhhomhepffgvmhhiucfo rghrihgvucfqsggvnhhouhhruceouggvmhhisehinhhvihhsihgslhgvthhhihhnghhslh grsgdrtghomheqnecuggftrfgrthhtvghrnhepvdefgeekvdekgfffgeekhfeijedtffek hefhleehfeejueetgfelgefgtdevieelnecuvehluhhsthgvrhfuihiivgeptdenucfrrg hrrghmpehmrghilhhfrhhomhepuggvmhhisehinhhvihhsihgslhgvthhhihhnghhslhgr sgdrtghomh X-ME-Proxy: <xmx:wneXZEgvzlc8nVYPOhk5f79G5koevQvdF9XTFkPt7YtRffBoAVRdaQ> <xmx:wneXZACW6ONEW_NBXszyPtQivp26sWwGhzAyC2mvLaeoRmEytclsTA> <xmx:wneXZFJ6sskoNJVl1UxJa9EJPJGHvT0uE5dBj_PfNP1HaAx1Z0v7qQ> <xmx:wneXZDNj8EA4ceoM3u9pdPZMiVmQ9XlubqorahAvGwxnbj62_01Utw> Feedback-ID: iac594737:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 24 Jun 2023 19:09:53 -0400 (EDT) From: Demi Marie Obenour <demi@invisiblethingslab.com> To: Alasdair Kergon <agk@redhat.com>, Mike Snitzer <snitzer@kernel.org>, dm-devel@redhat.com Cc: Demi Marie Obenour <demi@invisiblethingslab.com>, linux-kernel@vger.kernel.org Subject: [PATCH v2 0/4] Diskseq support in device-mapper Date: Sat, 24 Jun 2023 19:09:43 -0400 Message-ID: <20230624230950.2272-1-demi@invisiblethingslab.com> X-Mailer: git-send-email 2.41.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS, SPF_NONE,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED 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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1769627905982032004?= X-GMAIL-MSGID: =?utf-8?q?1769627905982032004?= |
Series |
Diskseq support in device-mapper
|
|
Message
Demi Marie Obenour
June 24, 2023, 11:09 p.m. UTC
This work aims to allow userspace to create and destroy device-mapper devices in a race-free way. Changes since v1: - Potentially backwards-incompatible changes to device-mapper now require userspace opt-in. - The code has been tested: I have a block script written in C that uses these changes to successfully boot a Xen VM. - The core block layer is completely untouched. Instead of exposing a block device inode directly to userspace, device-mapper ioctls that create a block device now return that device's diskseq. Userspace can then use that diskseq to safely open the device. Furthermore, ioctls that operate on an existing device-mapper device now accept a diskseq parameter, which can be used to prevent races. Demi Marie Obenour (4): dm ioctl: Allow userspace to opt-in to strict parameter checks dm ioctl: Allow userspace to provide expected diskseq dm ioctl: Allow userspace to suppress uevent generation dm ioctl: inform caller about already-existing device drivers/md/dm-core.h | 2 + drivers/md/dm-ioctl.c | 351 ++++++++++++++++++++++++++++------ drivers/md/dm.c | 5 +- include/linux/device-mapper.h | 2 +- include/uapi/linux/dm-ioctl.h | 90 ++++++++- 5 files changed, 382 insertions(+), 68 deletions(-)
Comments
On Sat, 2023-06-24 at 19:09 -0400, Demi Marie Obenour wrote: > This work aims to allow userspace to create and destroy device-mapper > devices in a race-free way. The discussion about this feature seems to have stalled ... will there be a v3 of this series any time soon? Also, I am wondering what should happen if a device-mapper table is changed in a SUSPEND/LOAD/RESUME cycle. Such operations can change the content of the device, thus I assume that the diskseq should also change. But AFAICS this wasn't part of your patch set. In general, whether the content changes in a reload operation depends on the target. The multipath target, for example, reloads frequently without changing the content of the dm device. An ever-changing diskseq wouldn't make a lot of sense for dm-multipath. But I doubt we want to start making distinctions on this level, so I guess that diskseq and multipath just won't go well together. Regards, Martin
On Mon, Jan 15, 2024 at 06:56:16PM +0100, Martin Wilck wrote: > On Sat, 2023-06-24 at 19:09 -0400, Demi Marie Obenour wrote: > > This work aims to allow userspace to create and destroy device-mapper > > devices in a race-free way. > > The discussion about this feature seems to have stalled ... will there > be a v3 of this series any time soon? I’m still interested in a v3, but it might take a while. If you are willing and able to do it first, I recommend that you do so. > Also, I am wondering what should happen if a device-mapper table is > changed in a SUSPEND/LOAD/RESUME cycle. Such operations can change the > content of the device, thus I assume that the diskseq should also > change. But AFAICS this wasn't part of your patch set. > > In general, whether the content changes in a reload operation depends > on the target. The multipath target, for example, reloads frequently > without changing the content of the dm device. An ever-changing diskseq > wouldn't make a lot of sense for dm-multipath. But I doubt we want to > start making distinctions on this level, so I guess that diskseq and > multipath just won't go well together. Should this be controlled by userspace?
On Mon, 2024-01-15 at 16:44 -0500, Demi Marie Obenour wrote: > On Mon, Jan 15, 2024 at 06:56:16PM +0100, Martin Wilck wrote: > > On Sat, 2023-06-24 at 19:09 -0400, Demi Marie Obenour wrote: > > > This work aims to allow userspace to create and destroy device- > > > mapper > > > devices in a race-free way. > > > > The discussion about this feature seems to have stalled ... will > > there > > be a v3 of this series any time soon? > > I’m still interested in a v3, but it might take a while. If you are > willing and able to do it first, I recommend that you do so. No, I was just trying to understand the status. > > > Also, I am wondering what should happen if a device-mapper table is > > changed in a SUSPEND/LOAD/RESUME cycle. Such operations can change > > the > > content of the device, thus I assume that the diskseq should also > > change. But AFAICS this wasn't part of your patch set. > > > > In general, whether the content changes in a reload operation > > depends > > on the target. The multipath target, for example, reloads > > frequently > > without changing the content of the dm device. An ever-changing > > diskseq > > wouldn't make a lot of sense for dm-multipath. But I doubt we want > > to > > start making distinctions on this level, so I guess that diskseq > > and > > multipath just won't go well together. > > Should this be controlled by userspace? Personally, I don't think so, but I guess this deserves a broader discussion. IMO users who want to benefit from the diskseq feature would not want to be surprised by device-mapper devices changing under them, and would also not want to have some block devices with diskseq semantics and others without. Therefore I believe that it's sufficient to be able to have some global switch to enable or disable the use of diskseq. But I've only learned about this feature pretty recently, so I may easily be misunderstanding something. Martin