[PATCH 2/2] dm-crypt: enable DM_TARGET_ATOMIC_WRITES

[PATCH 2/2] dm-crypt: enable DM_TARGET_ATOMIC_WRITES

[Mikulas Patocka]

Allow handling of bios with REQ_ATOMIC flag set.

Don't split these bios and fail them if they overrun the hard limit
"BIO_MAX_VECS << PAGE_SHIFT".

This commit joins the logic that avoids splitting emulated zone append
bios with atomic write bios.

Signed-off-by: John Garry <john.g.garry@oracle.com>
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>

---
 drivers/md/dm-crypt.c |   39 ++++++++++++++++++++++++---------------
 1 file changed, 24 insertions(+), 15 deletions(-)

Index: linux-2.6/drivers/md/dm-crypt.c
===================================================================
--- linux-2.6.orig/drivers/md/dm-crypt.c	2025-11-05 14:50:28.000000000 +0100
+++ linux-2.6/drivers/md/dm-crypt.c	2025-11-05 14:50:28.000000000 +0100
@@ -254,22 +254,15 @@ static unsigned int max_write_size = 0;
 module_param(max_write_size, uint, 0644);
 MODULE_PARM_DESC(max_write_size, "Maximum size of a write request");
 
-static unsigned get_max_request_sectors(struct dm_target *ti, struct bio *bio)
+static unsigned get_max_request_sectors(struct dm_target *ti, struct bio *bio, bool no_split)
 {
 	struct crypt_config *cc = ti->private;
 	unsigned val, sector_align;
 	bool wrt = op_is_write(bio_op(bio));
 
-	if (wrt) {
-		/*
-		 * For zoned devices, splitting write operations creates the
-		 * risk of deadlocking queue freeze operations with zone write
-		 * plugging BIO work when the reminder of a split BIO is
-		 * issued. So always allow the entire BIO to proceed.
-		 */
-		if (ti->emulate_zone_append)
-			return bio_sectors(bio);
-
+	if (no_split) {
+		val = -1;
+	} else if (wrt) {
 		val = min_not_zero(READ_ONCE(max_write_size),
 				   DM_CRYPT_DEFAULT_MAX_WRITE_SIZE);
 	} else {
@@ -3496,6 +3489,7 @@ static int crypt_map(struct dm_target *t
 	struct dm_crypt_io *io;
 	struct crypt_config *cc = ti->private;
 	unsigned max_sectors;
+	bool no_split;
 
 	/*
 	 * If bio is REQ_PREFLUSH or REQ_OP_DISCARD, just bypass crypt queues.
@@ -3513,10 +3507,20 @@ static int crypt_map(struct dm_target *t
 
 	/*
 	 * Check if bio is too large, split as needed.
-	 */
-	max_sectors = get_max_request_sectors(ti, bio);
-	if (unlikely(bio_sectors(bio) > max_sectors))
+	 *
+	 * For zoned devices, splitting write operations creates the
+	 * risk of deadlocking queue freeze operations with zone write
+	 * plugging BIO work when the reminder of a split BIO is
+	 * issued. So always allow the entire BIO to proceed.
+	 */
+	no_split = (ti->emulate_zone_append && op_is_write(bio_op(bio))) ||
+		   (bio->bi_opf & REQ_ATOMIC);
+	max_sectors = get_max_request_sectors(ti, bio, no_split);
+	if (unlikely(bio_sectors(bio) > max_sectors)) {
+		if (unlikely(no_split))
+			return DM_MAPIO_KILL;
 		dm_accept_partial_bio(bio, max_sectors);
+	}
 
 	/*
 	 * Ensure that bio is a multiple of internal sector encryption size
@@ -3762,6 +3766,11 @@ static void crypt_io_hints(struct dm_tar
 	if (ti->emulate_zone_append)
 		limits->max_hw_sectors = min(limits->max_hw_sectors,
 					     BIO_MAX_VECS << PAGE_SECTORS_SHIFT);
+
+	limits->atomic_write_hw_unit_max = min(limits->atomic_write_hw_unit_max,
+					       BIO_MAX_VECS << PAGE_SHIFT);
+	limits->atomic_write_hw_max = min(limits->atomic_write_hw_max,
+					  BIO_MAX_VECS << PAGE_SHIFT);
 }
 
 static struct target_type crypt_target = {
@@ -3770,7 +3779,7 @@ static struct target_type crypt_target =
 	.module = THIS_MODULE,
 	.ctr    = crypt_ctr,
 	.dtr    = crypt_dtr,
-	.features = DM_TARGET_ZONED_HM,
+	.features = DM_TARGET_ZONED_HM | DM_TARGET_ATOMIC_WRITES,
 	.report_zones = crypt_report_zones,
 	.map    = crypt_map,
 	.status = crypt_status,

Re: [PATCH 2/2] dm-crypt: enable DM_TARGET_ATOMIC_WRITES

[Benjamin Marzinski]

On Wed, Nov 05, 2025 at 04:02:36PM +0100, Mikulas Patocka wrote:
> Allow handling of bios with REQ_ATOMIC flag set.
> 
> Don't split these bios and fail them if they overrun the hard limit
> "BIO_MAX_VECS << PAGE_SHIFT".
> 
> This commit joins the logic that avoids splitting emulated zone append
> bios with atomic write bios.
> 
> Signed-off-by: John Garry <john.g.garry@oracle.com>
> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
> 
> ---
>  drivers/md/dm-crypt.c |   39 ++++++++++++++++++++++++---------------
>  1 file changed, 24 insertions(+), 15 deletions(-)
> 
> Index: linux-2.6/drivers/md/dm-crypt.c
> ===================================================================
> --- linux-2.6.orig/drivers/md/dm-crypt.c	2025-11-05 14:50:28.000000000 +0100
> +++ linux-2.6/drivers/md/dm-crypt.c	2025-11-05 14:50:28.000000000 +0100
> @@ -254,22 +254,15 @@ static unsigned int max_write_size = 0;
>  module_param(max_write_size, uint, 0644);
>  MODULE_PARM_DESC(max_write_size, "Maximum size of a write request");
>  
> -static unsigned get_max_request_sectors(struct dm_target *ti, struct bio *bio)
> +static unsigned get_max_request_sectors(struct dm_target *ti, struct bio *bio, bool no_split)
>  {
>  	struct crypt_config *cc = ti->private;
>  	unsigned val, sector_align;
>  	bool wrt = op_is_write(bio_op(bio));
>  
> -	if (wrt) {
> -		/*
> -		 * For zoned devices, splitting write operations creates the
> -		 * risk of deadlocking queue freeze operations with zone write
> -		 * plugging BIO work when the reminder of a split BIO is
> -		 * issued. So always allow the entire BIO to proceed.
> -		 */
> -		if (ti->emulate_zone_append)
> -			return bio_sectors(bio);
> -
> +	if (no_split) {
> +		val = -1;
> +	} else if (wrt) {
>  		val = min_not_zero(READ_ONCE(max_write_size),
>  				   DM_CRYPT_DEFAULT_MAX_WRITE_SIZE);
>  	} else {
> @@ -3496,6 +3489,7 @@ static int crypt_map(struct dm_target *t
>  	struct dm_crypt_io *io;
>  	struct crypt_config *cc = ti->private;
>  	unsigned max_sectors;
> +	bool no_split;
>  
>  	/*
>  	 * If bio is REQ_PREFLUSH or REQ_OP_DISCARD, just bypass crypt queues.
> @@ -3513,10 +3507,20 @@ static int crypt_map(struct dm_target *t
>  
>  	/*
>  	 * Check if bio is too large, split as needed.
> -	 */
> -	max_sectors = get_max_request_sectors(ti, bio);
> -	if (unlikely(bio_sectors(bio) > max_sectors))
> +	 *
> +	 * For zoned devices, splitting write operations creates the
> +	 * risk of deadlocking queue freeze operations with zone write
> +	 * plugging BIO work when the reminder of a split BIO is
> +	 * issued. So always allow the entire BIO to proceed.
> +	 */
> +	no_split = (ti->emulate_zone_append && op_is_write(bio_op(bio))) ||
> +		   (bio->bi_opf & REQ_ATOMIC);
> +	max_sectors = get_max_request_sectors(ti, bio, no_split);
> +	if (unlikely(bio_sectors(bio) > max_sectors)) {
> +		if (unlikely(no_split))
> +			return DM_MAPIO_KILL;
>  		dm_accept_partial_bio(bio, max_sectors);
> +	}
>  
>  	/*
>  	 * Ensure that bio is a multiple of internal sector encryption size
> @@ -3762,6 +3766,11 @@ static void crypt_io_hints(struct dm_tar
>  	if (ti->emulate_zone_append)
>  		limits->max_hw_sectors = min(limits->max_hw_sectors,
>  					     BIO_MAX_VECS << PAGE_SECTORS_SHIFT);
> +
> +	limits->atomic_write_hw_unit_max = min(limits->atomic_write_hw_unit_max,
> +					       BIO_MAX_VECS << PAGE_SHIFT);
> +	limits->atomic_write_hw_max = min(limits->atomic_write_hw_max,
> +					  BIO_MAX_VECS << PAGE_SHIFT);
>  }

Do we need to cap these limits, instead of just accepting the underlying
device limits? Neither of them are really used for IO.
atomic_write_unit_max, which is used for IO, will already get a capped
value from atomic_write_hw_unit_max in
blk_atomic_writes_update_limits(). And capping atomic_write_hw_max seems
wrong, since atomic_write_hw_max == UINT_MAX is used
blk_validate_atomic_write_limits() to indicate that atomic writes were
never set up, because no underlying device supported them. I don't think
these caps will actually break things, but in my mind they make some
already confusing limits even more confusing. 

Or am I missing some reason why this is needed?

-Ben

>  
>  static struct target_type crypt_target = {
> @@ -3770,7 +3779,7 @@ static struct target_type crypt_target =
>  	.module = THIS_MODULE,
>  	.ctr    = crypt_ctr,
>  	.dtr    = crypt_dtr,
> -	.features = DM_TARGET_ZONED_HM,
> +	.features = DM_TARGET_ZONED_HM | DM_TARGET_ATOMIC_WRITES,
>  	.report_zones = crypt_report_zones,
>  	.map    = crypt_map,
>  	.status = crypt_status,
> 

Re: [PATCH 2/2] dm-crypt: enable DM_TARGET_ATOMIC_WRITES

[John Garry]

On 06/11/2025 02:04, Benjamin Marzinski wrote:
>> }
>>   
>>   	/*
>>   	 * Ensure that bio is a multiple of internal sector encryption size
>> @@ -3762,6 +3766,11 @@ static void crypt_io_hints(struct dm_tar
>>   	if (ti->emulate_zone_append)
>>   		limits->max_hw_sectors = min(limits->max_hw_sectors,
>>   					     BIO_MAX_VECS << PAGE_SECTORS_SHIFT);
>> +
>> +	limits->atomic_write_hw_unit_max = min(limits->atomic_write_hw_unit_max,
>> +					       BIO_MAX_VECS << PAGE_SHIFT);
>> +	limits->atomic_write_hw_max = min(limits->atomic_write_hw_max,
>> +					  BIO_MAX_VECS << PAGE_SHIFT);
>>   }
> Do we need to cap these limits, instead of just accepting the underlying
> device limits?

I was going to mention that I don't think that this is required.

> Neither of them are really used for IO.
> atomic_write_unit_max, which is used for IO, will already get a capped
> value from atomic_write_hw_unit_max in
> blk_atomic_writes_update_limits().

Yes, we limit the software atomic writes limits by what the block stack 
can actually handle for never requiring to split a bio with REQ_ATOMIC 
flag set. The HW limits are just what the HW can support.

> And capping atomic_write_hw_max seems
> wrong, since atomic_write_hw_max == UINT_MAX is used
> blk_validate_atomic_write_limits() to indicate that atomic writes were
> never set up, because no underlying device supported them.

That UINT_MAX is used as a flag to indicate that we have not started to 
stack limits for bottom devices yet, and so we just report 0 for the 
atomic limits (when set). I actually don't think that this check is 
strictly required in blk_validate_atomic_write_limits(), as we don't try 
to validate those the limits before stacking the bottom devices. I did 
hit it previously - I need to check on that.

> I don't think
> these caps will actually break things, but in my mind they make some
> already confusing limits even more confusing.
> 
> Or am I missing some reason why this is needed?

Thanks,
John

Re: [PATCH 2/2] dm-crypt: enable DM_TARGET_ATOMIC_WRITES

[Mikulas Patocka]

On Wed, 5 Nov 2025, Benjamin Marzinski wrote:

> > @@ -3762,6 +3766,11 @@ static void crypt_io_hints(struct dm_tar
> >  	if (ti->emulate_zone_append)
> >  		limits->max_hw_sectors = min(limits->max_hw_sectors,
> >  					     BIO_MAX_VECS << PAGE_SECTORS_SHIFT);
> > +
> > +	limits->atomic_write_hw_unit_max = min(limits->atomic_write_hw_unit_max,
> > +					       BIO_MAX_VECS << PAGE_SHIFT);
> > +	limits->atomic_write_hw_max = min(limits->atomic_write_hw_max,
> > +					  BIO_MAX_VECS << PAGE_SHIFT);
> >  }
> 
> Do we need to cap these limits, instead of just accepting the underlying
> device limits?

BIO_MAX_VECS << PAGE_SHIFT is the hard limit for the size of any write 
(atomic or non-atomic) in dm-crypt. dm-crypt cannot support larger writes 
by design.

If non-atomic write is larger than BIO_MAX_VECS << PAGE_SHIFT, dm-crypt 
splits it using dm_accept_partial_bio. But atomic writes cannot be split, 
so we need to inform the upper layer to not sent larger bios.

> Neither of them are really used for IO.
> atomic_write_unit_max, which is used for IO, will already get a capped
> value from atomic_write_hw_unit_max in
> blk_atomic_writes_update_limits(). And capping atomic_write_hw_max seems
> wrong, since atomic_write_hw_max == UINT_MAX is used
> blk_validate_atomic_write_limits() to indicate that atomic writes were
> never set up, because no underlying device supported them. I don't think
> these caps will actually break things, but in my mind they make some
> already confusing limits even more confusing. 
> 
> Or am I missing some reason why this is needed?
> 
> -Ben

How do you think we should modify the limits, to make sure that atomic 
write size is capped at BIO_MAX_VECS << PAGE_SHIFT?

Mikulas

Re: [PATCH 2/2] dm-crypt: enable DM_TARGET_ATOMIC_WRITES

[John Garry]

On 06/11/2025 12:06, Mikulas Patocka wrote:
>> Neither of them are really used for IO.
>> atomic_write_unit_max, which is used for IO, will already get a capped
>> value from atomic_write_hw_unit_max in
>> blk_atomic_writes_update_limits(). And capping atomic_write_hw_max seems
>> wrong, since atomic_write_hw_max == UINT_MAX is used
>> blk_validate_atomic_write_limits() to indicate that atomic writes were
>> never set up, because no underlying device supported them. I don't think
>> these caps will actually break things, but in my mind they make some
>> already confusing limits even more confusing.
>>
>> Or am I missing some reason why this is needed?
>>
>> -Ben
> How do you think we should modify the limits, to make sure that atomic
> write size is capped at BIO_MAX_VECS << PAGE_SHIFT?

The atomic write size is limited elsewhere, specifically 
blk_atomic_writes_update_limits() - the limit there is quite similar (to 
what is added in this updated patch). So I don't think that we need to 
do anything special in dm-crypt, as that block limit is already tighter.

I suppose that this code can be kept with a comment (saying that it is 
unnecessary, but safer to keep). Or we can just drop the code and add a 
comment (saying that we don't need to limit here, as it is done elsewhere).

Thanks,
John

Re: [PATCH 2/2] dm-crypt: enable DM_TARGET_ATOMIC_WRITES

[Mikulas Patocka]

On Thu, 6 Nov 2025, John Garry wrote:

> On 06/11/2025 12:06, Mikulas Patocka wrote:
> > > Neither of them are really used for IO.
> > > atomic_write_unit_max, which is used for IO, will already get a capped
> > > value from atomic_write_hw_unit_max in
> > > blk_atomic_writes_update_limits(). And capping atomic_write_hw_max seems
> > > wrong, since atomic_write_hw_max == UINT_MAX is used
> > > blk_validate_atomic_write_limits() to indicate that atomic writes were
> > > never set up, because no underlying device supported them. I don't think
> > > these caps will actually break things, but in my mind they make some
> > > already confusing limits even more confusing.
> > > 
> > > Or am I missing some reason why this is needed?
> > > 
> > > -Ben
> > How do you think we should modify the limits, to make sure that atomic
> > write size is capped at BIO_MAX_VECS << PAGE_SHIFT?
> 
> The atomic write size is limited elsewhere, specifically
> blk_atomic_writes_update_limits() - the limit there is quite similar (to what
> is added in this updated patch). So I don't think that we need to do anything
> special in dm-crypt, as that block limit is already tighter.
> 
> I suppose that this code can be kept with a comment (saying that it is
> unnecessary, but safer to keep). Or we can just drop the code and add a
> comment (saying that we don't need to limit here, as it is done elsewhere).
> 
> Thanks,
> John

What if someone creates a hypothetical device that supports atomic writes 
larger than BIO_MAX_VECS << PAGE_SHIFT? I think, we should limit it.

Mikulas

Re: [PATCH 2/2] dm-crypt: enable DM_TARGET_ATOMIC_WRITES

[John Garry]

On 06/11/2025 14:00, Mikulas Patocka wrote:
>> The atomic write size is limited elsewhere, specifically
>> blk_atomic_writes_update_limits() - the limit there is quite similar (to what
>> is added in this updated patch). So I don't think that we need to do anything
>> special in dm-crypt, as that block limit is already tighter.
>>
>> I suppose that this code can be kept with a comment (saying that it is
>> unnecessary, but safer to keep). Or we can just drop the code and add a
>> comment (saying that we don't need to limit here, as it is done elsewhere).
>>
>> Thanks,
>> John
> What if someone creates a hypothetical device that supports atomic writes
> larger than BIO_MAX_VECS << PAGE_SHIFT? I think, we should limit it.

Yeah, it's entirely possible. And this is why we have separate HW and SW 
atomic write limits. The HW limits are just what the HW can support, and 
has no theoretical limit (apart from what we can fit in the 
request_queue limits values). But the SW limits are a combination of the 
HW limits and what the block stack can support (when guaranteeing to 
never split a bio). The SW upper limit is about ~500KB for 4K PAGE_SIZE 
- it can be less if the bdev has a limited segment count max. The SW 
limits are what we report to userspace in terms of the maximum atomic 
write size; in addition, it is the SW limits which the block stack 
checks for when submitting a bio.

So you could cap the HW limits to BIO_MAX_VECS << PAGE_SHIFT, but it 
would not have any effect in practice.

Thanks,
John

Re: [PATCH 2/2] dm-crypt: enable DM_TARGET_ATOMIC_WRITES

[John Garry]

On 05/11/2025 15:02, Mikulas Patocka wrote:
> Allow handling of bios with REQ_ATOMIC flag set.
> 
> Don't split these bios and fail them if they overrun the hard limit
> "BIO_MAX_VECS << PAGE_SHIFT".
> 
> This commit joins the logic that avoids splitting emulated zone append
> bios with atomic write bios.
> 
> Signed-off-by: John Garry <john.g.garry@oracle.com>
> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
> 

Tested-by: John Garry <john.g.garry@oracle.com>

fwiw, I still don't think that we require the change in crypt_io_hints() 
[not shown], but it should not make a difference.

Thanks!

Re: [PATCH 2/2] dm-crypt: enable DM_TARGET_ATOMIC_WRITES

[John Garry]

On 10/11/2025 16:02, John Garry wrote:

Hi Mikulas,

Just a friendly reminder on this series. Let me know if you require 
anything else.

Cheers

> On 05/11/2025 15:02, Mikulas Patocka wrote:
>> Allow handling of bios with REQ_ATOMIC flag set.
>>
>> Don't split these bios and fail them if they overrun the hard limit
>> "BIO_MAX_VECS << PAGE_SHIFT".
>>
>> This commit joins the logic that avoids splitting emulated zone append
>> bios with atomic write bios.
>>
>> Signed-off-by: John Garry <john.g.garry@oracle.com>
>> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
>>
> 
> Tested-by: John Garry <john.g.garry@oracle.com>
> 
> fwiw, I still don't think that we require the change in crypt_io_hints() 
> [not shown], but it should not make a difference.
> 
> Thanks!
> 

Re: [PATCH 2/2] dm-crypt: enable DM_TARGET_ATOMIC_WRITES

[Mikulas Patocka]

On Tue, 18 Nov 2025, John Garry wrote:

> On 10/11/2025 16:02, John Garry wrote:
> 
> Hi Mikulas,
> 
> Just a friendly reminder on this series. Let me know if you require anything
> else.
> 
> Cheers

Hi

In crypt_io_hints - should I set "limits->atomic_write_hw_max", 
"limits->atomic_write_hw_unit_max" or both?

I think that we haven't settled about that when we talked about it.

Mikulas

> > On 05/11/2025 15:02, Mikulas Patocka wrote:
> > > Allow handling of bios with REQ_ATOMIC flag set.
> > > 
> > > Don't split these bios and fail them if they overrun the hard limit
> > > "BIO_MAX_VECS << PAGE_SHIFT".
> > > 
> > > This commit joins the logic that avoids splitting emulated zone append
> > > bios with atomic write bios.
> > > 
> > > Signed-off-by: John Garry <john.g.garry@oracle.com>
> > > Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
> > > 
> > 
> > Tested-by: John Garry <john.g.garry@oracle.com>
> > 
> > fwiw, I still don't think that we require the change in crypt_io_hints()
> > [not shown], but it should not make a difference.
> > 
> > Thanks!
> > 
> 

Re: [PATCH 2/2] dm-crypt: enable DM_TARGET_ATOMIC_WRITES

[John Garry]

On 18/11/2025 17:09, Mikulas Patocka wrote:
> In crypt_io_hints - should I set "limits->atomic_write_hw_max",
> "limits->atomic_write_hw_unit_max" or both?
> 
> I think that we haven't settled about that when we talked about it.

If you are going to set one then set both of them.

I already tested this, so it's fine.

Thanks,
John

Re: [PATCH 2/2] dm-crypt: enable DM_TARGET_ATOMIC_WRITES

[Mikulas Patocka]

On Tue, 18 Nov 2025, John Garry wrote:

> On 18/11/2025 17:09, Mikulas Patocka wrote:
> > In crypt_io_hints - should I set "limits->atomic_write_hw_max",
> > "limits->atomic_write_hw_unit_max" or both?
> > 
> > I think that we haven't settled about that when we talked about it.
> 
> If you are going to set one then set both of them.
> 
> I already tested this, so it's fine.
> 
> Thanks,
> John

Hi

I committed those two patches - you can have look at linux-dm.git, branch 
for-next.

Mikulas

[PATCH 0/2] dm-crypt atomic writes support

[John Garry]

This small series enables atomic writes support for dm-crypt.

Apart from setting DM_TARGET_ATOMIC_WRITES flag, we need to make the
following changes:
- limit atomic write size to dm-crypt max write size
- BUG_ON() any partial completions for when REQ_ATOMIC is set

John Garry (2):
  dm: BUG on REQ_ATOMIC in dm_accept_partial_bio()
  dm-crypt: enable DM_TARGET_ATOMIC_WRITES

 drivers/md/dm-crypt.c | 21 +++++++++++++++++++--
 drivers/md/dm.c       |  5 +++--
 2 files changed, 22 insertions(+), 4 deletions(-)

-- 
2.43.5

[PATCH 2/2] dm-crypt: enable DM_TARGET_ATOMIC_WRITES

[John Garry]

Allow handling of bios with REQ_ATOMIC flag set.

In crypt_io_hints(), the max atomic write sizes needs to be limited
according to the max of DM_CRYPT_DEFAULT_MAX_WRITE_SIZE and max_write_size.
Otherwise, we may need to split bios in crypt_map() ->
dm_accept_partial_bio().

Signed-off-by: John Garry <john.g.garry@oracle.com>
---
 drivers/md/dm-crypt.c | 21 +++++++++++++++++++--
 1 file changed, 19 insertions(+), 2 deletions(-)

diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c
index 5ef43231fe77f..c4c97f57bc477 100644
--- a/drivers/md/dm-crypt.c
+++ b/drivers/md/dm-crypt.c
@@ -3515,8 +3515,11 @@ static int crypt_map(struct dm_target *ti, struct bio *bio)
 	 * Check if bio is too large, split as needed.
 	 */
 	max_sectors = get_max_request_sectors(ti, bio);
-	if (unlikely(bio_sectors(bio) > max_sectors))
+	if (unlikely(bio_sectors(bio) > max_sectors)) {
+		if (bio->bi_opf & REQ_ATOMIC)
+			return DM_MAPIO_KILL;
 		dm_accept_partial_bio(bio, max_sectors);
+	}
 
 	/*
 	 * Ensure that bio is a multiple of internal sector encryption size
@@ -3744,6 +3747,8 @@ static int crypt_iterate_devices(struct dm_target *ti,
 static void crypt_io_hints(struct dm_target *ti, struct queue_limits *limits)
 {
 	struct crypt_config *cc = ti->private;
+	unsigned int _max_write_size =
+		min_not_zero(max_write_size, DM_CRYPT_DEFAULT_MAX_WRITE_SIZE);
 
 	limits->logical_block_size =
 		max_t(unsigned int, limits->logical_block_size, cc->sector_size);
@@ -3762,6 +3767,18 @@ static void crypt_io_hints(struct dm_target *ti, struct queue_limits *limits)
 	if (ti->emulate_zone_append)
 		limits->max_hw_sectors = min(limits->max_hw_sectors,
 					     BIO_MAX_VECS << PAGE_SECTORS_SHIFT);
+
+	if (_max_write_size < limits->atomic_write_hw_unit_min) {
+		limits->atomic_write_hw_unit_min = 0;
+		limits->atomic_write_hw_unit_max = 0;
+		limits->atomic_write_hw_max = 0;
+		limits->atomic_write_hw_boundary = 0;
+	} else {
+		limits->atomic_write_hw_unit_max =
+			min(limits->atomic_write_hw_unit_max, _max_write_size);
+		limits->atomic_write_hw_max =
+			min(limits->atomic_write_hw_max, _max_write_size);
+	}
 }
 
 static struct target_type crypt_target = {
@@ -3770,7 +3787,7 @@ static struct target_type crypt_target = {
 	.module = THIS_MODULE,
 	.ctr    = crypt_ctr,
 	.dtr    = crypt_dtr,
-	.features = DM_TARGET_ZONED_HM,
+	.features = DM_TARGET_ZONED_HM | DM_TARGET_ATOMIC_WRITES,
 	.report_zones = crypt_report_zones,
 	.map    = crypt_map,
 	.status = crypt_status,
-- 
2.43.5