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 <[email protected]> > Closes: > https://lore.kernel.org/r/cad14+f2avkf8fa2oo1aauddntdsvzzr6ctu_ojsmtyd6zsy...@mail.gmail.com > Fixes: 0ffd71bcc3a0 ("staging: erofs: introduce LZ4 decompression inplace") > Fixes: 598162d05080 ("erofs: support decompress big pcluster for lz4 backend") > Cc: stable <[email protected]> # 5.4+ > Tested-by: Yifan Zhao <[email protected]> > Signed-off-by: Gao Xiang <[email protected]> > Link: > https://lore.kernel.org/r/[email protected] > --- > Adapt 5.10.y codebase due to non-trivial conflicts out of > recent new features & cleanups.
Both now queued up, thanks. greg k-h
