Date: Tue, 09 May 2023 19:05:02 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 271333] kernel panic 13.2-RELEASE Message-ID: <bug-271333-227-rkJGfB9af9@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-271333-227@https.bugs.freebsd.org/bugzilla/> References: <bug-271333-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D271333 Mark Johnston <markj@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |markj@FreeBSD.org Status|New |Open --- Comment #1 from Mark Johnston <markj@FreeBSD.org> --- Looks like a LinuxKPI bug: - i915_vma_coredump contains an array of pages, freed in __i915_gpu_coredump_free() -> cleanup_gt() -> i915_vma_coredump_free() with for (page =3D 0; page < vma->page_count; page++) free_page((unsigned long)vma->pages[page]); - free_page() just calls FreeBSD's kmem_free(). That is, it expects to rec= eive a page mapped into the kernel map. - Looks like those pages are allocated by pool_alloc() in i915_gpu_error.c.= It uses alloc_page() in the LinuxKPI, which just allocates and returns an unma= pped page. pool_alloc() extracts the direct map address. So, i915kms is passing a direct map address to free_page(), which doesn't handle that. Probably free_page() should handle direct-mapped addresses by resolving them to a page and freeing that with linux_free_pages(page, 0). --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-271333-227-rkJGfB9af9>