Bcachefs crash (Oops) in LZ4HC_compress_generic+0x3b3/0x1b90 #753
Comments
|
UPD: Also for attempt_compress: I find you make call to the lz4 function here: int ret = LZ4_compress_HC(
src, dst, src_len, dst_len,
compression.level,workspace
);And that function crashes on this code: static FORCE_INLINE void LZ4_copy8(void *dst, const void *src) {
#if LZ4_ARCH64 // this was True during kernel build
U64 a = get_unaligned((const U64 *)src);
/* THE CRASH IS HERE -> */ put_unaligned(a, (U64 *)dst);
#else
U32 a = get_unaligned((const U32 *)src);
U32 b = get_unaligned((const U32 *)src + 1);
...Respectively this is #define put_unaligned(val, ptr) __put_unaligned_t(typeof(*(ptr)), (val), (ptr))Respectively, macro "__put_unaligned_t" is finally defined in the same file: #define __put_unaligned_t(type, val, ptr) do { \
struct { type x; } __packed *__pptr = (typeof(__pptr))(ptr); \
__pptr->x = (val); \
} while (0)Here is the exact crashing line: I wasn't able to understand myself why this action randomly faults. |
|
Interesting detail: I still haven't rebooted because the filesystem continues to work! Despite that it's |
|
@koverstreet not fixed |
🥝Kernel: 6.10.0
Hello, developers. Ive just decided to enable compression on a production filesystem because it was critically running out of space. I did it by:
The filesystem was under heavy use at that moment.
bch-rebalancethread became 100% CPU ,I think it means that compression has started.But after less than a minute I got a crash of a kworker process in a workqueue.
I believe that last your function was
attempt_compress+0x205/0x270. Then crash in the lz4 module/code.I don't know if it is your bug, or an issue with configuration. My configuration is this:
Thank you very much!
The filesystem is still up and it accepts reads writes.
bch-rebalanceis also still running at 100%. I don't know if a reboot is required anytime soon. Just the manualsync()calls don't return.The text was updated successfully, but these errors were encountered: