linux-kernel - Re: [dm-devel] [PATCH v2 0/4] Diskseq support in device-mapper

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <ff539e4aed4c586d91a2f1ba62658f81203119de.camel@suse.com>
Date: Tue, 16 Jan 2024 09:00:48 +0100
From: Martin Wilck <mwilck@...e.com>
To: Demi Marie Obenour <demi@...isiblethingslab.com>, Alasdair Kergon
 <agk@...hat.com>, Mike Snitzer <snitzer@...nel.org>,
 dm-devel@...ts.linux.dev,  Christoph Hellwig <hch@...radead.org>
Cc: linux-kernel@...r.kernel.org, linux-block@...r.kernel.org, Franck Bui
	 <fbui@...e.com>
Subject: Re: [dm-devel] [PATCH v2 0/4] Diskseq support in device-mapper

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