As recently raised on the mailing list, it may be useful to propose a
list of steps to go through in order to proove the devices have been
described correctly, especially since all the block protection
information is not stored in any kind of table and is instead filled
manually by developpers.
Use the debugfs output to ease the comparison between expectations and
reality.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
Documentation/driver-api/mtd/spi-nor.rst | 118 +++++++++++++++++++++++++++++++
1 file changed, 118 insertions(+)
diff --git a/Documentation/driver-api/mtd/spi-nor.rst b/Documentation/driver-api/mtd/spi-nor.rst
index 148fa4288760b6ba47d530ed72c5ef81397d598f..d56ff5c42a98af23a65097c9b77cd20ef2504a49 100644
--- a/Documentation/driver-api/mtd/spi-nor.rst
+++ b/Documentation/driver-api/mtd/spi-nor.rst
@@ -203,3 +203,121 @@ section, after the ``---`` marker.
mtd.writesize = 1
mtd.oobsize = 0
regions = 0
+
+5) If your flash supports locking, also follow the following test
+ procedure to make sure it correctly behaves. These tests must be
+ conducted with #WP high (no hardware protection) or the `no-wp`
+ property in the DT node.
+
+ Test full chip locking and make sure expectations, the MEMISLOCKED
+ ioctl output, the debugfs output and experimental results are all
+ aligned::
+
+ root@1:~# alias show_sectors='grep -A4 "locked sectors" /sys/kernel/debug/spi-nor/spi0.0/params'
+ root@1:~# flash_lock -u /dev/mtd0
+ root@1:~# flash_lock -i /dev/mtd0
+ Device: /dev/mtd0
+ Start: 0
+ Len: 0x4000000
+ Lock status: unlocked
+ Return code: 0
+ root@1:~# mtd_debug erase /dev/mtd0 0 2097152
+ Erased 2097152 bytes from address 0x00000000 in flash
+ root@1:~# mtd_debug write /dev/mtd0 0 2097152 spi_test
+ Copied 2097152 bytes from spi_test to address 0x00000000 in flash
+ root@1:~# mtd_debug read /dev/mtd0 0 2097152 spi_read
+ Copied 2097152 bytes from address 0x00000000 in flash to spi_read
+ root@1:~# sha256sum spi*
+ c444216a6ba2a4a66cccd60a0dd062bce4b865dd52b200ef5e21838c4b899ac8 spi_read
+ c444216a6ba2a4a66cccd60a0dd062bce4b865dd52b200ef5e21838c4b899ac8 spi_test
+ root@1:~# show_sectors
+ software locked sectors
+ region (in hex) | status | #blocks
+ ------------------+----------+--------
+ 00000000-03ffffff | unlocked | 1024
+
+ root@1:~# flash_lock -l /dev/mtd0
+ root@1:~# flash_lock -i /dev/mtd0
+ Device: /dev/mtd0
+ Start: 0
+ Len: 0x4000000
+ Lock status: locked
+ Return code: 1
+ root@1:~# mtd_debug erase /dev/mtd0 0 2097152
+ Erased 2097152 bytes from address 0x00000000 in flash
+ root@1:~# mtd_debug read /dev/mtd0 0 2097152 spi_read
+ Copied 2097152 bytes from address 0x00000000 in flash to spi_read
+ root@1:~# sha256sum spi*
+ c444216a6ba2a4a66cccd60a0dd062bce4b865dd52b200ef5e21838c4b899ac8 spi_read
+ c444216a6ba2a4a66cccd60a0dd062bce4b865dd52b200ef5e21838c4b899ac8 spi_test
+ root@1:~# dd if=/dev/urandom of=./spi_test2 bs=1M count=2
+ 2+0 records in
+ 2+0 records out
+ root@1:~# mtd_debug write /dev/mtd0 0 2097152 spi_test2
+ Copied 2097152 bytes from spi_test to address 0x00000000 in flash
+ root@1:~# mtd_debug read /dev/mtd0 0 2097152 spi_read2
+ Copied 2097152 bytes from address 0x00000000 in flash to spi_read
+ root@1:~# sha256sum spi*
+ c444216a6ba2a4a66cccd60a0dd062bce4b865dd52b200ef5e21838c4b899ac8 spi_read
+ c444216a6ba2a4a66cccd60a0dd062bce4b865dd52b200ef5e21838c4b899ac8 spi_read2
+ c444216a6ba2a4a66cccd60a0dd062bce4b865dd52b200ef5e21838c4b899ac8 spi_test
+ bea9334df51c620440f86751cba0799214a016329f1736f9456d40cf40efdc88 spi_test2
+ root@1:~# show_sectors
+ software locked sectors
+ region (in hex) | status | #blocks
+ ------------------+----------+--------
+ 00000000-03ffffff | locked | 1024
+
+ Once we trust the debugfs output we can use it to test various
+ situations. Check top locking/unlocking (end of the device)::
+
+ root@1:~# bs=$(cat /sys/class/mtd/mtd0/erasesize)
+ root@1:~# size=$(cat /sys/class/mtd/mtd0/size)
+
+ root@1:~# flash_lock -u /dev/mtd0
+ root@1:~# flash_lock -l /dev/mtd0 $(($size - (2 * $bs))) 2 # last two
+ root@1:~# show_sectors
+ software locked sectors
+ region (in hex) | status | #blocks
+ ------------------+----------+--------
+ 00000000-03fdffff | unlocked | 1022
+ 03fe0000-03ffffff | locked | 2
+ root@1:~# flash_lock -u /dev/mtd0 $(($size - (2 * $bs))) 1 # last one
+ root@1:~# show_sectors
+ software locked sectors
+ region (in hex) | status | #blocks
+ ------------------+----------+--------
+ 00000000-03feffff | unlocked | 1023
+ 03ff0000-03ffffff | locked | 1
+
+ If the flash features 4 block protection bits (BP), we can protect
+ more than 4MB (typically 128 64kiB-blocks or more), with a finer
+ grain than locking the entire device::
+
+ root@1:~# flash_lock -u /dev/mtd0
+ root@1:~# flash_lock -l /dev/mtd0 $(($size - (2**7 * $bs))) $((2**7))
+ root@1:~# show_sectors
+ software locked sectors
+ region (in hex) | status | #blocks
+ ------------------+----------+--------
+ 00000000-037fffff | unlocked | 896
+ 03800000-03ffffff | locked | 128
+
+ If the flash features a Top/Bottom (TB) bit, we can protect the
+ beginning of the flash::
+
+ root@1:~# flash_lock -u /dev/mtd0
+ root@1:~# flash_lock -l /dev/mtd0 0 2 # first two
+ root@1:~# show_sectors
+ software locked sectors
+ region (in hex) | status | #blocks
+ ------------------+----------+--------
+ 00000000-0001ffff | locked | 2
+ 00020000-03ffffff | unlocked | 1022
+ root@1:~# flash_lock -u /dev/mtd0 $bs 1 # first one
+ root@1:~# show_sectors
+ software locked sectors
+ region (in hex) | status | #blocks
+ ------------------+----------+--------
+ 00000000-0000ffff | locked | 1
+ 00010000-03ffffff | unlocked | 1023
--
2.51.0On Fri Nov 14, 2025 at 6:53 PM CET, Miquel Raynal wrote: > As recently raised on the mailing list, it may be useful to propose a > list of steps to go through in order to proove the devices have been > described correctly, especially since all the block protection > information is not stored in any kind of table and is instead filled > manually by developpers. > > Use the debugfs output to ease the comparison between expectations and > reality. > > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> > --- > Documentation/driver-api/mtd/spi-nor.rst | 118 +++++++++++++++++++++++++++++++ > 1 file changed, 118 insertions(+) > > diff --git a/Documentation/driver-api/mtd/spi-nor.rst b/Documentation/driver-api/mtd/spi-nor.rst > index 148fa4288760b6ba47d530ed72c5ef81397d598f..d56ff5c42a98af23a65097c9b77cd20ef2504a49 100644 > --- a/Documentation/driver-api/mtd/spi-nor.rst > +++ b/Documentation/driver-api/mtd/spi-nor.rst > @@ -203,3 +203,121 @@ section, after the ``---`` marker. > mtd.writesize = 1 > mtd.oobsize = 0 > regions = 0 > + > +5) If your flash supports locking, also follow the following test > + procedure to make sure it correctly behaves. These tests must be > + conducted with #WP high (no hardware protection) or the `no-wp` > + property in the DT node. Or? If WPn is low, the no-wp property doesn't matter. It's hardware write protected. Also there is that corner case, where you can actually fully lock your flash: WPn hard tied to low. Be aware, that you can enable locking even if WPn is tied low. That has the use case to initially program the flash and then lock it forever. So we might add a warning note, that WPn should somehow be controllable (or be sure that is tied high) before conducting the locking tests. > + > + Test full chip locking and make sure expectations, the MEMISLOCKED > + ioctl output, the debugfs output and experimental results are all > + aligned:: > + > + root@1:~# alias show_sectors='grep -A4 "locked sectors" /sys/kernel/debug/spi-nor/spi0.0/params' > + root@1:~# flash_lock -u /dev/mtd0 > + root@1:~# flash_lock -i /dev/mtd0 > + Device: /dev/mtd0 > + Start: 0 > + Len: 0x4000000 > + Lock status: unlocked > + Return code: 0 > + root@1:~# mtd_debug erase /dev/mtd0 0 2097152 > + Erased 2097152 bytes from address 0x00000000 in flash > + root@1:~# mtd_debug write /dev/mtd0 0 2097152 spi_test > + Copied 2097152 bytes from spi_test to address 0x00000000 in flash > + root@1:~# mtd_debug read /dev/mtd0 0 2097152 spi_read > + Copied 2097152 bytes from address 0x00000000 in flash to spi_read > + root@1:~# sha256sum spi* > + c444216a6ba2a4a66cccd60a0dd062bce4b865dd52b200ef5e21838c4b899ac8 spi_read > + c444216a6ba2a4a66cccd60a0dd062bce4b865dd52b200ef5e21838c4b899ac8 spi_test > + root@1:~# show_sectors > + software locked sectors > + region (in hex) | status | #blocks > + ------------------+----------+-------- > + 00000000-03ffffff | unlocked | 1024 > + > + root@1:~# flash_lock -l /dev/mtd0 > + root@1:~# flash_lock -i /dev/mtd0 > + Device: /dev/mtd0 > + Start: 0 > + Len: 0x4000000 > + Lock status: locked > + Return code: 1 > + root@1:~# mtd_debug erase /dev/mtd0 0 2097152 > + Erased 2097152 bytes from address 0x00000000 in flash > + root@1:~# mtd_debug read /dev/mtd0 0 2097152 spi_read > + Copied 2097152 bytes from address 0x00000000 in flash to spi_read > + root@1:~# sha256sum spi* > + c444216a6ba2a4a66cccd60a0dd062bce4b865dd52b200ef5e21838c4b899ac8 spi_read > + c444216a6ba2a4a66cccd60a0dd062bce4b865dd52b200ef5e21838c4b899ac8 spi_test > + root@1:~# dd if=/dev/urandom of=./spi_test2 bs=1M count=2 > + 2+0 records in > + 2+0 records out > + root@1:~# mtd_debug write /dev/mtd0 0 2097152 spi_test2 > + Copied 2097152 bytes from spi_test to address 0x00000000 in flash > + root@1:~# mtd_debug read /dev/mtd0 0 2097152 spi_read2 > + Copied 2097152 bytes from address 0x00000000 in flash to spi_read > + root@1:~# sha256sum spi* > + c444216a6ba2a4a66cccd60a0dd062bce4b865dd52b200ef5e21838c4b899ac8 spi_read > + c444216a6ba2a4a66cccd60a0dd062bce4b865dd52b200ef5e21838c4b899ac8 spi_read2 > + c444216a6ba2a4a66cccd60a0dd062bce4b865dd52b200ef5e21838c4b899ac8 spi_test > + bea9334df51c620440f86751cba0799214a016329f1736f9456d40cf40efdc88 spi_test2 > + root@1:~# show_sectors > + software locked sectors > + region (in hex) | status | #blocks > + ------------------+----------+-------- > + 00000000-03ffffff | locked | 1024 > + > + Once we trust the debugfs output we can use it to test various > + situations. Check top locking/unlocking (end of the device):: > + > + root@1:~# bs=$(cat /sys/class/mtd/mtd0/erasesize) > + root@1:~# size=$(cat /sys/class/mtd/mtd0/size) > + > + root@1:~# flash_lock -u /dev/mtd0 > + root@1:~# flash_lock -l /dev/mtd0 $(($size - (2 * $bs))) 2 # last two > + root@1:~# show_sectors > + software locked sectors > + region (in hex) | status | #blocks > + ------------------+----------+-------- > + 00000000-03fdffff | unlocked | 1022 > + 03fe0000-03ffffff | locked | 2 > + root@1:~# flash_lock -u /dev/mtd0 $(($size - (2 * $bs))) 1 # last one huh? shouldn't that be 1 * $bs? -michael > + root@1:~# show_sectors > + software locked sectors > + region (in hex) | status | #blocks > + ------------------+----------+-------- > + 00000000-03feffff | unlocked | 1023 > + 03ff0000-03ffffff | locked | 1 > + > + If the flash features 4 block protection bits (BP), we can protect > + more than 4MB (typically 128 64kiB-blocks or more), with a finer > + grain than locking the entire device:: > + > + root@1:~# flash_lock -u /dev/mtd0 > + root@1:~# flash_lock -l /dev/mtd0 $(($size - (2**7 * $bs))) $((2**7)) > + root@1:~# show_sectors > + software locked sectors > + region (in hex) | status | #blocks > + ------------------+----------+-------- > + 00000000-037fffff | unlocked | 896 > + 03800000-03ffffff | locked | 128 > + > + If the flash features a Top/Bottom (TB) bit, we can protect the > + beginning of the flash:: > + > + root@1:~# flash_lock -u /dev/mtd0 > + root@1:~# flash_lock -l /dev/mtd0 0 2 # first two > + root@1:~# show_sectors > + software locked sectors > + region (in hex) | status | #blocks > + ------------------+----------+-------- > + 00000000-0001ffff | locked | 2 > + 00020000-03ffffff | unlocked | 1022 > + root@1:~# flash_lock -u /dev/mtd0 $bs 1 # first one > + root@1:~# show_sectors > + software locked sectors > + region (in hex) | status | #blocks > + ------------------+----------+-------- > + 00000000-0000ffff | locked | 1 > + 00010000-03ffffff | unlocked | 1023
On 18/11/2025 at 13:24:02 +01, "Michael Walle" <mwalle@kernel.org> wrote:
> On Fri Nov 14, 2025 at 6:53 PM CET, Miquel Raynal wrote:
>> As recently raised on the mailing list, it may be useful to propose a
>> list of steps to go through in order to proove the devices have been
>> described correctly, especially since all the block protection
>> information is not stored in any kind of table and is instead filled
>> manually by developpers.
>>
>> Use the debugfs output to ease the comparison between expectations and
>> reality.
>>
>> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
>> ---
>> Documentation/driver-api/mtd/spi-nor.rst | 118 +++++++++++++++++++++++++++++++
>> 1 file changed, 118 insertions(+)
>>
>> diff --git a/Documentation/driver-api/mtd/spi-nor.rst b/Documentation/driver-api/mtd/spi-nor.rst
>> index 148fa4288760b6ba47d530ed72c5ef81397d598f..d56ff5c42a98af23a65097c9b77cd20ef2504a49 100644
>> --- a/Documentation/driver-api/mtd/spi-nor.rst
>> +++ b/Documentation/driver-api/mtd/spi-nor.rst
>> @@ -203,3 +203,121 @@ section, after the ``---`` marker.
>> mtd.writesize = 1
>> mtd.oobsize = 0
>> regions = 0
>> +
>> +5) If your flash supports locking, also follow the following test
>> + procedure to make sure it correctly behaves. These tests must be
>> + conducted with #WP high (no hardware protection) or the `no-wp`
>> + property in the DT node.
>
> Or? If WPn is low, the no-wp property doesn't matter.
> It's hardware write protected.
This is only correct if the SRP bit is set. If the SRP bit is unset, #WP
low still has no impact. And this is why setting the no-wp property
matters, because otherwise the SR_SRWD bit gets set at the first locking
command.
I disliked this behaviour as I actually got almost locked with
a non drivable #WP pin and had to play with pinctrl in order to force it
high and allow me to overwrite the SR_SRWD bit back.
> Also there is that corner case, where you can
> actually fully lock your flash: WPn hard tied to low. Be aware, that
> you can enable locking even if WPn is tied low. That has the use
> case to initially program the flash and then lock it forever. So we
> might add a warning note, that WPn should somehow be controllable
> (or be sure that is tied high) before conducting the locking tests.
Yes, that is the situation I met, it is not documented anywhere except
the code.
My intent with this paragraph was to hint people not to conduct these
tests under certain situations, but we can definitely improve that. What
about:
5) If your flash supports locking, please got through the following test
procedure to make sure it correctly behaves.
Warning: These tests may hard lock your device! Make sure:
- The device is not hard locked already (#WP strapped to low and
SR_SRWD bit set)
- If you have a #WP pin, you may want to set `no-wp` in your DT for
the time of the test, to only make use of software protection.
Please amend this text if you still think it is missing his goal.
>> + root@1:~# flash_lock -u /dev/mtd0
>> + root@1:~# flash_lock -l /dev/mtd0 $(($size - (2 * $bs))) 2 # last two
>> + root@1:~# show_sectors
>> + software locked sectors
>> + region (in hex) | status | #blocks
>> + ------------------+----------+--------
>> + 00000000-03fdffff | unlocked | 1022
>> + 03fe0000-03ffffff | locked | 2
>> + root@1:~# flash_lock -u /dev/mtd0 $(($size - (2 * $bs))) 1 # last one
>
> huh? shouldn't that be 1 * $bs?
I don't think so:
- first we lock the last two blocks (offset: size - 2 blocks, length: 2
blocks)
- then we unlock the penultimate block so that only the last block
remains locked (offset: size - 2 blocks, length 1).
I we were doing flash_lock -u <mtd> $(($size - (1 * $bs))) 1, we would
be asking to unlock the very last block and keep only the penultimate
block locked, which would not be supported.
Thanks,
Miquèl
On Wed Nov 19, 2025 at 10:40 AM CET, Miquel Raynal wrote:
> On 18/11/2025 at 13:24:02 +01, "Michael Walle" <mwalle@kernel.org> wrote:
>
>> On Fri Nov 14, 2025 at 6:53 PM CET, Miquel Raynal wrote:
>>> As recently raised on the mailing list, it may be useful to propose a
>>> list of steps to go through in order to proove the devices have been
>>> described correctly, especially since all the block protection
>>> information is not stored in any kind of table and is instead filled
>>> manually by developpers.
>>>
>>> Use the debugfs output to ease the comparison between expectations and
>>> reality.
>>>
>>> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
>>> ---
>>> Documentation/driver-api/mtd/spi-nor.rst | 118 +++++++++++++++++++++++++++++++
>>> 1 file changed, 118 insertions(+)
>>>
>>> diff --git a/Documentation/driver-api/mtd/spi-nor.rst b/Documentation/driver-api/mtd/spi-nor.rst
>>> index 148fa4288760b6ba47d530ed72c5ef81397d598f..d56ff5c42a98af23a65097c9b77cd20ef2504a49 100644
>>> --- a/Documentation/driver-api/mtd/spi-nor.rst
>>> +++ b/Documentation/driver-api/mtd/spi-nor.rst
>>> @@ -203,3 +203,121 @@ section, after the ``---`` marker.
>>> mtd.writesize = 1
>>> mtd.oobsize = 0
>>> regions = 0
>>> +
>>> +5) If your flash supports locking, also follow the following test
>>> + procedure to make sure it correctly behaves. These tests must be
>>> + conducted with #WP high (no hardware protection) or the `no-wp`
>>> + property in the DT node.
>>
>> Or? If WPn is low, the no-wp property doesn't matter.
>> It's hardware write protected.
>
> This is only correct if the SRP bit is set. If the SRP bit is unset, #WP
> low still has no impact. And this is why setting the no-wp property
> matters, because otherwise the SR_SRWD bit gets set at the first locking
> command.
Yes, but only if it's not write-protected before. The text read as
if you could ignore the hardware write protection. More below.
> I disliked this behaviour as I actually got almost locked with
> a non drivable #WP pin and had to play with pinctrl in order to force it
> high and allow me to overwrite the SR_SRWD bit back.
That no-wp property was recently introduced because of faulty
hardware. Before that, locking was always the "real" hardware
write-protection.
>> Also there is that corner case, where you can
>> actually fully lock your flash: WPn hard tied to low. Be aware, that
>> you can enable locking even if WPn is tied low. That has the use
>> case to initially program the flash and then lock it forever. So we
>> might add a warning note, that WPn should somehow be controllable
>> (or be sure that is tied high) before conducting the locking tests.
>
> Yes, that is the situation I met, it is not documented anywhere except
> the code.
>
> My intent with this paragraph was to hint people not to conduct these
> tests under certain situations, but we can definitely improve that. What
> about:
>
> 5) If your flash supports locking, please got through the following test
> procedure to make sure it correctly behaves.
>
> Warning: These tests may hard lock your device! Make sure:
> - The device is not hard locked already (#WP strapped to low and
> SR_SRWD bit set)
> - If you have a #WP pin, you may want to set `no-wp` in your DT for
> the time of the test, to only make use of software protection.
Yes that is much better. BTW, I've never seen "#signal" but only
SIG#, nSIG, SIGn or /SIG, maybe I haven't paid too much attention.
> Please amend this text if you still think it is missing his goal.
What about
- If you have a WPn pin, you may want to set `no-wp` in your DT for
the time of the test, to only make use of software protection.
Otherwise, clearing the locking state depends on the WPn
signal and if it is tied to low, the flash will be permanently
locked.
>
>>> + root@1:~# flash_lock -u /dev/mtd0
>>> + root@1:~# flash_lock -l /dev/mtd0 $(($size - (2 * $bs))) 2 # last two
>>> + root@1:~# show_sectors
>>> + software locked sectors
>>> + region (in hex) | status | #blocks
>>> + ------------------+----------+--------
>>> + 00000000-03fdffff | unlocked | 1022
>>> + 03fe0000-03ffffff | locked | 2
>>> + root@1:~# flash_lock -u /dev/mtd0 $(($size - (2 * $bs))) 1 # last one
>>
>> huh? shouldn't that be 1 * $bs?
>
> I don't think so:
> - first we lock the last two blocks (offset: size - 2 blocks, length: 2
> blocks)
> - then we unlock the penultimate block so that only the last block
> remains locked (offset: size - 2 blocks, length 1).
Yes you're correct. I've read the -u for a -l (and somehow assumed
a complete unlock in between).
> I we were doing flash_lock -u <mtd> $(($size - (1 * $bs))) 1, we would
> be asking to unlock the very last block and keep only the penultimate
> block locked, which would not be supported.
>
> Thanks,
> Miquèl
>> 5) If your flash supports locking, please got through the following test >> procedure to make sure it correctly behaves. >> >> Warning: These tests may hard lock your device! Make sure: >> - The device is not hard locked already (#WP strapped to low and >> SR_SRWD bit set) >> - If you have a #WP pin, you may want to set `no-wp` in your DT for >> the time of the test, to only make use of software protection. > > Yes that is much better. BTW, I've never seen "#signal" but only > SIG#, nSIG, SIGn or /SIG, maybe I haven't paid too much attention. Ah, right. I'm fine either ways. I'll look for occurrences and use one of your suggestions. >> Please amend this text if you still think it is missing his goal. > > What about > > - If you have a WPn pin, you may want to set `no-wp` in your DT for > the time of the test, to only make use of software protection. > Otherwise, clearing the locking state depends on the WPn > signal and if it is tied to low, the flash will be permanently > locked. Yep, I'll use that. >>>> + root@1:~# flash_lock -u /dev/mtd0 >>>> + root@1:~# flash_lock -l /dev/mtd0 $(($size - (2 * $bs))) 2 # last two >>>> + root@1:~# show_sectors >>>> + software locked sectors >>>> + region (in hex) | status | #blocks >>>> + ------------------+----------+-------- >>>> + 00000000-03fdffff | unlocked | 1022 >>>> + 03fe0000-03ffffff | locked | 2 >>>> + root@1:~# flash_lock -u /dev/mtd0 $(($size - (2 * $bs))) 1 # last one >>> >>> huh? shouldn't that be 1 * $bs? >> >> I don't think so: >> - first we lock the last two blocks (offset: size - 2 blocks, length: 2 >> blocks) >> - then we unlock the penultimate block so that only the last block >> remains locked (offset: size - 2 blocks, length 1). > > Yes you're correct. I've read the -u for a -l (and somehow assumed > a complete unlock in between). You cannot imagine how many times this happened to me while writing/testing/documenting all this :-) Thanks, Miquèl
© 2016 - 2026 Red Hat, Inc.