Open g2p opened 1 month ago
I looked at #658. I did not customize the compression level. Also, it seems like the crash might be an error reading from the source buffer?
Confirmed by looking at objdump -rSl lib/lz4/lz4_compress.o
:
/home/g2p/src/evilpiepirate.org/git/bcachefs/lib/lz4/lz4_compress.c:641
size_t matchLength = LZ4_count(ip + MINMATCH,
1c9c: 48 83 c2 04 add $0x4,%rdx
/home/g2p/src/evilpiepirate.org/git/bcachefs/lib/lz4/lz4_compress.c:637
LZ4_writeLE16(op, (U16)(ip - match)); op += 2;
1ca0: 66 89 46 fe mov %ax,-0x2(%rsi)
LZ4_count():
/home/g2p/src/evilpiepirate.org/git/bcachefs/lib/lz4/lz4defs.h:202 (discriminator 1)
while (likely(pIn < pInLimit - (STEPSIZE - 1))) {
1ca4: 4c 89 f0 mov %r14,%rax
1ca7: 4d 39 ce cmp %r9,%r14
1caa: 0f 83 28 01 00 00 jae 1dd8 <LZ4_compress_destSize_generic+0x488>
LZ4_read_ARCH():
/home/g2p/src/evilpiepirate.org/git/bcachefs/lib/lz4/lz4defs.h:119
return get_unaligned((const size_t *)ptr);
1cb0: 48 8b 3a mov (%rdx),%rdi
1cb3: 4c 8b 38 mov (%rax),%r15
Where the bad address is in %rdx according to decodecode:
Code: 60 02 00 00 41 c6 00 00 48 89 c8 4c 8d 71 04 48 83 c6 02 48 29 d0 48 83 c2 04 66 89 46 fe 4c 89 f0 4d 39 ce 0f 83 28 01 00 00 <48> 8b12:21:46 [1/873]
39 ff 0f 84 08 01 00 00 4c 31 ff f3 48 0f bc
All code
========
0: 60 (bad)
1: 02 00 add (%rax),%al
3: 00 41 c6 add %al,-0x3a(%rcx)
6: 00 00 add %al,(%rax)
8: 48 89 c8 mov %rcx,%rax
b: 4c 8d 71 04 lea 0x4(%rcx),%r14
f: 48 83 c6 02 add $0x2,%rsi
13: 48 29 d0 sub %rdx,%rax
16: 48 83 c2 04 add $0x4,%rdx
1a: 66 89 46 fe mov %ax,-0x2(%rsi)
1e: 4c 89 f0 mov %r14,%rax
21: 4d 39 ce cmp %r9,%r14
24: 0f 83 28 01 00 00 jae 0x152
2a:* 48 8b 3a mov (%rdx),%rdi <-- trapping instruction
2d: 4c 8b 38 mov (%rax),%r15
30: 4c 39 ff cmp %r15,%rdi
33: 0f 84 08 01 00 00 je 0x141
39: 4c 31 ff xor %r15,%rdi
3c: f3 repz
3d: 48 rex.W
3e: 0f .byte 0xf
3f: bc .byte 0xbc
From a quick grep bcachefs is the only user of LZ4_compress_destSize. Quite possibly the bug is in the in-kernel LZ4 library; it was updated last to upstream LZ4 1.8.3 in 2018 which has known bugs (documented upstream).
We can switch away from LZ4_compress_destsize as a workaround if we really need to
The kernel is the same as for #708, d11e1164d85f6d6e08942edc0f5d14f9e9c6a8a0 rebased over linus/master (e091caf99f3a5006c95baec24330bac6f7f17193).
lz4 is used for foreground compression.
With scripts/decode_stacktrace.sh: