2019-07-31 18:57:31 +03:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-only
|
2019-06-24 10:22:55 +03:00
|
|
|
/*
|
|
|
|
* Copyright (C) 2019 HUAWEI, Inc.
|
2020-07-13 16:09:44 +03:00
|
|
|
* https://www.huawei.com/
|
2019-06-24 10:22:55 +03:00
|
|
|
*/
|
|
|
|
#include "compress.h"
|
2019-07-31 18:57:44 +03:00
|
|
|
#include <linux/module.h>
|
2019-06-24 10:22:55 +03:00
|
|
|
#include <linux/lz4.h>
|
|
|
|
|
|
|
|
#ifndef LZ4_DISTANCE_MAX /* history window size */
|
|
|
|
#define LZ4_DISTANCE_MAX 65535 /* set to maximum value by default */
|
|
|
|
#endif
|
|
|
|
|
staging: erofs: fix LZ4 limited bounced page mis-reuse
Like all lz77-based algrithms, lz4 has a dynamically populated
("sliding window") dictionary and the maximum lookback distance
is 65535. Therefore the number of bounced pages could be limited
by erofs based on this property.
However, just now we observed some lz4 sequences in the extreme
case cannot be decompressed correctly after this feature is enabled,
the root causes after analysis are clear as follows:
1) max bounced pages should be 17 rather than 16 pages;
2) considering the following case, the broken implementation
could reuse unsafely in advance (in other words, reuse it
less than a safe distance),
0 1 2 ... 16 17 18 ... 33 34
b p b b
note that the bounce page that we are concerned was allocated
at 0, and it reused at 18 since page 17 exists, but it mis-reused
at 34 in advance again, which causes decompress failure.
This patch resolves the issue by introducing a bitmap to mark
whether the page in the same position of last round is a bounced
page or not, and a micro stack data structure to store all
available bounced pages.
Fixes: 7fc45dbc938a ("staging: erofs: introduce generic decompression backend")
Reviewed-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Gao Xiang <gaoxiang25@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-07-03 09:52:09 +03:00
|
|
|
#define LZ4_MAX_DISTANCE_PAGES (DIV_ROUND_UP(LZ4_DISTANCE_MAX, PAGE_SIZE) + 1)
|
2019-06-24 10:22:56 +03:00
|
|
|
#ifndef LZ4_DECOMPRESS_INPLACE_MARGIN
|
|
|
|
#define LZ4_DECOMPRESS_INPLACE_MARGIN(srcsize) (((srcsize) >> 8) + 32)
|
|
|
|
#endif
|
2019-06-24 10:22:55 +03:00
|
|
|
|
2021-03-29 04:23:06 +03:00
|
|
|
int z_erofs_load_lz4_config(struct super_block *sb,
|
2021-03-29 04:23:07 +03:00
|
|
|
struct erofs_super_block *dsb,
|
|
|
|
struct z_erofs_lz4_cfgs *lz4, int size)
|
2021-03-29 04:23:06 +03:00
|
|
|
{
|
2021-04-07 07:39:23 +03:00
|
|
|
struct erofs_sb_info *sbi = EROFS_SB(sb);
|
2021-03-29 04:23:07 +03:00
|
|
|
u16 distance;
|
|
|
|
|
|
|
|
if (lz4) {
|
|
|
|
if (size < sizeof(struct z_erofs_lz4_cfgs)) {
|
|
|
|
erofs_err(sb, "invalid lz4 cfgs, size=%u", size);
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
distance = le16_to_cpu(lz4->max_distance);
|
2021-04-07 07:39:23 +03:00
|
|
|
|
|
|
|
sbi->lz4.max_pclusterblks = le16_to_cpu(lz4->max_pclusterblks);
|
|
|
|
if (!sbi->lz4.max_pclusterblks) {
|
|
|
|
sbi->lz4.max_pclusterblks = 1; /* reserved case */
|
|
|
|
} else if (sbi->lz4.max_pclusterblks >
|
|
|
|
Z_EROFS_PCLUSTER_MAX_SIZE / EROFS_BLKSIZ) {
|
|
|
|
erofs_err(sb, "too large lz4 pclusterblks %u",
|
|
|
|
sbi->lz4.max_pclusterblks);
|
|
|
|
return -EINVAL;
|
|
|
|
} else if (sbi->lz4.max_pclusterblks >= 2) {
|
|
|
|
erofs_info(sb, "EXPERIMENTAL big pcluster feature in use. Use at your own risk!");
|
|
|
|
}
|
2021-03-29 04:23:07 +03:00
|
|
|
} else {
|
2021-03-29 13:00:12 +03:00
|
|
|
distance = le16_to_cpu(dsb->u1.lz4_max_distance);
|
2021-04-07 07:39:23 +03:00
|
|
|
sbi->lz4.max_pclusterblks = 1;
|
2021-03-29 04:23:07 +03:00
|
|
|
}
|
2021-03-29 04:23:06 +03:00
|
|
|
|
2021-04-07 07:39:23 +03:00
|
|
|
sbi->lz4.max_distance_pages = distance ?
|
2021-03-29 04:23:06 +03:00
|
|
|
DIV_ROUND_UP(distance, PAGE_SIZE) + 1 :
|
|
|
|
LZ4_MAX_DISTANCE_PAGES;
|
2021-04-07 07:39:23 +03:00
|
|
|
return erofs_pcpubuf_growsize(sbi->lz4.max_pclusterblks);
|
2021-03-29 04:23:06 +03:00
|
|
|
}
|
|
|
|
|
2021-10-11 00:31:44 +03:00
|
|
|
/*
|
|
|
|
* Fill all gaps with bounce pages if it's a sparse page list. Also check if
|
|
|
|
* all physical pages are consecutive, which can be seen for moderate CR.
|
|
|
|
*/
|
|
|
|
static int z_erofs_lz4_prepare_dstpages(struct z_erofs_decompress_req *rq,
|
2021-10-22 12:01:20 +03:00
|
|
|
struct page **pagepool)
|
2019-06-24 10:22:55 +03:00
|
|
|
{
|
|
|
|
const unsigned int nr =
|
|
|
|
PAGE_ALIGN(rq->pageofs_out + rq->outputsize) >> PAGE_SHIFT;
|
|
|
|
struct page *availables[LZ4_MAX_DISTANCE_PAGES] = { NULL };
|
staging: erofs: fix LZ4 limited bounced page mis-reuse
Like all lz77-based algrithms, lz4 has a dynamically populated
("sliding window") dictionary and the maximum lookback distance
is 65535. Therefore the number of bounced pages could be limited
by erofs based on this property.
However, just now we observed some lz4 sequences in the extreme
case cannot be decompressed correctly after this feature is enabled,
the root causes after analysis are clear as follows:
1) max bounced pages should be 17 rather than 16 pages;
2) considering the following case, the broken implementation
could reuse unsafely in advance (in other words, reuse it
less than a safe distance),
0 1 2 ... 16 17 18 ... 33 34
b p b b
note that the bounce page that we are concerned was allocated
at 0, and it reused at 18 since page 17 exists, but it mis-reused
at 34 in advance again, which causes decompress failure.
This patch resolves the issue by introducing a bitmap to mark
whether the page in the same position of last round is a bounced
page or not, and a micro stack data structure to store all
available bounced pages.
Fixes: 7fc45dbc938a ("staging: erofs: introduce generic decompression backend")
Reviewed-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Gao Xiang <gaoxiang25@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-07-03 09:52:09 +03:00
|
|
|
unsigned long bounced[DIV_ROUND_UP(LZ4_MAX_DISTANCE_PAGES,
|
|
|
|
BITS_PER_LONG)] = { 0 };
|
2021-03-29 04:23:06 +03:00
|
|
|
unsigned int lz4_max_distance_pages =
|
|
|
|
EROFS_SB(rq->sb)->lz4.max_distance_pages;
|
2019-06-24 10:22:55 +03:00
|
|
|
void *kaddr = NULL;
|
staging: erofs: fix LZ4 limited bounced page mis-reuse
Like all lz77-based algrithms, lz4 has a dynamically populated
("sliding window") dictionary and the maximum lookback distance
is 65535. Therefore the number of bounced pages could be limited
by erofs based on this property.
However, just now we observed some lz4 sequences in the extreme
case cannot be decompressed correctly after this feature is enabled,
the root causes after analysis are clear as follows:
1) max bounced pages should be 17 rather than 16 pages;
2) considering the following case, the broken implementation
could reuse unsafely in advance (in other words, reuse it
less than a safe distance),
0 1 2 ... 16 17 18 ... 33 34
b p b b
note that the bounce page that we are concerned was allocated
at 0, and it reused at 18 since page 17 exists, but it mis-reused
at 34 in advance again, which causes decompress failure.
This patch resolves the issue by introducing a bitmap to mark
whether the page in the same position of last round is a bounced
page or not, and a micro stack data structure to store all
available bounced pages.
Fixes: 7fc45dbc938a ("staging: erofs: introduce generic decompression backend")
Reviewed-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Gao Xiang <gaoxiang25@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-07-03 09:52:09 +03:00
|
|
|
unsigned int i, j, top;
|
2019-06-24 10:22:55 +03:00
|
|
|
|
staging: erofs: fix LZ4 limited bounced page mis-reuse
Like all lz77-based algrithms, lz4 has a dynamically populated
("sliding window") dictionary and the maximum lookback distance
is 65535. Therefore the number of bounced pages could be limited
by erofs based on this property.
However, just now we observed some lz4 sequences in the extreme
case cannot be decompressed correctly after this feature is enabled,
the root causes after analysis are clear as follows:
1) max bounced pages should be 17 rather than 16 pages;
2) considering the following case, the broken implementation
could reuse unsafely in advance (in other words, reuse it
less than a safe distance),
0 1 2 ... 16 17 18 ... 33 34
b p b b
note that the bounce page that we are concerned was allocated
at 0, and it reused at 18 since page 17 exists, but it mis-reused
at 34 in advance again, which causes decompress failure.
This patch resolves the issue by introducing a bitmap to mark
whether the page in the same position of last round is a bounced
page or not, and a micro stack data structure to store all
available bounced pages.
Fixes: 7fc45dbc938a ("staging: erofs: introduce generic decompression backend")
Reviewed-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Gao Xiang <gaoxiang25@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-07-03 09:52:09 +03:00
|
|
|
top = 0;
|
|
|
|
for (i = j = 0; i < nr; ++i, ++j) {
|
2019-06-24 10:22:55 +03:00
|
|
|
struct page *const page = rq->out[i];
|
staging: erofs: fix LZ4 limited bounced page mis-reuse
Like all lz77-based algrithms, lz4 has a dynamically populated
("sliding window") dictionary and the maximum lookback distance
is 65535. Therefore the number of bounced pages could be limited
by erofs based on this property.
However, just now we observed some lz4 sequences in the extreme
case cannot be decompressed correctly after this feature is enabled,
the root causes after analysis are clear as follows:
1) max bounced pages should be 17 rather than 16 pages;
2) considering the following case, the broken implementation
could reuse unsafely in advance (in other words, reuse it
less than a safe distance),
0 1 2 ... 16 17 18 ... 33 34
b p b b
note that the bounce page that we are concerned was allocated
at 0, and it reused at 18 since page 17 exists, but it mis-reused
at 34 in advance again, which causes decompress failure.
This patch resolves the issue by introducing a bitmap to mark
whether the page in the same position of last round is a bounced
page or not, and a micro stack data structure to store all
available bounced pages.
Fixes: 7fc45dbc938a ("staging: erofs: introduce generic decompression backend")
Reviewed-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Gao Xiang <gaoxiang25@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-07-03 09:52:09 +03:00
|
|
|
struct page *victim;
|
2019-06-24 10:22:55 +03:00
|
|
|
|
2021-03-29 04:23:06 +03:00
|
|
|
if (j >= lz4_max_distance_pages)
|
staging: erofs: fix LZ4 limited bounced page mis-reuse
Like all lz77-based algrithms, lz4 has a dynamically populated
("sliding window") dictionary and the maximum lookback distance
is 65535. Therefore the number of bounced pages could be limited
by erofs based on this property.
However, just now we observed some lz4 sequences in the extreme
case cannot be decompressed correctly after this feature is enabled,
the root causes after analysis are clear as follows:
1) max bounced pages should be 17 rather than 16 pages;
2) considering the following case, the broken implementation
could reuse unsafely in advance (in other words, reuse it
less than a safe distance),
0 1 2 ... 16 17 18 ... 33 34
b p b b
note that the bounce page that we are concerned was allocated
at 0, and it reused at 18 since page 17 exists, but it mis-reused
at 34 in advance again, which causes decompress failure.
This patch resolves the issue by introducing a bitmap to mark
whether the page in the same position of last round is a bounced
page or not, and a micro stack data structure to store all
available bounced pages.
Fixes: 7fc45dbc938a ("staging: erofs: introduce generic decompression backend")
Reviewed-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Gao Xiang <gaoxiang25@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-07-03 09:52:09 +03:00
|
|
|
j = 0;
|
|
|
|
|
|
|
|
/* 'valid' bounced can only be tested after a complete round */
|
|
|
|
if (test_bit(j, bounced)) {
|
2021-03-29 04:23:06 +03:00
|
|
|
DBG_BUGON(i < lz4_max_distance_pages);
|
|
|
|
DBG_BUGON(top >= lz4_max_distance_pages);
|
|
|
|
availables[top++] = rq->out[i - lz4_max_distance_pages];
|
staging: erofs: fix LZ4 limited bounced page mis-reuse
Like all lz77-based algrithms, lz4 has a dynamically populated
("sliding window") dictionary and the maximum lookback distance
is 65535. Therefore the number of bounced pages could be limited
by erofs based on this property.
However, just now we observed some lz4 sequences in the extreme
case cannot be decompressed correctly after this feature is enabled,
the root causes after analysis are clear as follows:
1) max bounced pages should be 17 rather than 16 pages;
2) considering the following case, the broken implementation
could reuse unsafely in advance (in other words, reuse it
less than a safe distance),
0 1 2 ... 16 17 18 ... 33 34
b p b b
note that the bounce page that we are concerned was allocated
at 0, and it reused at 18 since page 17 exists, but it mis-reused
at 34 in advance again, which causes decompress failure.
This patch resolves the issue by introducing a bitmap to mark
whether the page in the same position of last round is a bounced
page or not, and a micro stack data structure to store all
available bounced pages.
Fixes: 7fc45dbc938a ("staging: erofs: introduce generic decompression backend")
Reviewed-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Gao Xiang <gaoxiang25@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-07-03 09:52:09 +03:00
|
|
|
}
|
2019-06-24 10:22:55 +03:00
|
|
|
|
|
|
|
if (page) {
|
staging: erofs: fix LZ4 limited bounced page mis-reuse
Like all lz77-based algrithms, lz4 has a dynamically populated
("sliding window") dictionary and the maximum lookback distance
is 65535. Therefore the number of bounced pages could be limited
by erofs based on this property.
However, just now we observed some lz4 sequences in the extreme
case cannot be decompressed correctly after this feature is enabled,
the root causes after analysis are clear as follows:
1) max bounced pages should be 17 rather than 16 pages;
2) considering the following case, the broken implementation
could reuse unsafely in advance (in other words, reuse it
less than a safe distance),
0 1 2 ... 16 17 18 ... 33 34
b p b b
note that the bounce page that we are concerned was allocated
at 0, and it reused at 18 since page 17 exists, but it mis-reused
at 34 in advance again, which causes decompress failure.
This patch resolves the issue by introducing a bitmap to mark
whether the page in the same position of last round is a bounced
page or not, and a micro stack data structure to store all
available bounced pages.
Fixes: 7fc45dbc938a ("staging: erofs: introduce generic decompression backend")
Reviewed-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Gao Xiang <gaoxiang25@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-07-03 09:52:09 +03:00
|
|
|
__clear_bit(j, bounced);
|
2019-06-24 10:22:55 +03:00
|
|
|
if (kaddr) {
|
|
|
|
if (kaddr + PAGE_SIZE == page_address(page))
|
|
|
|
kaddr += PAGE_SIZE;
|
|
|
|
else
|
|
|
|
kaddr = NULL;
|
|
|
|
} else if (!i) {
|
|
|
|
kaddr = page_address(page);
|
|
|
|
}
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
kaddr = NULL;
|
staging: erofs: fix LZ4 limited bounced page mis-reuse
Like all lz77-based algrithms, lz4 has a dynamically populated
("sliding window") dictionary and the maximum lookback distance
is 65535. Therefore the number of bounced pages could be limited
by erofs based on this property.
However, just now we observed some lz4 sequences in the extreme
case cannot be decompressed correctly after this feature is enabled,
the root causes after analysis are clear as follows:
1) max bounced pages should be 17 rather than 16 pages;
2) considering the following case, the broken implementation
could reuse unsafely in advance (in other words, reuse it
less than a safe distance),
0 1 2 ... 16 17 18 ... 33 34
b p b b
note that the bounce page that we are concerned was allocated
at 0, and it reused at 18 since page 17 exists, but it mis-reused
at 34 in advance again, which causes decompress failure.
This patch resolves the issue by introducing a bitmap to mark
whether the page in the same position of last round is a bounced
page or not, and a micro stack data structure to store all
available bounced pages.
Fixes: 7fc45dbc938a ("staging: erofs: introduce generic decompression backend")
Reviewed-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Gao Xiang <gaoxiang25@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-07-03 09:52:09 +03:00
|
|
|
__set_bit(j, bounced);
|
2019-06-24 10:22:55 +03:00
|
|
|
|
staging: erofs: fix LZ4 limited bounced page mis-reuse
Like all lz77-based algrithms, lz4 has a dynamically populated
("sliding window") dictionary and the maximum lookback distance
is 65535. Therefore the number of bounced pages could be limited
by erofs based on this property.
However, just now we observed some lz4 sequences in the extreme
case cannot be decompressed correctly after this feature is enabled,
the root causes after analysis are clear as follows:
1) max bounced pages should be 17 rather than 16 pages;
2) considering the following case, the broken implementation
could reuse unsafely in advance (in other words, reuse it
less than a safe distance),
0 1 2 ... 16 17 18 ... 33 34
b p b b
note that the bounce page that we are concerned was allocated
at 0, and it reused at 18 since page 17 exists, but it mis-reused
at 34 in advance again, which causes decompress failure.
This patch resolves the issue by introducing a bitmap to mark
whether the page in the same position of last round is a bounced
page or not, and a micro stack data structure to store all
available bounced pages.
Fixes: 7fc45dbc938a ("staging: erofs: introduce generic decompression backend")
Reviewed-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Gao Xiang <gaoxiang25@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-07-03 09:52:09 +03:00
|
|
|
if (top) {
|
|
|
|
victim = availables[--top];
|
|
|
|
get_page(victim);
|
2019-06-24 10:22:55 +03:00
|
|
|
} else {
|
2021-03-16 06:15:14 +03:00
|
|
|
victim = erofs_allocpage(pagepool,
|
|
|
|
GFP_KERNEL | __GFP_NOFAIL);
|
2020-12-08 12:58:32 +03:00
|
|
|
set_page_private(victim, Z_EROFS_SHORTLIVED_PAGE);
|
2019-06-24 10:22:55 +03:00
|
|
|
}
|
staging: erofs: fix LZ4 limited bounced page mis-reuse
Like all lz77-based algrithms, lz4 has a dynamically populated
("sliding window") dictionary and the maximum lookback distance
is 65535. Therefore the number of bounced pages could be limited
by erofs based on this property.
However, just now we observed some lz4 sequences in the extreme
case cannot be decompressed correctly after this feature is enabled,
the root causes after analysis are clear as follows:
1) max bounced pages should be 17 rather than 16 pages;
2) considering the following case, the broken implementation
could reuse unsafely in advance (in other words, reuse it
less than a safe distance),
0 1 2 ... 16 17 18 ... 33 34
b p b b
note that the bounce page that we are concerned was allocated
at 0, and it reused at 18 since page 17 exists, but it mis-reused
at 34 in advance again, which causes decompress failure.
This patch resolves the issue by introducing a bitmap to mark
whether the page in the same position of last round is a bounced
page or not, and a micro stack data structure to store all
available bounced pages.
Fixes: 7fc45dbc938a ("staging: erofs: introduce generic decompression backend")
Reviewed-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Gao Xiang <gaoxiang25@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-07-03 09:52:09 +03:00
|
|
|
rq->out[i] = victim;
|
2019-06-24 10:22:55 +03:00
|
|
|
}
|
|
|
|
return kaddr ? 1 : 0;
|
|
|
|
}
|
|
|
|
|
2021-10-11 00:31:44 +03:00
|
|
|
static void *z_erofs_lz4_handle_inplace_io(struct z_erofs_decompress_req *rq,
|
erofs: support decompress big pcluster for lz4 backend
Prior to big pcluster, there was only one compressed page so it'd
easy to map this. However, when big pcluster is enabled, more work
needs to be done to handle multiple compressed pages. In detail,
- (maptype 0) if there is only one compressed page + no need
to copy inplace I/O, just map it directly what we did before;
- (maptype 1) if there are more compressed pages + no need to
copy inplace I/O, vmap such compressed pages instead;
- (maptype 2) if inplace I/O needs to be copied, use per-CPU
buffers for decompression then.
Another thing is how to detect inplace decompression is feasable or
not (it's still quite easy for non big pclusters), apart from the
inplace margin calculation, inplace I/O page reusing order is also
needed to be considered for each compressed page. Currently, if the
compressed page is the xth page, it shouldn't be reused as [0 ...
nrpages_out - nrpages_in + x], otherwise a full copy will be triggered.
Although there are some extra optimization ideas for this, I'd like
to make big pcluster work correctly first and obviously it can be
further optimized later since it has nothing with the on-disk format
at all.
Link: https://lore.kernel.org/r/20210407043927.10623-10-xiang@kernel.org
Acked-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Gao Xiang <hsiangkao@redhat.com>
2021-04-07 07:39:26 +03:00
|
|
|
void *inpage, unsigned int *inputmargin, int *maptype,
|
|
|
|
bool support_0padding)
|
2019-06-24 10:22:55 +03:00
|
|
|
{
|
erofs: support decompress big pcluster for lz4 backend
Prior to big pcluster, there was only one compressed page so it'd
easy to map this. However, when big pcluster is enabled, more work
needs to be done to handle multiple compressed pages. In detail,
- (maptype 0) if there is only one compressed page + no need
to copy inplace I/O, just map it directly what we did before;
- (maptype 1) if there are more compressed pages + no need to
copy inplace I/O, vmap such compressed pages instead;
- (maptype 2) if inplace I/O needs to be copied, use per-CPU
buffers for decompression then.
Another thing is how to detect inplace decompression is feasable or
not (it's still quite easy for non big pclusters), apart from the
inplace margin calculation, inplace I/O page reusing order is also
needed to be considered for each compressed page. Currently, if the
compressed page is the xth page, it shouldn't be reused as [0 ...
nrpages_out - nrpages_in + x], otherwise a full copy will be triggered.
Although there are some extra optimization ideas for this, I'd like
to make big pcluster work correctly first and obviously it can be
further optimized later since it has nothing with the on-disk format
at all.
Link: https://lore.kernel.org/r/20210407043927.10623-10-xiang@kernel.org
Acked-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Gao Xiang <hsiangkao@redhat.com>
2021-04-07 07:39:26 +03:00
|
|
|
unsigned int nrpages_in, nrpages_out;
|
|
|
|
unsigned int ofull, oend, inputsize, total, i, j;
|
|
|
|
struct page **in;
|
|
|
|
void *src, *tmp;
|
|
|
|
|
|
|
|
inputsize = rq->inputsize;
|
|
|
|
nrpages_in = PAGE_ALIGN(inputsize) >> PAGE_SHIFT;
|
|
|
|
oend = rq->pageofs_out + rq->outputsize;
|
|
|
|
ofull = PAGE_ALIGN(oend);
|
|
|
|
nrpages_out = ofull >> PAGE_SHIFT;
|
|
|
|
|
|
|
|
if (rq->inplace_io) {
|
|
|
|
if (rq->partial_decoding || !support_0padding ||
|
|
|
|
ofull - oend < LZ4_DECOMPRESS_INPLACE_MARGIN(inputsize))
|
|
|
|
goto docopy;
|
|
|
|
|
|
|
|
for (i = 0; i < nrpages_in; ++i) {
|
|
|
|
DBG_BUGON(rq->in[i] == NULL);
|
|
|
|
for (j = 0; j < nrpages_out - nrpages_in + i; ++j)
|
|
|
|
if (rq->out[j] == rq->in[i])
|
|
|
|
goto docopy;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (nrpages_in <= 1) {
|
|
|
|
*maptype = 0;
|
|
|
|
return inpage;
|
|
|
|
}
|
|
|
|
kunmap_atomic(inpage);
|
|
|
|
might_sleep();
|
|
|
|
src = erofs_vm_map_ram(rq->in, nrpages_in);
|
|
|
|
if (!src)
|
|
|
|
return ERR_PTR(-ENOMEM);
|
|
|
|
*maptype = 1;
|
|
|
|
return src;
|
|
|
|
|
|
|
|
docopy:
|
|
|
|
/* Or copy compressed data which can be overlapped to per-CPU buffer */
|
|
|
|
in = rq->in;
|
|
|
|
src = erofs_get_pcpubuf(nrpages_in);
|
|
|
|
if (!src) {
|
|
|
|
DBG_BUGON(1);
|
|
|
|
kunmap_atomic(inpage);
|
|
|
|
return ERR_PTR(-EFAULT);
|
|
|
|
}
|
|
|
|
|
|
|
|
tmp = src;
|
|
|
|
total = rq->inputsize;
|
|
|
|
while (total) {
|
|
|
|
unsigned int page_copycnt =
|
|
|
|
min_t(unsigned int, total, PAGE_SIZE - *inputmargin);
|
|
|
|
|
|
|
|
if (!inpage)
|
|
|
|
inpage = kmap_atomic(*in);
|
|
|
|
memcpy(tmp, inpage + *inputmargin, page_copycnt);
|
|
|
|
kunmap_atomic(inpage);
|
|
|
|
inpage = NULL;
|
|
|
|
tmp += page_copycnt;
|
|
|
|
total -= page_copycnt;
|
2019-06-24 10:22:55 +03:00
|
|
|
++in;
|
erofs: support decompress big pcluster for lz4 backend
Prior to big pcluster, there was only one compressed page so it'd
easy to map this. However, when big pcluster is enabled, more work
needs to be done to handle multiple compressed pages. In detail,
- (maptype 0) if there is only one compressed page + no need
to copy inplace I/O, just map it directly what we did before;
- (maptype 1) if there are more compressed pages + no need to
copy inplace I/O, vmap such compressed pages instead;
- (maptype 2) if inplace I/O needs to be copied, use per-CPU
buffers for decompression then.
Another thing is how to detect inplace decompression is feasable or
not (it's still quite easy for non big pclusters), apart from the
inplace margin calculation, inplace I/O page reusing order is also
needed to be considered for each compressed page. Currently, if the
compressed page is the xth page, it shouldn't be reused as [0 ...
nrpages_out - nrpages_in + x], otherwise a full copy will be triggered.
Although there are some extra optimization ideas for this, I'd like
to make big pcluster work correctly first and obviously it can be
further optimized later since it has nothing with the on-disk format
at all.
Link: https://lore.kernel.org/r/20210407043927.10623-10-xiang@kernel.org
Acked-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Gao Xiang <hsiangkao@redhat.com>
2021-04-07 07:39:26 +03:00
|
|
|
*inputmargin = 0;
|
2019-06-24 10:22:55 +03:00
|
|
|
}
|
erofs: support decompress big pcluster for lz4 backend
Prior to big pcluster, there was only one compressed page so it'd
easy to map this. However, when big pcluster is enabled, more work
needs to be done to handle multiple compressed pages. In detail,
- (maptype 0) if there is only one compressed page + no need
to copy inplace I/O, just map it directly what we did before;
- (maptype 1) if there are more compressed pages + no need to
copy inplace I/O, vmap such compressed pages instead;
- (maptype 2) if inplace I/O needs to be copied, use per-CPU
buffers for decompression then.
Another thing is how to detect inplace decompression is feasable or
not (it's still quite easy for non big pclusters), apart from the
inplace margin calculation, inplace I/O page reusing order is also
needed to be considered for each compressed page. Currently, if the
compressed page is the xth page, it shouldn't be reused as [0 ...
nrpages_out - nrpages_in + x], otherwise a full copy will be triggered.
Although there are some extra optimization ideas for this, I'd like
to make big pcluster work correctly first and obviously it can be
further optimized later since it has nothing with the on-disk format
at all.
Link: https://lore.kernel.org/r/20210407043927.10623-10-xiang@kernel.org
Acked-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Gao Xiang <hsiangkao@redhat.com>
2021-04-07 07:39:26 +03:00
|
|
|
*maptype = 2;
|
|
|
|
return src;
|
2019-06-24 10:22:55 +03:00
|
|
|
}
|
|
|
|
|
2021-10-11 00:31:44 +03:00
|
|
|
static int z_erofs_lz4_decompress_mem(struct z_erofs_decompress_req *rq,
|
|
|
|
u8 *out)
|
2019-06-24 10:22:55 +03:00
|
|
|
{
|
erofs: support decompress big pcluster for lz4 backend
Prior to big pcluster, there was only one compressed page so it'd
easy to map this. However, when big pcluster is enabled, more work
needs to be done to handle multiple compressed pages. In detail,
- (maptype 0) if there is only one compressed page + no need
to copy inplace I/O, just map it directly what we did before;
- (maptype 1) if there are more compressed pages + no need to
copy inplace I/O, vmap such compressed pages instead;
- (maptype 2) if inplace I/O needs to be copied, use per-CPU
buffers for decompression then.
Another thing is how to detect inplace decompression is feasable or
not (it's still quite easy for non big pclusters), apart from the
inplace margin calculation, inplace I/O page reusing order is also
needed to be considered for each compressed page. Currently, if the
compressed page is the xth page, it shouldn't be reused as [0 ...
nrpages_out - nrpages_in + x], otherwise a full copy will be triggered.
Although there are some extra optimization ideas for this, I'd like
to make big pcluster work correctly first and obviously it can be
further optimized later since it has nothing with the on-disk format
at all.
Link: https://lore.kernel.org/r/20210407043927.10623-10-xiang@kernel.org
Acked-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Gao Xiang <hsiangkao@redhat.com>
2021-04-07 07:39:26 +03:00
|
|
|
unsigned int inputmargin;
|
|
|
|
u8 *headpage, *src;
|
|
|
|
bool support_0padding;
|
|
|
|
int ret, maptype;
|
2019-06-24 10:22:55 +03:00
|
|
|
|
erofs: support decompress big pcluster for lz4 backend
Prior to big pcluster, there was only one compressed page so it'd
easy to map this. However, when big pcluster is enabled, more work
needs to be done to handle multiple compressed pages. In detail,
- (maptype 0) if there is only one compressed page + no need
to copy inplace I/O, just map it directly what we did before;
- (maptype 1) if there are more compressed pages + no need to
copy inplace I/O, vmap such compressed pages instead;
- (maptype 2) if inplace I/O needs to be copied, use per-CPU
buffers for decompression then.
Another thing is how to detect inplace decompression is feasable or
not (it's still quite easy for non big pclusters), apart from the
inplace margin calculation, inplace I/O page reusing order is also
needed to be considered for each compressed page. Currently, if the
compressed page is the xth page, it shouldn't be reused as [0 ...
nrpages_out - nrpages_in + x], otherwise a full copy will be triggered.
Although there are some extra optimization ideas for this, I'd like
to make big pcluster work correctly first and obviously it can be
further optimized later since it has nothing with the on-disk format
at all.
Link: https://lore.kernel.org/r/20210407043927.10623-10-xiang@kernel.org
Acked-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Gao Xiang <hsiangkao@redhat.com>
2021-04-07 07:39:26 +03:00
|
|
|
DBG_BUGON(*rq->in == NULL);
|
|
|
|
headpage = kmap_atomic(*rq->in);
|
2019-06-24 10:22:55 +03:00
|
|
|
inputmargin = 0;
|
2019-06-24 10:22:56 +03:00
|
|
|
support_0padding = false;
|
|
|
|
|
|
|
|
/* decompression inplace is only safe when 0padding is enabled */
|
2021-03-29 04:23:05 +03:00
|
|
|
if (erofs_sb_has_lz4_0padding(EROFS_SB(rq->sb))) {
|
2019-06-24 10:22:56 +03:00
|
|
|
support_0padding = true;
|
|
|
|
|
erofs: support decompress big pcluster for lz4 backend
Prior to big pcluster, there was only one compressed page so it'd
easy to map this. However, when big pcluster is enabled, more work
needs to be done to handle multiple compressed pages. In detail,
- (maptype 0) if there is only one compressed page + no need
to copy inplace I/O, just map it directly what we did before;
- (maptype 1) if there are more compressed pages + no need to
copy inplace I/O, vmap such compressed pages instead;
- (maptype 2) if inplace I/O needs to be copied, use per-CPU
buffers for decompression then.
Another thing is how to detect inplace decompression is feasable or
not (it's still quite easy for non big pclusters), apart from the
inplace margin calculation, inplace I/O page reusing order is also
needed to be considered for each compressed page. Currently, if the
compressed page is the xth page, it shouldn't be reused as [0 ...
nrpages_out - nrpages_in + x], otherwise a full copy will be triggered.
Although there are some extra optimization ideas for this, I'd like
to make big pcluster work correctly first and obviously it can be
further optimized later since it has nothing with the on-disk format
at all.
Link: https://lore.kernel.org/r/20210407043927.10623-10-xiang@kernel.org
Acked-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Gao Xiang <hsiangkao@redhat.com>
2021-04-07 07:39:26 +03:00
|
|
|
while (!headpage[inputmargin & ~PAGE_MASK])
|
2019-06-24 10:22:56 +03:00
|
|
|
if (!(++inputmargin & ~PAGE_MASK))
|
|
|
|
break;
|
|
|
|
|
|
|
|
if (inputmargin >= rq->inputsize) {
|
erofs: support decompress big pcluster for lz4 backend
Prior to big pcluster, there was only one compressed page so it'd
easy to map this. However, when big pcluster is enabled, more work
needs to be done to handle multiple compressed pages. In detail,
- (maptype 0) if there is only one compressed page + no need
to copy inplace I/O, just map it directly what we did before;
- (maptype 1) if there are more compressed pages + no need to
copy inplace I/O, vmap such compressed pages instead;
- (maptype 2) if inplace I/O needs to be copied, use per-CPU
buffers for decompression then.
Another thing is how to detect inplace decompression is feasable or
not (it's still quite easy for non big pclusters), apart from the
inplace margin calculation, inplace I/O page reusing order is also
needed to be considered for each compressed page. Currently, if the
compressed page is the xth page, it shouldn't be reused as [0 ...
nrpages_out - nrpages_in + x], otherwise a full copy will be triggered.
Although there are some extra optimization ideas for this, I'd like
to make big pcluster work correctly first and obviously it can be
further optimized later since it has nothing with the on-disk format
at all.
Link: https://lore.kernel.org/r/20210407043927.10623-10-xiang@kernel.org
Acked-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Gao Xiang <hsiangkao@redhat.com>
2021-04-07 07:39:26 +03:00
|
|
|
kunmap_atomic(headpage);
|
2019-06-24 10:22:56 +03:00
|
|
|
return -EIO;
|
|
|
|
}
|
|
|
|
}
|
2019-06-24 10:22:55 +03:00
|
|
|
|
erofs: support decompress big pcluster for lz4 backend
Prior to big pcluster, there was only one compressed page so it'd
easy to map this. However, when big pcluster is enabled, more work
needs to be done to handle multiple compressed pages. In detail,
- (maptype 0) if there is only one compressed page + no need
to copy inplace I/O, just map it directly what we did before;
- (maptype 1) if there are more compressed pages + no need to
copy inplace I/O, vmap such compressed pages instead;
- (maptype 2) if inplace I/O needs to be copied, use per-CPU
buffers for decompression then.
Another thing is how to detect inplace decompression is feasable or
not (it's still quite easy for non big pclusters), apart from the
inplace margin calculation, inplace I/O page reusing order is also
needed to be considered for each compressed page. Currently, if the
compressed page is the xth page, it shouldn't be reused as [0 ...
nrpages_out - nrpages_in + x], otherwise a full copy will be triggered.
Although there are some extra optimization ideas for this, I'd like
to make big pcluster work correctly first and obviously it can be
further optimized later since it has nothing with the on-disk format
at all.
Link: https://lore.kernel.org/r/20210407043927.10623-10-xiang@kernel.org
Acked-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Gao Xiang <hsiangkao@redhat.com>
2021-04-07 07:39:26 +03:00
|
|
|
rq->inputsize -= inputmargin;
|
2021-10-11 00:31:44 +03:00
|
|
|
src = z_erofs_lz4_handle_inplace_io(rq, headpage, &inputmargin,
|
|
|
|
&maptype, support_0padding);
|
erofs: support decompress big pcluster for lz4 backend
Prior to big pcluster, there was only one compressed page so it'd
easy to map this. However, when big pcluster is enabled, more work
needs to be done to handle multiple compressed pages. In detail,
- (maptype 0) if there is only one compressed page + no need
to copy inplace I/O, just map it directly what we did before;
- (maptype 1) if there are more compressed pages + no need to
copy inplace I/O, vmap such compressed pages instead;
- (maptype 2) if inplace I/O needs to be copied, use per-CPU
buffers for decompression then.
Another thing is how to detect inplace decompression is feasable or
not (it's still quite easy for non big pclusters), apart from the
inplace margin calculation, inplace I/O page reusing order is also
needed to be considered for each compressed page. Currently, if the
compressed page is the xth page, it shouldn't be reused as [0 ...
nrpages_out - nrpages_in + x], otherwise a full copy will be triggered.
Although there are some extra optimization ideas for this, I'd like
to make big pcluster work correctly first and obviously it can be
further optimized later since it has nothing with the on-disk format
at all.
Link: https://lore.kernel.org/r/20210407043927.10623-10-xiang@kernel.org
Acked-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Gao Xiang <hsiangkao@redhat.com>
2021-04-07 07:39:26 +03:00
|
|
|
if (IS_ERR(src))
|
|
|
|
return PTR_ERR(src);
|
2019-06-24 10:22:55 +03:00
|
|
|
|
2020-02-26 11:10:07 +03:00
|
|
|
/* legacy format could compress extra data in a pcluster. */
|
|
|
|
if (rq->partial_decoding || !support_0padding)
|
|
|
|
ret = LZ4_decompress_safe_partial(src + inputmargin, out,
|
erofs: support decompress big pcluster for lz4 backend
Prior to big pcluster, there was only one compressed page so it'd
easy to map this. However, when big pcluster is enabled, more work
needs to be done to handle multiple compressed pages. In detail,
- (maptype 0) if there is only one compressed page + no need
to copy inplace I/O, just map it directly what we did before;
- (maptype 1) if there are more compressed pages + no need to
copy inplace I/O, vmap such compressed pages instead;
- (maptype 2) if inplace I/O needs to be copied, use per-CPU
buffers for decompression then.
Another thing is how to detect inplace decompression is feasable or
not (it's still quite easy for non big pclusters), apart from the
inplace margin calculation, inplace I/O page reusing order is also
needed to be considered for each compressed page. Currently, if the
compressed page is the xth page, it shouldn't be reused as [0 ...
nrpages_out - nrpages_in + x], otherwise a full copy will be triggered.
Although there are some extra optimization ideas for this, I'd like
to make big pcluster work correctly first and obviously it can be
further optimized later since it has nothing with the on-disk format
at all.
Link: https://lore.kernel.org/r/20210407043927.10623-10-xiang@kernel.org
Acked-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Gao Xiang <hsiangkao@redhat.com>
2021-04-07 07:39:26 +03:00
|
|
|
rq->inputsize, rq->outputsize, rq->outputsize);
|
2020-02-26 11:10:07 +03:00
|
|
|
else
|
|
|
|
ret = LZ4_decompress_safe(src + inputmargin, out,
|
erofs: support decompress big pcluster for lz4 backend
Prior to big pcluster, there was only one compressed page so it'd
easy to map this. However, when big pcluster is enabled, more work
needs to be done to handle multiple compressed pages. In detail,
- (maptype 0) if there is only one compressed page + no need
to copy inplace I/O, just map it directly what we did before;
- (maptype 1) if there are more compressed pages + no need to
copy inplace I/O, vmap such compressed pages instead;
- (maptype 2) if inplace I/O needs to be copied, use per-CPU
buffers for decompression then.
Another thing is how to detect inplace decompression is feasable or
not (it's still quite easy for non big pclusters), apart from the
inplace margin calculation, inplace I/O page reusing order is also
needed to be considered for each compressed page. Currently, if the
compressed page is the xth page, it shouldn't be reused as [0 ...
nrpages_out - nrpages_in + x], otherwise a full copy will be triggered.
Although there are some extra optimization ideas for this, I'd like
to make big pcluster work correctly first and obviously it can be
further optimized later since it has nothing with the on-disk format
at all.
Link: https://lore.kernel.org/r/20210407043927.10623-10-xiang@kernel.org
Acked-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Gao Xiang <hsiangkao@redhat.com>
2021-04-07 07:39:26 +03:00
|
|
|
rq->inputsize, rq->outputsize);
|
2020-02-26 11:10:07 +03:00
|
|
|
|
2020-02-26 11:10:08 +03:00
|
|
|
if (ret != rq->outputsize) {
|
|
|
|
erofs_err(rq->sb, "failed to decompress %d in[%u, %u] out[%u]",
|
erofs: support decompress big pcluster for lz4 backend
Prior to big pcluster, there was only one compressed page so it'd
easy to map this. However, when big pcluster is enabled, more work
needs to be done to handle multiple compressed pages. In detail,
- (maptype 0) if there is only one compressed page + no need
to copy inplace I/O, just map it directly what we did before;
- (maptype 1) if there are more compressed pages + no need to
copy inplace I/O, vmap such compressed pages instead;
- (maptype 2) if inplace I/O needs to be copied, use per-CPU
buffers for decompression then.
Another thing is how to detect inplace decompression is feasable or
not (it's still quite easy for non big pclusters), apart from the
inplace margin calculation, inplace I/O page reusing order is also
needed to be considered for each compressed page. Currently, if the
compressed page is the xth page, it shouldn't be reused as [0 ...
nrpages_out - nrpages_in + x], otherwise a full copy will be triggered.
Although there are some extra optimization ideas for this, I'd like
to make big pcluster work correctly first and obviously it can be
further optimized later since it has nothing with the on-disk format
at all.
Link: https://lore.kernel.org/r/20210407043927.10623-10-xiang@kernel.org
Acked-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Gao Xiang <hsiangkao@redhat.com>
2021-04-07 07:39:26 +03:00
|
|
|
ret, rq->inputsize, inputmargin, rq->outputsize);
|
2020-02-26 11:10:08 +03:00
|
|
|
|
2019-06-24 10:22:55 +03:00
|
|
|
print_hex_dump(KERN_DEBUG, "[ in]: ", DUMP_PREFIX_OFFSET,
|
erofs: support decompress big pcluster for lz4 backend
Prior to big pcluster, there was only one compressed page so it'd
easy to map this. However, when big pcluster is enabled, more work
needs to be done to handle multiple compressed pages. In detail,
- (maptype 0) if there is only one compressed page + no need
to copy inplace I/O, just map it directly what we did before;
- (maptype 1) if there are more compressed pages + no need to
copy inplace I/O, vmap such compressed pages instead;
- (maptype 2) if inplace I/O needs to be copied, use per-CPU
buffers for decompression then.
Another thing is how to detect inplace decompression is feasable or
not (it's still quite easy for non big pclusters), apart from the
inplace margin calculation, inplace I/O page reusing order is also
needed to be considered for each compressed page. Currently, if the
compressed page is the xth page, it shouldn't be reused as [0 ...
nrpages_out - nrpages_in + x], otherwise a full copy will be triggered.
Although there are some extra optimization ideas for this, I'd like
to make big pcluster work correctly first and obviously it can be
further optimized later since it has nothing with the on-disk format
at all.
Link: https://lore.kernel.org/r/20210407043927.10623-10-xiang@kernel.org
Acked-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Gao Xiang <hsiangkao@redhat.com>
2021-04-07 07:39:26 +03:00
|
|
|
16, 1, src + inputmargin, rq->inputsize, true);
|
2019-06-24 10:22:55 +03:00
|
|
|
print_hex_dump(KERN_DEBUG, "[out]: ", DUMP_PREFIX_OFFSET,
|
|
|
|
16, 1, out, rq->outputsize, true);
|
2020-02-26 11:10:08 +03:00
|
|
|
|
|
|
|
if (ret >= 0)
|
|
|
|
memset(out + ret, 0, rq->outputsize - ret);
|
2019-06-24 10:22:55 +03:00
|
|
|
ret = -EIO;
|
2021-10-14 09:57:44 +03:00
|
|
|
} else {
|
|
|
|
ret = 0;
|
2019-06-24 10:22:55 +03:00
|
|
|
}
|
|
|
|
|
erofs: support decompress big pcluster for lz4 backend
Prior to big pcluster, there was only one compressed page so it'd
easy to map this. However, when big pcluster is enabled, more work
needs to be done to handle multiple compressed pages. In detail,
- (maptype 0) if there is only one compressed page + no need
to copy inplace I/O, just map it directly what we did before;
- (maptype 1) if there are more compressed pages + no need to
copy inplace I/O, vmap such compressed pages instead;
- (maptype 2) if inplace I/O needs to be copied, use per-CPU
buffers for decompression then.
Another thing is how to detect inplace decompression is feasable or
not (it's still quite easy for non big pclusters), apart from the
inplace margin calculation, inplace I/O page reusing order is also
needed to be considered for each compressed page. Currently, if the
compressed page is the xth page, it shouldn't be reused as [0 ...
nrpages_out - nrpages_in + x], otherwise a full copy will be triggered.
Although there are some extra optimization ideas for this, I'd like
to make big pcluster work correctly first and obviously it can be
further optimized later since it has nothing with the on-disk format
at all.
Link: https://lore.kernel.org/r/20210407043927.10623-10-xiang@kernel.org
Acked-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Gao Xiang <hsiangkao@redhat.com>
2021-04-07 07:39:26 +03:00
|
|
|
if (maptype == 0) {
|
2019-06-24 10:22:55 +03:00
|
|
|
kunmap_atomic(src);
|
erofs: support decompress big pcluster for lz4 backend
Prior to big pcluster, there was only one compressed page so it'd
easy to map this. However, when big pcluster is enabled, more work
needs to be done to handle multiple compressed pages. In detail,
- (maptype 0) if there is only one compressed page + no need
to copy inplace I/O, just map it directly what we did before;
- (maptype 1) if there are more compressed pages + no need to
copy inplace I/O, vmap such compressed pages instead;
- (maptype 2) if inplace I/O needs to be copied, use per-CPU
buffers for decompression then.
Another thing is how to detect inplace decompression is feasable or
not (it's still quite easy for non big pclusters), apart from the
inplace margin calculation, inplace I/O page reusing order is also
needed to be considered for each compressed page. Currently, if the
compressed page is the xth page, it shouldn't be reused as [0 ...
nrpages_out - nrpages_in + x], otherwise a full copy will be triggered.
Although there are some extra optimization ideas for this, I'd like
to make big pcluster work correctly first and obviously it can be
further optimized later since it has nothing with the on-disk format
at all.
Link: https://lore.kernel.org/r/20210407043927.10623-10-xiang@kernel.org
Acked-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Gao Xiang <hsiangkao@redhat.com>
2021-04-07 07:39:26 +03:00
|
|
|
} else if (maptype == 1) {
|
|
|
|
vm_unmap_ram(src, PAGE_ALIGN(rq->inputsize) >> PAGE_SHIFT);
|
|
|
|
} else if (maptype == 2) {
|
|
|
|
erofs_put_pcpubuf(src);
|
|
|
|
} else {
|
|
|
|
DBG_BUGON(1);
|
|
|
|
return -EFAULT;
|
|
|
|
}
|
2019-06-24 10:22:55 +03:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2021-10-11 00:31:44 +03:00
|
|
|
static int z_erofs_lz4_decompress(struct z_erofs_decompress_req *rq,
|
2021-10-22 12:01:20 +03:00
|
|
|
struct page **pagepool)
|
2019-06-24 10:22:55 +03:00
|
|
|
{
|
|
|
|
const unsigned int nrpages_out =
|
|
|
|
PAGE_ALIGN(rq->pageofs_out + rq->outputsize) >> PAGE_SHIFT;
|
|
|
|
unsigned int dst_maptype;
|
|
|
|
void *dst;
|
erofs: support decompress big pcluster for lz4 backend
Prior to big pcluster, there was only one compressed page so it'd
easy to map this. However, when big pcluster is enabled, more work
needs to be done to handle multiple compressed pages. In detail,
- (maptype 0) if there is only one compressed page + no need
to copy inplace I/O, just map it directly what we did before;
- (maptype 1) if there are more compressed pages + no need to
copy inplace I/O, vmap such compressed pages instead;
- (maptype 2) if inplace I/O needs to be copied, use per-CPU
buffers for decompression then.
Another thing is how to detect inplace decompression is feasable or
not (it's still quite easy for non big pclusters), apart from the
inplace margin calculation, inplace I/O page reusing order is also
needed to be considered for each compressed page. Currently, if the
compressed page is the xth page, it shouldn't be reused as [0 ...
nrpages_out - nrpages_in + x], otherwise a full copy will be triggered.
Although there are some extra optimization ideas for this, I'd like
to make big pcluster work correctly first and obviously it can be
further optimized later since it has nothing with the on-disk format
at all.
Link: https://lore.kernel.org/r/20210407043927.10623-10-xiang@kernel.org
Acked-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Gao Xiang <hsiangkao@redhat.com>
2021-04-07 07:39:26 +03:00
|
|
|
int ret;
|
2019-06-24 10:22:55 +03:00
|
|
|
|
2021-10-14 09:57:44 +03:00
|
|
|
/* one optimized fast path only for non bigpcluster cases yet */
|
|
|
|
if (rq->inputsize <= PAGE_SIZE && nrpages_out == 1 && !rq->inplace_io) {
|
|
|
|
DBG_BUGON(!*rq->out);
|
|
|
|
dst = kmap_atomic(*rq->out);
|
|
|
|
dst_maptype = 0;
|
|
|
|
goto dstmap_out;
|
2019-06-24 10:22:55 +03:00
|
|
|
}
|
|
|
|
|
erofs: support decompress big pcluster for lz4 backend
Prior to big pcluster, there was only one compressed page so it'd
easy to map this. However, when big pcluster is enabled, more work
needs to be done to handle multiple compressed pages. In detail,
- (maptype 0) if there is only one compressed page + no need
to copy inplace I/O, just map it directly what we did before;
- (maptype 1) if there are more compressed pages + no need to
copy inplace I/O, vmap such compressed pages instead;
- (maptype 2) if inplace I/O needs to be copied, use per-CPU
buffers for decompression then.
Another thing is how to detect inplace decompression is feasable or
not (it's still quite easy for non big pclusters), apart from the
inplace margin calculation, inplace I/O page reusing order is also
needed to be considered for each compressed page. Currently, if the
compressed page is the xth page, it shouldn't be reused as [0 ...
nrpages_out - nrpages_in + x], otherwise a full copy will be triggered.
Although there are some extra optimization ideas for this, I'd like
to make big pcluster work correctly first and obviously it can be
further optimized later since it has nothing with the on-disk format
at all.
Link: https://lore.kernel.org/r/20210407043927.10623-10-xiang@kernel.org
Acked-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Gao Xiang <hsiangkao@redhat.com>
2021-04-07 07:39:26 +03:00
|
|
|
/* general decoding path which can be used for all cases */
|
2021-10-11 00:31:44 +03:00
|
|
|
ret = z_erofs_lz4_prepare_dstpages(rq, pagepool);
|
erofs: support decompress big pcluster for lz4 backend
Prior to big pcluster, there was only one compressed page so it'd
easy to map this. However, when big pcluster is enabled, more work
needs to be done to handle multiple compressed pages. In detail,
- (maptype 0) if there is only one compressed page + no need
to copy inplace I/O, just map it directly what we did before;
- (maptype 1) if there are more compressed pages + no need to
copy inplace I/O, vmap such compressed pages instead;
- (maptype 2) if inplace I/O needs to be copied, use per-CPU
buffers for decompression then.
Another thing is how to detect inplace decompression is feasable or
not (it's still quite easy for non big pclusters), apart from the
inplace margin calculation, inplace I/O page reusing order is also
needed to be considered for each compressed page. Currently, if the
compressed page is the xth page, it shouldn't be reused as [0 ...
nrpages_out - nrpages_in + x], otherwise a full copy will be triggered.
Although there are some extra optimization ideas for this, I'd like
to make big pcluster work correctly first and obviously it can be
further optimized later since it has nothing with the on-disk format
at all.
Link: https://lore.kernel.org/r/20210407043927.10623-10-xiang@kernel.org
Acked-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Gao Xiang <hsiangkao@redhat.com>
2021-04-07 07:39:26 +03:00
|
|
|
if (ret < 0)
|
2019-06-24 10:22:55 +03:00
|
|
|
return ret;
|
erofs: support decompress big pcluster for lz4 backend
Prior to big pcluster, there was only one compressed page so it'd
easy to map this. However, when big pcluster is enabled, more work
needs to be done to handle multiple compressed pages. In detail,
- (maptype 0) if there is only one compressed page + no need
to copy inplace I/O, just map it directly what we did before;
- (maptype 1) if there are more compressed pages + no need to
copy inplace I/O, vmap such compressed pages instead;
- (maptype 2) if inplace I/O needs to be copied, use per-CPU
buffers for decompression then.
Another thing is how to detect inplace decompression is feasable or
not (it's still quite easy for non big pclusters), apart from the
inplace margin calculation, inplace I/O page reusing order is also
needed to be considered for each compressed page. Currently, if the
compressed page is the xth page, it shouldn't be reused as [0 ...
nrpages_out - nrpages_in + x], otherwise a full copy will be triggered.
Although there are some extra optimization ideas for this, I'd like
to make big pcluster work correctly first and obviously it can be
further optimized later since it has nothing with the on-disk format
at all.
Link: https://lore.kernel.org/r/20210407043927.10623-10-xiang@kernel.org
Acked-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Gao Xiang <hsiangkao@redhat.com>
2021-04-07 07:39:26 +03:00
|
|
|
if (ret) {
|
2019-06-24 10:22:55 +03:00
|
|
|
dst = page_address(*rq->out);
|
|
|
|
dst_maptype = 1;
|
|
|
|
goto dstmap_out;
|
|
|
|
}
|
|
|
|
|
erofs: support decompress big pcluster for lz4 backend
Prior to big pcluster, there was only one compressed page so it'd
easy to map this. However, when big pcluster is enabled, more work
needs to be done to handle multiple compressed pages. In detail,
- (maptype 0) if there is only one compressed page + no need
to copy inplace I/O, just map it directly what we did before;
- (maptype 1) if there are more compressed pages + no need to
copy inplace I/O, vmap such compressed pages instead;
- (maptype 2) if inplace I/O needs to be copied, use per-CPU
buffers for decompression then.
Another thing is how to detect inplace decompression is feasable or
not (it's still quite easy for non big pclusters), apart from the
inplace margin calculation, inplace I/O page reusing order is also
needed to be considered for each compressed page. Currently, if the
compressed page is the xth page, it shouldn't be reused as [0 ...
nrpages_out - nrpages_in + x], otherwise a full copy will be triggered.
Although there are some extra optimization ideas for this, I'd like
to make big pcluster work correctly first and obviously it can be
further optimized later since it has nothing with the on-disk format
at all.
Link: https://lore.kernel.org/r/20210407043927.10623-10-xiang@kernel.org
Acked-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Gao Xiang <hsiangkao@redhat.com>
2021-04-07 07:39:26 +03:00
|
|
|
dst = erofs_vm_map_ram(rq->out, nrpages_out);
|
2019-06-24 10:22:55 +03:00
|
|
|
if (!dst)
|
|
|
|
return -ENOMEM;
|
|
|
|
dst_maptype = 2;
|
|
|
|
|
|
|
|
dstmap_out:
|
2021-10-11 00:31:44 +03:00
|
|
|
ret = z_erofs_lz4_decompress_mem(rq, dst + rq->pageofs_out);
|
2019-06-24 10:22:55 +03:00
|
|
|
|
|
|
|
if (!dst_maptype)
|
|
|
|
kunmap_atomic(dst);
|
|
|
|
else if (dst_maptype == 2)
|
2019-09-04 05:09:07 +03:00
|
|
|
vm_unmap_ram(dst, nrpages_out);
|
2019-06-24 10:22:55 +03:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2021-10-11 00:31:44 +03:00
|
|
|
static int z_erofs_shifted_transform(struct z_erofs_decompress_req *rq,
|
2021-10-22 12:01:20 +03:00
|
|
|
struct page **pagepool)
|
2019-06-24 10:22:55 +03:00
|
|
|
{
|
|
|
|
const unsigned int nrpages_out =
|
|
|
|
PAGE_ALIGN(rq->pageofs_out + rq->outputsize) >> PAGE_SHIFT;
|
|
|
|
const unsigned int righthalf = PAGE_SIZE - rq->pageofs_out;
|
|
|
|
unsigned char *src, *dst;
|
|
|
|
|
|
|
|
if (nrpages_out > 2) {
|
|
|
|
DBG_BUGON(1);
|
|
|
|
return -EIO;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (rq->out[0] == *rq->in) {
|
|
|
|
DBG_BUGON(nrpages_out != 1);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
src = kmap_atomic(*rq->in);
|
2020-01-07 05:25:46 +03:00
|
|
|
if (rq->out[0]) {
|
2019-06-24 10:22:55 +03:00
|
|
|
dst = kmap_atomic(rq->out[0]);
|
|
|
|
memcpy(dst + rq->pageofs_out, src, righthalf);
|
2020-01-07 05:25:46 +03:00
|
|
|
kunmap_atomic(dst);
|
2019-06-24 10:22:55 +03:00
|
|
|
}
|
|
|
|
|
2020-01-07 05:25:46 +03:00
|
|
|
if (nrpages_out == 2) {
|
2019-06-24 10:22:55 +03:00
|
|
|
DBG_BUGON(!rq->out[1]);
|
2020-01-07 05:25:46 +03:00
|
|
|
if (rq->out[1] == *rq->in) {
|
|
|
|
memmove(src, src + righthalf, rq->pageofs_out);
|
|
|
|
} else {
|
|
|
|
dst = kmap_atomic(rq->out[1]);
|
|
|
|
memcpy(dst, src + righthalf, rq->pageofs_out);
|
|
|
|
kunmap_atomic(dst);
|
|
|
|
}
|
2019-06-24 10:22:55 +03:00
|
|
|
}
|
|
|
|
kunmap_atomic(src);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2021-10-11 00:31:44 +03:00
|
|
|
static struct z_erofs_decompressor decompressors[] = {
|
|
|
|
[Z_EROFS_COMPRESSION_SHIFTED] = {
|
|
|
|
.decompress = z_erofs_shifted_transform,
|
|
|
|
.name = "shifted"
|
|
|
|
},
|
|
|
|
[Z_EROFS_COMPRESSION_LZ4] = {
|
|
|
|
.decompress = z_erofs_lz4_decompress,
|
|
|
|
.name = "lz4"
|
|
|
|
},
|
2021-10-11 00:31:45 +03:00
|
|
|
#ifdef CONFIG_EROFS_FS_ZIP_LZMA
|
|
|
|
[Z_EROFS_COMPRESSION_LZMA] = {
|
|
|
|
.decompress = z_erofs_lzma_decompress,
|
|
|
|
.name = "lzma"
|
|
|
|
},
|
|
|
|
#endif
|
2021-10-11 00:31:44 +03:00
|
|
|
};
|
|
|
|
|
2019-06-24 10:22:55 +03:00
|
|
|
int z_erofs_decompress(struct z_erofs_decompress_req *rq,
|
2021-10-22 12:01:20 +03:00
|
|
|
struct page **pagepool)
|
2019-06-24 10:22:55 +03:00
|
|
|
{
|
2021-10-11 00:31:44 +03:00
|
|
|
return decompressors[rq->alg].decompress(rq, pagepool);
|
2019-06-24 10:22:55 +03:00
|
|
|
}
|