From nobody Mon Jan 01 16:14:45 2024 X-Original-To: bugs@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T3gzp05ynz571gy for ; Mon, 1 Jan 2024 16:14:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4T3gzn4vTBz4vgB for ; Mon, 1 Jan 2024 16:14:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1704125685; a=rsa-sha256; cv=none; b=HcCkkRG5WDfMIs5Y8rXN61xvQNANBe4YXZQwlKL/F9MjsH6VBVyHB85yQhjq/mLWfTXOsa 94oDgpamFdMM3QY0YknH9/L0c7pTg5gPpAciDGKD29gr8e72uA7m7VDM0rBMzJPEIk2xNt s4k+WBUX7OCuds+Z7MEpXrW/xYN40uOEovTcuX8hS77nu5J54TkCz/uo1dtSXc2CFN1DcH ZeSWW6FZxarjPGIswhl4SIX+gFOv4yzg4oGJDFRrgtOCnShOg31YEvijILERde6OEN8Wd1 9N2r7J4xp9mYw1TttV09EEo70HWdsbP8/uhaHjE9v9MnbhWcFFqALkMPB7l3KA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1704125685; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=i9fkH3ikazJGeoODYY9EGDtK0rl37Gq8TFvU64U1Hbs=; b=wYTNN8aE94ZBpUGaGRLUSMusTMzqqfyqqvb4EkVDmtwhvdjw0IEyVFTMR7yyfAlEWEwwG2 PVnlSEXgW1j8FuNeUGJoQICGHcHblEp0dYtrZ8k9broxjJzPMZLWQsTkgMD52+kGzs0wGi T74gjErYmD1qi4ksAgU5P/VVhB/sUZ7cIt/lrZrwgb3OYeYvimgWup/sT+bXWu66ZfIaSM TGwBMcSzdhuIsKgDZ+s27f35QzKfsVc4Ov6BeAuSykb+SWP5s/GhDHb8EwRvxEOiaUjvMx PX8a5AyTyE+rAM5lkLq2CWTMHqXrVrY9UDPrkLUJdJ8P29yKnsbKt1pXT2ynNg== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4T3gzn3z0Rz8p4 for ; Mon, 1 Jan 2024 16:14:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 401GEjac081119 for ; Mon, 1 Jan 2024 16:14:45 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 401GEj2p081118 for bugs@FreeBSD.org; Mon, 1 Jan 2024 16:14:45 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 276057] crash in xa_destroy() while initializing the i915kms module Date: Mon, 01 Jan 2024 16:14:45 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 14.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: donn@xmission.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Bug reports List-Archive: https://lists.freebsd.org/archives/freebsd-bugs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-bugs@freebsd.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D276057 Bug ID: 276057 Summary: crash in xa_destroy() while initializing the i915kms module Product: Base System Version: 14.0-RELEASE Hardware: amd64 OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: donn@xmission.com While trying to get Xorg graphics to work on my Alder Lake P laptop with FreeBSD 14 RELEASE, I hit a problem where loading the i915kms module appear= ed to cause the system to hang. I searched for reports about this problem and found a discussion at https://github.com/freebsd/drm-kmod/issues/252. I did eventually get graphics to work, but it required a small kernel change; I m= ade a comment (as @hirairaka5) in the github thread to let people know what I h= ad to do. I'm reporting the kernel issue here. There's a fairly obvious bug in the xarray (re-)implementation in linuxkpi that causes a kernel segfault in i19= 5kms (from drm-515-kmod). There are a number of ways to fix it; I picked a simp= le one. Here is my local git commit for the fix, with the details: commit 31fc171e7ff77dfa01df39a0598b167fbd6a24bf (HEAD -> xarray-2) Author: Donn Seeley Date: Mon Jan 1 08:56:08 2024 -0700 xa_destroy: leave the xarray re-usable, like Linux does When trying to get graphics to work on an Alder Lake P laptop, I got a crash. I copied down the information from ddb: --- trap 0xc, rip=3D0xffffffff80b302ec, rsp=3D0xfffffe013acf44e0 ... __mtx_lock_sleep() at __mtx_lock_sleep+0xbc xa_load() at xa_load+0x73 guc_lrc_desc_pin() at guc_lrc_desc_pin+0x49 intel_guc_submission_enable() at intel_guc_submission_enable+0x7d __uc_init_hw() at __uc_init_hw+0x46f intel_gt_init_hw() at intel_gt_init_hw+0x481 intel_gt_resume() at intel_gt_resume+0x5cc intel_gt_init() at intel_gt_init+0x213 i915_gem_init() at i915_gem_init+0x92 i915_driver_probe() at i915_driver_probe+0x40 i915_pci_probe() at i915_pci_probe+0x40 linux_pci_attach_device() at linux_pci_attach_device+0x420 device_attach() at device_attach+0x3be bus_generic_driver_added() at bus_generic_driver_added+0xa1 [etc.] We got a segfault in __mtx_lock_sleep() when trying to dereference a null thread pointer. The sequence of events looks like this: intel_guc_submission_enable(guc) guc_init_lrc_mapping(guc) xa_destroy(&guc->context_lookup) mtx_destroy(&xa->mtx) _mtx_destroy(&(m)->mtx_lock) m->mtx_lock =3D MTX_DESTROYED guc_kernel_context_pin(guc, ce) guc_lrc_desc_pin(guc, loop=3Dtrue) lrc_desc_registered(guc, id) __get_context(guc, id) xa_load(xa=3D&guc->context_lookup, index=3Did) xa_lock(xa) mtx_lock(&(xa)->mtx) mtx_lock_flags((m), 0) _mtx_lock_flags((m), (opts), (file), (line)) __mtx_lock_flags(&(m)->mtx_lock, o, f, l) _mtx_obtain_lock_fetch(m, &v, tid) atomic_fcmpset_acq_ptr(&(mp)->mtx_lock, vp, (tid)) _mtx_lock_sleep(m, v, opts, file, line) __mtx_lock_sleep(&(m)->mtx_lock, v) owner =3D lv_mtx_owner(v) ((struct thread *)((v) & ~MTX_FLAGMASK)) TD_IS_RUNNING(owner) TD_GET_STATE(td) =3D=3D TDS_RUNNING (td)->td_state We crash because v =3D=3D MTX_DESTROYED, which means that td, the thread pointer part of the owner cookie, is NULL and we can't dereference it. The Linux version of xa_destroy() is careful to fix up the xarray so that it can be used again. The FreeBSD version is simpler: we just need to maintain the xarray flags when we reinitialize the xarray structure. diff --git a/sys/compat/linuxkpi/common/src/linux_xarray.c b/sys/compat/linuxkpi/common/src/linux_xarray.c index 44900666242f..856a67ba7e3c 100644 --- a/sys/compat/linuxkpi/common/src/linux_xarray.c +++ b/sys/compat/linuxkpi/common/src/linux_xarray.c @@ -352,6 +352,9 @@ xa_destroy(struct xarray *xa) radix_tree_for_each_slot(ppslot, &xa->root, &iter, 0) radix_tree_iter_delete(&xa->root, &iter, ppslot); mtx_destroy(&xa->mtx); + + /* Linux leaves the xarray re-usable after xa_destroy(). */ + xa_init_flags(xa, xa->flags); } /* --=20 You are receiving this mail because: You are the assignee for the bug.=