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] [thread-next>] [day] [month] [year] [list]
Message-ID: <6a6f8cff-bd19-4079-8867-4ac17d09e915@oracle.com>
Date: Thu, 16 Jan 2025 11:28:08 +0000
From: John Garry <john.g.garry@...cle.com>
To: Mikulas Patocka <mpatocka@...hat.com>
Cc: Mike Snitzer <snitzer@...merspace.com>, axboe@...nel.dk, agk@...hat.com,
        hch@....de, martin.petersen@...cle.com, linux-block@...r.kernel.org,
        dm-devel@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC 0/5] device mapper atomic write support

On 07/01/2025 17:13, Mikulas Patocka wrote:
> 
> 
> On Mon, 6 Jan 2025, John Garry wrote:
> 
>> On 06/01/2025 17:26, Mike Snitzer wrote:
>>> On Mon, Jan 06, 2025 at 12:41:14PM +0000, John Garry wrote:
>>>> This series introduces initial device mapper atomic write support.
>>>>
>>>> Since we already support stacking atomic writes limits, it's quite
>>>> straightforward to support.
>>>>
>>>> Only dm-linear is supported for now, but other personalities could
>>>> be supported.
>>>>
>>>> Patch #1 is a proper fix, but the rest of the series is RFC - this is
>>>> because I have not fully tested and we are close to the end of this
>>>> development cycle.
>>> In general, looks reasonable.  But I would prefer to see atomic write
>>> support added to dm-striped as well.  Not that I have some need, but
>>> because it will help verify the correctness of the general stacking
>>> code changes (in both block and DM core).
>>
>> That should be fine. We already have md raid0 support working (for atomic
>> writes), so I would expect much of the required support is already available.
> 
> BTW. could it be possible to add dm-mirror support as well? dm-mirror is
> used when the user moves the logical volume to another physical volume, so
> it would be nice if this worked without resulting in not-supported errors.
> 
> dm-mirror uses dm-io to perform the writes on multiple mirror legs (see
> the function do_write() -> dm_io()), I looked at the code and it seems
> that the support for atomic writes in dm-mirror and dm-io would be
> straightforward.

I tried this out, and it seems to work ok.

However, I need to set DM_TARGET_ATOMIC_WRITES in the 
mirror_target.features member, like:

diff --git a/drivers/md/dm-raid1.c b/drivers/md/dm-raid1.c
index 9511dae5b556..913a92c55904 100644
--- a/drivers/md/dm-raid1.c
+++ b/drivers/md/dm-raid1.c
@@ -1485,6 +1485,7 @@ static struct target_type mirror_target = {
	.name    = "mirror",
	.version = {1, 14, 0},
	.module  = THIS_MODULE,
+	.features = DM_TARGET_ATOMIC_WRITES,
	.ctr     = mirror_ctr,
	.dtr     = mirror_dtr,
	.map     = mirror_map,


Is this the right thing to do? I ask, as none of the other DM_TARGET* 
flags are set already, which makes me suspicious.

Thanks,
John


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ