Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <CAHk-=wjB5XBk4obhMPfrU3mnOakV9VgHAYOo-ZGJnB2X0DnBWA@mail.gmail.com>
 <a9473821-1d53-0037-7590-aeaf8e85e72a@jonmasters.org>
In-Reply-To: <a9473821-1d53-0037-7590-aeaf8e85e72a@jonmasters.org>
From:   Linus Torvalds <torvalds@linux-foundation.org>
Date:   Mon, 12 Jul 2021 12:14:24 -0700
Message-ID: <CAHk-=wh0mRAyL9GNVjhw2ki7vRevvUnovCzawn2FO7e_dOfU-w@mail.gmail.com>
Subject: Re: Linux 5.14-rc1
To:     Jon Masters <jcm@jonmasters.org>,
        =?UTF-8?Q?Christian_K=C3=B6nig?= <christian.koenig@amd.com>,
        Matthew Auld <matthew.auld@intel.com>
Cc:     Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        dri-devel <dri-devel@lists.freedesktop.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Mon, Jul 12, 2021 at 12:08 AM Jon Masters <jcm@jonmasters.org> wrote:
>
> I happened to be installing a Fedora 34 (x86) VM for something and did a
> test kernel compile that hung on boot. Setting up a serial console I get
> the below backtrace from ttm but I have not had chance to look at it.

It's a NULL pointer in qxl_bo_delete_mem_notify(), with the code
disassembling to

  16: 55                    push   %rbp
  17: 48 89 fd              mov    %rdi,%rbp
  1a: e8 a2 02 00 00        callq  0x2c1
  1f: 84 c0                test   %al,%al
  21: 74 0d                je     0x30
  23: 48 8b 85 68 01 00 00 mov    0x168(%rbp),%rax
  2a:* 83 78 10 03          cmpl   $0x3,0x10(%rax) <-- trapping instruction
  2e: 74 02                je     0x32
  30: 5d                    pop    %rbp
  31: c3                    retq

and that "cmpl $3" looks exactly like that

        if (bo->resource->mem_type == TTM_PL_PRIV

and the bug is almost certainly from commit d3116756a710 ("drm/ttm:
rename bo->mem and make it a pointer"), which did

-       if (bo->mem.mem_type == TTM_PL_PRIV ...
+       if (bo->resource->mem_type == TTM_PL_PRIV ...

and claimed "No functional change".

But clearly the "bo->resource" pointer is NULL.

Added guilty parties and dri-devel mailing list.

Christian? Full report at

   https://lore.kernel.org/lkml/a9473821-1d53-0037-7590-aeaf8e85e72a@jonmasters.org/

but there's not a whole lot else there that is interesting except for
the call trace:

  ttm_bo_cleanup_memtype_use+0x22/0x60 [ttm]
  ttm_bo_release+0x1a1/0x300 [ttm]
  ttm_bo_delayed_delete+0x1be/0x220 [ttm]
  ttm_device_delayed_workqueue+0x18/0x40 [ttm]
  process_one_work+0x1ec/0x390
  worker_thread+0x53/0x3e0

so it's presumably the cleanup phase and perhaps "bo->resource" has
been deallocated and cleared?

                  Linus