Re: [PATCH] generic/286: fix integer underflow on block sizes != 4096

[Eryu Guan <eguan@linux.alibaba.com>]

On Tue, May 25, 2021 at 07:34:14PM +0200, Jakob Unterwurzacher wrote:
> On Sun, May 23, 2021 at 11:05 AM Eryu Guan <guan@eryu.me> wrote:
> > The total read length should be
> >
> > "The length of this extent is (hole_off - data_off)"
> >
> > according to the comments above do_extent_copy(). Total read length
> > being not a multiple of 4k means 'data_off' or 'hole_off' is not 4k
> > aligned.
> 
> That is correct.
> 
> > But generic/286 creates source files with length of all data extents and
> > hole extents being multiple of 4k. So I still don't understand why this
> > is valid for gocryptfs. Shouldn't that be a bug in seek_data/seek_hole
> > in gocryptfs? Could you please elaborate?
> 
> Yes sure, the situation is a bit complicated. gocryptfs works similar
> to eCryptFS and EncFS (also overlay filesystems).
> The files are stored in encrypted form in regular files on ext4 or xfs
> or whatever "real disk" filesystem.
> Disk space allocation & file holes are handled by the real filesystem.
> A gocryptfs mount shows a decrypted view of these files.
> 
> Now, gocryptfs uses AES-GCM for encryption. This adds 32 bytes of
> overhead to every 4096-byte block,
> which gives a storage size of 4128 bytes.

Ah, that makes sense to me now. Would you please include the detailed
explaination in commit log as well?

Thanks,
Eryu

> 
> The encryption overhead is why the files & holes created by
> generic/286 are not 4k-aligned on disk when viewed through the
> gocryptfs mount.
> 
> Thanks, Jakob