diff mbox

lz4hc compression in UBIFS?

Message ID 106621382627723@web13g.yandex.ru
State New, archived
Headers show

Commit Message

Konstantin Tokarev Oct. 24, 2013, 3:15 p.m. UTC 
24.10.2013, 18:20, "Konstantin Tokarev" <annulen@yandex.ru>:
> 23.10.2013, 22:26, "Yann Collet" <yann.collet.73@gmail.com>:
>
>>  UBIFS error (pid 4288): ubifs_decompress: cannot decompress 12 bytes,
>>  (...)
>>          data size      12
>>          data:
>>          00000000: 1f 00 01 00 ff e8 50 00 00 00 00 00
>>
>>  The compressed format is correct.
>>  It describes a flow of 00, of size ~500.
>>
>>  So the problem seems more likely on the decompression side.
>>
>>  Are you sure you are providing "12" as the "input size" parameter ? and that
>>  the "maximum output size" parameter is correctly provided ? (i.e. >= to
>>  original data size)
>
> Decompression code in kernel[1] is heavily modified. In particular, lz4_uncompress
> function (used in this case) does not have input size parameter at all,
> while it's present in lz4_uncompress_unknownoutputsize.
>
> [1] lib/lz4/lz4_decompress.c

Attached patch to crypto API wrapper for lz4hc seems to fix the issue. I can save
and read files on LZ4HC-compressed volume, and I'm running on LZ4HC-compressed rootfs,
flashed from mkfs.ubifs generated image (patch by Elie De Brauwer). My software
works correctly.

Unfortunately, on my board LZ4HC-compressed UBIFS volume performs noticeable worse
than LZO, while still faster than zlib. I guess the reason is that CPU is no longer a
bottleneck for my system, but NAND speed.

Thank you all for your help!

Comments

Konstantin Tokarev Oct. 28, 2013, 4:22 p.m. UTC | #1 
24.10.2013, 19:15, "Konstantin Tokarev" <annulen@yandex.ru>:
> Attached patch to crypto API wrapper for lz4hc seems to fix the issue. I can save
> and read files on LZ4HC-compressed volume, and I'm running on LZ4HC-compressed rootfs,
> flashed from mkfs.ubifs generated image (patch by Elie De Brauwer). My software
> works correctly.
>
> Unfortunately, on my board LZ4HC-compressed UBIFS volume performs noticeable worse
> than LZO, while still faster than zlib. I guess the reason is that CPU is no longer a
> bottleneck for my system, but NAND speed.
>
> Thank you all for your help!

Can anyone review the correctness of my patch? Looks like API of LZ4 decompressor is
used wrong way in crypto API.
Florian Fainelli Oct. 28, 2013, 4:45 p.m. UTC | #2 
2013/10/28 Konstantin Tokarev <annulen@yandex.ru>:
>
>
> 24.10.2013, 19:15, "Konstantin Tokarev" <annulen@yandex.ru>:
>> Attached patch to crypto API wrapper for lz4hc seems to fix the issue. I can save
>> and read files on LZ4HC-compressed volume, and I'm running on LZ4HC-compressed rootfs,
>> flashed from mkfs.ubifs generated image (patch by Elie De Brauwer). My software
>> works correctly.
>>
>> Unfortunately, on my board LZ4HC-compressed UBIFS volume performs noticeable worse
>> than LZO, while still faster than zlib. I guess the reason is that CPU is no longer a
>> bottleneck for my system, but NAND speed.
>>
>> Thank you all for your help!
>
> Can anyone review the correctness of my patch? Looks like API of LZ4 decompressor is
> used wrong way in crypto API.

Can you make a formal submission of it? That would probably help reviewing it.
--
Florian
diff mbox

Patch

diff --git a/crypto/lz4.c b/crypto/lz4.c
index 4586dd1..91a0613 100644
--- a/crypto/lz4.c
+++ b/crypto/lz4.c
@@ -66,9 +66,8 @@  static int lz4_decompress_crypto(struct crypto_tfm *tfm, const u8 *src,
 {
 	int err;
 	size_t tmp_len = *dlen;
-	size_t __slen = slen;
 
-	err = lz4_decompress(src, &__slen, dst, tmp_len);
+	err = lz4_decompress_unknownoutputsize(src, slen, dst, &tmp_len);
 	if (err < 0)
 		return -EINVAL;
 
diff --git a/crypto/lz4hc.c b/crypto/lz4hc.c
index 151ba31..9987741 100644
--- a/crypto/lz4hc.c
+++ b/crypto/lz4hc.c
@@ -66,9 +66,8 @@  static int lz4hc_decompress_crypto(struct crypto_tfm *tfm, const u8 *src,
 {
 	int err;
 	size_t tmp_len = *dlen;
-	size_t __slen = slen;
 
-	err = lz4_decompress(src, &__slen, dst, tmp_len);
+	err = lz4_decompress_unknownoutputsize(src, slen, dst, &tmp_len);
 	if (err < 0)
 		return -EINVAL;