Messages in this thread | | | Subject | Re: Linux 5.14-rc1 | From | Christian König <> | Date | Mon, 12 Jul 2021 21:22:40 +0200 |
| |
Hi guys,
Am 12.07.21 um 21:14 schrieb Linus Torvalds: > 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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Flkml%2Fa9473821-1d53-0037-7590-aeaf8e85e72a%40jonmasters.org%2F&data=04%7C01%7Cchristian.koenig%40amd.com%7C06dd885408e84008a9a208d945694d9f%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637617140858341274%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=UlqsiWTjfJZ4%2FeIJJMh1AeCqs5SeFjNG%2F22UiuVAIII%3D&reserved=0 > > 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?
That's a known issue. Fixed by:
commit 3efe180d5105d367ae1dfadb97892ab93a89a783 Author: Christian König <christian.koenig@amd.com> Date: Tue Jul 6 08:51:25 2021 +0200
drm/qxl: add NULL check for bo->resource
When allocations fails that can be NULL now.
Previously the structure was embedded into the buffer object and when allocation failed (or never happened in a temporary buffer) the structure was just zeroed.
Going to double check tomorrow why that hasn't showed up in your tree yet.
Christian.
> > Linus
| |