On Sat, 28 Jan 2023 15:26:00 +0100 Borislav Petkov <bp@xxxxxxxxx> wrote: > On Sat, Jan 28, 2023 at 02:55:58PM +0100, Linux kernel regression tracking (Thorsten Leemhuis) wrote: > > On 28.01.23 12:03, Borislav Petkov wrote: > > > On Sat, Jan 28, 2023 at 03:41:50AM +0100, Mirsad Goran Todorovac wrote: > > >> This appears to be a duplicate of the report: > > >> https://lore.kernel.org/linux-mm/2c677d85-820c-d41a-fc98-7d3974b49e42@xxxxxxxxxxxx/raw > > > > > > Yah, looks like > > > > > > 56a61617dd22 ("mm: use stack_depot for recording kmemleak's backtrace") > > > > > > needs to be reverted. > > > > Unless I'm missing something (which might easily be the case) there is a > > patch for that issue in -mm already: > > > > https://lore.kernel.org/all/20230119224022.80752C433F0@xxxxxxxxxxxxxxx/ > > > > Or where two different issues discussed in the thread Mirsad mentioned > > above? > > Probably the same issue. This one fixes the issue on my machine - thanks! > > Tested-by: Borislav Petkov (AMD) <bp@xxxxxxxxx> > OK, thanks, I didn't realize this issue was so serious. I reordered Zhaoyang Huang's series so that "mm: use stack_depot_early_init for kmemleak" comes ahead of "mm: move KMEMLEAK's Kconfig items from lib to mm" and I've staged "mm: use stack_depot_early_init for kmemleak" in the mm-hotfixes branch for upstream merging in this -rc cycle.
