Bug 214839
| Summary: | [bug] [arm] Null pointer dereference in btrfs compression code on ARM 32-bit. | ||
|---|---|---|---|
| Product: | File System | Reporter: | System Error (systemerror) |
| Component: | btrfs | Assignee: | BTRFS virtual assignee (fs_btrfs) |
| Status: | RESOLVED CODE_FIX | ||
| Severity: | high | CC: | dsterba |
| Priority: | P1 | ||
| Hardware: | ARM | ||
| OS: | Linux | ||
| URL: | https://paste.debian.net/1216460/ | ||
| Kernel Version: | 5.15-rc7 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
|
Description
System Error
2021-10-27 01:57:16 UTC
NB: disregard kernel version in log - byproduct of bisecting and going some pre-5.15-rc1 commits. Bug definitely tested to exist up to 5.15-rc6 Thanks for the report. This is most likely caused by my patches removing kmap calls. This affects 32bit architectures with enabled HIGHMEM. There was another report https://lore.kernel.org/all/CAJCQCtT+OuemovPO7GZk8Y8=qtOObr0XTDp8jh4OHD6y84AFxw@mail.gmail.com/ I'll send a revert as it's still in unreleased 5.15-rc. I've got similar impression as bisect revolved all around these and after of couple of experiments I've got same very thing in LZO so bisect found where it finally became in effect in my config but real issue apparently happened before. Thanks, fix would be really appreciated as it kinda breaks btrfs on 5.15 for me and otherwise I'd had to skip 5.15 on at least ARM32 targets (maybe others, arms were first where it surfaced upon giving -rc a try). And in the end btrfs is really nice thing, I'll be sad if some users would get other impression. Yeah, though intel 32bit is almost extinct nowadays, the 32bit ARM machines are not and used for low power storage boxes. A fix would have to be merged either way, pre 5.15 or after release via stable trees but potentially causing more damage. I see revert arrived and I've tested it (as of a379fbbcb88bcf43d886977c6fb91fb43f330b84 commit). It has corrected problem, thanks! Yay! On side note, btrfs got strong points even beyond "storage boxes". For example, DUP storage scheme improves chances system would complete boot even if conditions were imperfect (and fatal for most of other FS) and boot sequence not really assumed there can be more than 1 boot device involved (e.g. booting from SDcard or eMMC). Its very sad state of things when single sporadic bad sector, etc on underlying storage ruins whole boot sequence. Especially in automatic/unsupervised systems. That's where btrfs comes to help: it would usually say "bad csum at XXX, corrected", repairing from another copy and if it repeats often I'd to schedule maintenance, while it still keeps going so its normal course of actions instead of emergency. Way better vs suddenly getting unbootable system, especially if it's been control or automation running unsupervised. Self healing properties of btrfs and lack of fsck proven to be really neat in these cases. And best of all: it easy to get going and flexible (e.g. unlike RAID it not cares of device size, so can be easily grown/shrinked as needed, minimizing OS image after composing it, or expanding FS to full available device size as needed, etc). So I eventually test how upcoming kernels perform. I actually caught it about -rc2 but wasn't sure what it is me got something wrong in kernel configuration or something. Then I've got dragged into few other things, so only got to fullfledged bisect around -rc6 and quickly got idea it revolves around suspicious refactor and likely isn't my fault. I'm sorry for rather late timings. Either way, thanks for fixing. Its nice this bullet has been dodged. I have pleasure to mark this RESOLVED as I can't reproduce in my configs anymore :) |