[prev in list] [next in list] [prev in thread] [next in thread] 

List:       dm-crypt
Subject:    [dm-crypt] Re: --disable-locks
From:       Milan Broz <gmazyland () gmail ! com>
Date:       2021-09-24 17:33:28
Message-ID: 18f4e75c-6ed1-8c03-6d41-b05b20a0661a () gmail ! com
[Download RAW message or body]

On 23/09/2021 15:01, Jeremiah Moree wrote:
> While searching through the source code I came upon docs/LUKS-locking.txt.  
> 
> From previous discussions on this list I understood the locking to be only for \
> protection against concurrent user access.  This is how I wrote the FAQ entry that \
> is now in the docs.

It protects LUKS2 metadata (serializes access to metadata update so concurrent \
processes cannot see partially updated metadata).

That said, in some situations activation of data device can rely on reliable metadata \
update. For example, during reencryption, LUKS2 metadata is continuously updated when \
moving reencrypted area.

If you disable locking here, it will (almost for sure) corrupt the data (not only \
metadata).

> From this new-to-me doc it seems that locking is to also prevent header corruption. \
> I am surprised no one pointed this out in discussions so there is a chance I may be \
> misunderstanding.

Interesting, I thought that we are primarily talking about metadata :)
 
> Specifically, this was in a discussion about --disable-locks.  Am I correct in \
> stating: 
> Using --disable-locks I risk
> * concurrent user access problems
> *  header corruption

See above.

For the simple situation we do not need locks to activate device and prevent \
concurrent accerss (kernel dm-crypt/device-mapper has internal locking that allows \
only one device activation in-kernel).

But LUKS2 device can be more complex stacks of devices (a reencryption in-progress is \
a nice example) where the LUKS2 locking plays its role.

Milan
_______________________________________________
dm-crypt mailing list -- dm-crypt@saout.de
To unsubscribe send an email to dm-crypt-leave@saout.de


[prev in list] [next in list] [prev in thread] [next in thread]