[Nouveau] Advice about debugging nouveau driver suspend issue (init_on_alloc=1 and init_on_free=1)

[Ilia Mirkin]

On Thu, Oct 14, 2021 at 12:51 PM Computer Enthusiastic
<computer.enthusiastic at gmail.com> 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