[PATCH 5.10.y] erofs: fix lz4 inplace decompression

[Greg KH]

On Sat, Feb 24, 2024 at 02:32:48PM +0800, Gao Xiang wrote:
> commit 3c12466b6b7bf1e56f9b32c366a3d83d87afb4de upstream.
> 
> Currently EROFS can map another compressed buffer for inplace
> decompression, that was used to handle the cases that some pages of
> compressed data are actually not in-place I/O.
> 
> However, like most simple LZ77 algorithms, LZ4 expects the compressed
> data is arranged at the end of the decompressed buffer and it
> explicitly uses memmove() to handle overlapping:
>   __________________________________________________________
>  |_ direction of decompression --> ____ |_ compressed data _|
> 
> Although EROFS arranges compressed data like this, it typically maps two
> individual virtual buffers so the relative order is uncertain.
> Previously, it was hardly observed since LZ4 only uses memmove() for
> short overlapped literals and x86/arm64 memmove implementations seem to
> completely cover it up and they don't have this issue.  Juhyung reported
> that EROFS data corruption can be found on a new Intel x86 processor.
> After some analysis, it seems that recent x86 processors with the new
> FSRM feature expose this issue with "rep movsb".
> 
> Let's strictly use the decompressed buffer for lz4 inplace
> decompression for now.  Later, as an useful improvement, we could try
> to tie up these two buffers together in the correct order.
> 
> Reported-and-tested-by: Juhyung Park <qkrwngud825 at gmail.com>
> Closes: https://lore.kernel.org/r/CAD14+f2AVKf8Fa2OO1aAUdDNTDsVzzR6ctU_oJSmTyd6zSYR2Q@mail.gmail.com
> Fixes: 0ffd71bcc3a0 ("staging: erofs: introduce LZ4 decompression inplace")
> Fixes: 598162d05080 ("erofs: support decompress big pcluster for lz4 backend")
> Cc: stable <stable at vger.kernel.org> # 5.4+
> Tested-by: Yifan Zhao <zhaoyifan at sjtu.edu.cn>
> Signed-off-by: Gao Xiang <hsiangkao at linux.alibaba.com>
> Link: https://lore.kernel.org/r/20231206045534.3920847-1-hsiangkao@linux.alibaba.com
> ---
> Adapt 5.10.y codebase due to non-trivial conflicts out of
> recent new features & cleanups.

Both now queued up, thanks.

greg k-h