On Thu, Oct 14, 2021 at 12:51 PM Computer Enthusiastic <computer.enthusiastic@xxxxxxxxx> wrote: > > Hello, > > Thanks for the answer. > > On Wed, Oct 13, 2021 at 01:43:56PM -0400, Ilia Mirkin wrote: > > The most straightforward thing, if you can reproduce at will, would be > > to do a bisect to figure out which change this happened with. Once we > > know which change caused the problem, it will hopefully provide with > > more ability to sort out where we're going wrong. You can also play > > with things like KASAN, although it's not clear to me that they would > > necessarily catch this problem. > > The patch is "mm: security: introduce init_on_alloc=1 and init_on_free=1 > boot options" (commit 6471384af2a6530696fc0203bafe4de41a23c9ef) [1]. > > It was introduced in kernel version 5.2: > $ git describe --tags 6471384af2a6530696fc0203bafe4de41a23c9ef > v5.2-5754-g6471384af2a6 Uff... so you've verified that a kernel at that commit + init_on_alloc=1 and init_on_free=1 (or the CONFIG_* equivalents) will cause the problems? That means the problem has "always been there" (or at least we have no great way of knowing when it might have been introduced). I think there's some sort of SLUB debug options that help find use-after-frees and such. What if you disable the init_on_*, enable SLUB, and boot with like "slub_debug=FZP"? -ilia
