From: Greg KH <gregkh@linuxfoundation.org>
To: Gao Xiang <hsiangkao@linux.alibaba.com>
Cc: Juhyung Park <qkrwngud825@gmail.com>,
Yifan Zhao <zhaoyifan@sjtu.edu.cn>,
linux-erofs@lists.ozlabs.org, stable@vger.kernel.org
Subject: Re: [PATCH 5.10.y] erofs: fix lz4 inplace decompression
Date: Sun, 25 Feb 2024 11:45:43 +0100 [thread overview]
Message-ID: <2024022527-voicing-overbite-04be@gregkh> (raw)
In-Reply-To: <20240224063248.2157885-1-hsiangkao@linux.alibaba.com>
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@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@vger.kernel.org> # 5.4+
> Tested-by: Yifan Zhao <zhaoyifan@sjtu.edu.cn>
> Signed-off-by: Gao Xiang <hsiangkao@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
prev parent reply other threads:[~2024-02-25 10:46 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <2024012650-altitude-gush-572f@gregkh>
2024-02-24 6:32 ` [PATCH 5.10.y] erofs: fix lz4 inplace decompression Gao Xiang
2024-02-25 10:45 ` Greg KH [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2024022527-voicing-overbite-04be@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=hsiangkao@linux.alibaba.com \
--cc=linux-erofs@lists.ozlabs.org \
--cc=qkrwngud825@gmail.com \
--cc=stable@vger.kernel.org \
--cc=zhaoyifan@sjtu.edu.cn \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).