On Fri, Nov 05, 2021 at 08:50:04PM +0100, David Sterba wrote: > On Thu, Nov 04, 2021 at 04:37:25PM -0700, Linus Torvalds wrote: > > On Thu, Nov 4, 2021 at 3:09 PM Linus Torvalds > > <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > > If (a) works, but (b) still fails, then it must be some odd > > > interaction issug withs-----ing else. Which sounds unlikely, since I > > > don't think we really had anything that should affect kmap or anything > > > in this area, but who knows... > > > > And bisection ends up perhaps somewhat painful, but sounds like the > > way to go if there's no other path forward. > > Just to give an update, I tested several merge commits and the btrfs > merge is the first bad (037c50bfbeb33b4c). > > Last good is the one right before that, > > 9c6e8d52a7299 Merge tag 'exfat-for-5.16-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/linkinjeon/exfat > (plus the fixup to make it compile e66435936756d9bce) > > The remaining test to do is the merge conflict resolved by me, as you > suggested. So the result is that the merge conflict from Linus resolved the kmaps correctly, there was a bug in the lzo refactoring patch itself that caused some page array overflow and some random address was accessed. I'll send a pull request in a day, I've been validating the patch on the unmerged base and on rc1, also with various debugging options on. Curiously, with SLOB there's an early crash while still doing the compression, but with SLUB (and debugging enabled) there is not an immediate crash but some other warning/assertion notices a page with mapping (unexpected).
