From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f48.google.com (mail-wm1-f48.google.com [209.85.128.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B2C1C3563F9 for ; Mon, 2 Feb 2026 10:12:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770027158; cv=none; b=Hqt1yHpwYQgRo0OoLzStlx1bUDcN0BaDVi/ytVcjBYmmPapa8liOU26TnHUBsZpjHDjt8z3Br6MS2QzBms/FqUqiFtyKY1miRKBfP39sgiy/AF5+gWSogG5b3NzP2+X7oh8YV2nJCgOWX2FzSRMQF6nGWFSO2o7iNAia75B8gZk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770027158; c=relaxed/simple; bh=mqU7paSKxEd5u2/n51EmU4XiOARYE3ldSyNCAspu198=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=gnO7mBpkGS1StJWTS7ulBqN1dv63KUY7q+354OlX7Z79r5xN2MG5fpDQgYE1KdxPxh0cXNQBR1a7uI3Bgpgy+1k6yczhJBCJvkr2ULqrcfwsyWbc0ZBcmovVDaqbelyRfY7rRD340+MVcWOAtBtuSQFNIeMxz67aWmjMOelT7aQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org; spf=pass smtp.mailfrom=linaro.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b=b83FG9pk; arc=none smtp.client-ip=209.85.128.48 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linaro.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="b83FG9pk" Received: by mail-wm1-f48.google.com with SMTP id 5b1f17b1804b1-4801bc32725so31552895e9.0 for ; Mon, 02 Feb 2026 02:12:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1770027155; x=1770631955; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=u5iMSISoPXHP8cm/BuB1aiphidaUfX1u3Xy0JvO160Q=; b=b83FG9pkGSvHKR8P2k0Htt6klfjwt8JBjAMaWIu5515CriX26H+EZ+2MLeP91rpTU6 dQCPtxRUwmED26jJMmcWC0IDatiRtP2h3iCbruLVeTXbxP5picVV3waiZyshHDjkZF1D zDYAt+DgWHCEUGxXNQD9HAMXLRhXZgKD1rE7qg3JXZfOOJsrvQe+nQo6VM4GzyABjpbM Y6JIKczl8D1YNie3OJ6mkCKQ7zyHNukxNd2AbNZiqhHnSgGFFsoXEFEncfqKwOcTn4cL aqzXfrYq5cYi7DXheRNfYL6VBvTCX1yo3hjLX7dnnA6Ue0B0n0H5BVgZaIYn9EYnlxu+ oT/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770027155; x=1770631955; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=u5iMSISoPXHP8cm/BuB1aiphidaUfX1u3Xy0JvO160Q=; b=iQiF5ED3halcXwz4mtIJxlYZc6CD6iK3uwvhiUmWwoaFXaV5RjAlT0CglxRBgcdVhI LBgDe1+dNmCJ7k1xBCtuXYHLgJw/gh1uKEQCsLwbgCI3U+s5ahvbN2a3+YMNu77+hh5U YKkApxMWZRKtdmzjHIbPofYsBysqQ7/Q1cut7n8eIHDTwksWIkWGLbURycUDp2gHup4P Qc0NIuBJ4Y78dls1Nfhh7CxMQA1XCrjpwODXwhqUNkQfDP1uFL/PoXGmDNFltvlqur9q J/eozc+VUk11Bw46Gn81GJG4C5ZAsZ52hIJRudhzJ1hHI5aSAn2ClIlLpA/Sd2AuI/5K 16rA== X-Forwarded-Encrypted: i=1; AJvYcCVntbdia/cwO8rROi995EgtT98n62KDoJ9VN1ORxUIOLjGN9xsyhh7JBWTPxEOH6ZzOOOz5uu+mPQpMXsM=@vger.kernel.org X-Gm-Message-State: AOJu0YzLSu1q336S9u/Wpu4+i6cyioqvcpDJ1lzyJsYzVexTcxADN/az 0URZvAQCvN1WB9wMAv2zv0tn10iM+lRjnwK3pPnCvTzV4Vx9XXI/zqZBrNPUPvP9wbI= X-Gm-Gg: AZuq6aLtv/buRXLS4XzBz6126vDm+goxlmVMkU+dXPmn8Wtm251WS7hJBYKDoabbvZR yavz7Ple2aGgWzzdVhmkJuezb/lDCQh/KNDuRfmFcrgoy5MgC0b+B2ulGFHP+TQe1WI+C7F7BDw +KiDGZxUPDijBnhqcsWaOwpu274hUDsJfhyA7Tfhz3KtTGA/WxoqnXSBiXpzTWfTyjBK+g1VaJx QHXx4PFd1hVgxRWDAzqHRJHn8KHWQIPUGxlAPupGMqgP5PajFQCK3npkv1JYsWhO0gU89H5xcS5 UiyzbSk95fjda2iwNTiro57T3r72NYhsHaFa1CrTOBK/eSI+r+dazmvmSjeS7VXbkxegNgrBNoq WCXXHNTyb7UXl+R/dkMmrE2/tpL4yiEdD2AonF8/NMBtOmWiobqhVS+DmPuy4L/gfD2cxWz7n/x wMKGe88YuMvGZFrAC0 X-Received: by 2002:a05:600c:5566:b0:482:dbd7:a1c1 with SMTP id 5b1f17b1804b1-482dbd7a308mr90480105e9.34.1770027154676; Mon, 02 Feb 2026 02:12:34 -0800 (PST) Received: from localhost ([196.207.164.177]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4806cdd78d3sm399143985e9.1.2026.02.02.02.12.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Feb 2026 02:12:33 -0800 (PST) Date: Mon, 2 Feb 2026 13:12:30 +0300 From: Dan Carpenter To: Shenghao Yang Cc: Ruben Wauters , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, stable+noautosel@kernel.org, kernel test robot Subject: Re: [PATCH v2] drm/gud: fix NULL crtc dereference on display disable Message-ID: References: <20260201095956.21042-1-me@shenghaoyang.info> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260201095956.21042-1-me@shenghaoyang.info> On Sun, Feb 01, 2026 at 05:59:56PM +0800, Shenghao Yang wrote: > gud_plane_atomic_update() currently handles both crtc state and > framebuffer updates - the complexity has led to a few accidental > NULL pointer dereferences. > > Commit dc2d5ddb193e ("drm/gud: fix NULL fb and crtc dereferences > on USB disconnect") [1] fixed an earlier dereference but planes > can also be disabled in non-hotplug paths (e.g. display disables > via the desktop environment). The drm_dev_enter() call would not > cause an early return in those and subsequently oops on > dereferencing crtc: > > BUG: kernel NULL pointer dereference, address: 00000000000005c8 > CPU: 6 UID: 1000 PID: 3473 Comm: kwin_wayland Not tainted 6.18.2-200.vanilla.gud.fc42.x86_64 #1 PREEMPT(lazy) > RIP: 0010:gud_plane_atomic_update+0x148/0x470 [gud] > > drm_atomic_helper_commit_planes+0x28e/0x310 > drm_atomic_helper_commit_tail+0x2a/0x70 > commit_tail+0xf1/0x150 > drm_atomic_helper_commit+0x13c/0x180 > drm_atomic_commit+0xb1/0xe0 > info ? __pfx___drm_printfn_info+0x10/0x10 > drm_mode_atomic_ioctl+0x70f/0x7c0 > ? __pfx_drm_mode_atomic_ioctl+0x10/0x10 > drm_ioctl_kernel+0xae/0x100 > drm_ioctl+0x2a8/0x550 > ? __pfx_drm_mode_atomic_ioctl+0x10/0x10 > __x64_sys_ioctl+0x97/0xe0 > do_syscall_64+0x7e/0x7f0 > ? __ct_user_enter+0x56/0xd0 > ? do_syscall_64+0x158/0x7f0 > ? __ct_user_enter+0x56/0xd0 > ? do_syscall_64+0x158/0x7f0 > entry_SYSCALL_64_after_hwframe+0x76/0x7e > > Split out crtc handling from gud_plane_atomic_update() into > atomic_enable() and atomic_disable() functions to delegate > crtc state transitioning work to the DRM helpers. > > To preserve the gud state commit sequence [2], switch to > the runtime PM version of drm_atomic_helper_commit_tail() which > ensures that crtcs are enabled (hence sending the > GUD_REQ_SET_CONTROLLER_ENABLE and GUD_REQ_SET_DISPLAY_ENABLE > requests) before a framebuffer update is sent. > > [1] https://lore.kernel.org/all/20251231055039.44266-1-me@shenghaoyang.info/ > [2] https://github.com/notro/gud/wiki/GUD-Protocol#display-state > > Cc: # won't apply cleanly on 6.18.x Why are you adding this? I suspect it's because checkpatch complains that commits with BUG: in the commit message should be CC'd to stable. (Although, I can't trigger that warning now. Weird). If a patch doesn't apply, then the stable scripts aren't going to apply it. It's not necessary to tell the scripts not to try. To me the "noautosel" basically means that it's important to not backport the patch. Maybe the API has changed so backporting it will cause a subtle breakage. Are you planning to manually backport it? If so, you could CC stable and then when you get the email that it doesn't apply, then you can do the manual backport. Or you could ignore it. Or if you think it's not worth backporting, you could explain why. Cc: # too risky for low benefit regards, dan carpenter