[dm-crypt] luks header on initramfs img fails due to no O_DIRECT support in tmpfs

[dm-crypt] luks header on initramfs img fails due to no O_DIRECT support in tmpfs

[Natanael Copa]

Hi,

I found this posting while looking at an issue with cryptsetup-1.6.5 in initramfs:
http://www.saout.de/pipermail/dm-crypt/2014-August/004227.html

I believe this is same thing as reported here:
http://bugs.alpinelinux.org/issues/3281

Seems like the problem is that open(2) does not support O_DIRECT when on tmpfs.

I don't subscribe to your mailing list but wanted to share anyways.

Thanks!

-nc

Re: [dm-crypt] luks header on initramfs img fails due to no O_DIRECT support in tmpfs

[Milan Broz]

On 08/08/2014 09:22 AM, Natanael Copa wrote:
> I found this posting while looking at an issue with cryptsetup-1.6.5 in initramfs:
> http://www.saout.de/pipermail/dm-crypt/2014-August/004227.html
> 
> I believe this is same thing as reported here:
> http://bugs.alpinelinux.org/issues/3281
> 
> Seems like the problem is that open(2) does not support O_DIRECT when on tmpfs.

Yes, I expected something like that.

In cryptsetup 1.6.4 this was not happening because it was hidden by temporary dmcrypt
device in the middle of stack.

It is kernel bug, O_DIRECT should work on tmpfs and similar devices.

Anyway, it should also work on older kernels, so I'll think about implementing
some workaround here.

Thanks,
Milan

Re: [dm-crypt] luks header on initramfs img fails due to no O_DIRECT support in tmpfs

[Milan Broz]

On 08/08/2014 09:22 AM, Natanael Copa wrote:
> Hi,
> 
> I found this posting while looking at an issue with cryptsetup-1.6.5 in initramfs:
> http://www.saout.de/pipermail/dm-crypt/2014-August/004227.html
> 
> I believe this is same thing as reported here:
> http://bugs.alpinelinux.org/issues/3281
> 
> Seems like the problem is that open(2) does not support O_DIRECT when on tmpfs.
> 
> I don't subscribe to your mailing list but wanted to share anyways.

BTW I see patch removing O_DIRECT completely in your distro.

As you already mentioned in comment in link above, please do not do this.
You are risking data corruption in some situations.
Using direct-io should ensure that block device is really updated
(And also we really do not want to cache keyslot content in memory.)

I know it is not 100% solution but the best way is to report the problem
here and then backport upstream fix.

(Just use existing device_open() which tries to open device twice, also no need
to patch old code which do not fail. See upstream commit, I also added
test for tmpfs to not repeat the problem again in future.)

Thanks,
Milan