From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f49.google.com (mail-wr1-f49.google.com [209.85.221.49]) (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 CE2EE345EC0 for ; Sat, 15 Aug 2026 20:42:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.49 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786826576; cv=none; b=vGiHkhBZyUvnI3/ea0KdC4ayj9JW3YdCul6bczdfRMUy/M1MxyPwd/BkKwaVul2kJuxI8GLyinFrhnoUi87pmCslFfxds9nb89zx5vBJYYvEyM3i1zL2DHQVfs8swlAU2xQsWzfA4RnSwAOc10lgmJ4lhDFyitr1Gm8v/0Uz2Ck= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786826576; c=relaxed/simple; bh=jhB2Br9LpoXj6jJeCXXm3cPp4I/HjCuB+J1fdpjrMlg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: Content-Type:MIME-Version; b=AfoCCfGJE7gQWgVg68X5i2YvpsZZwxhDUrAEHyd8JfvGcPOpnWmeWP/hco2zkGdHfQyymg0pVH6UStjqfElBoHQgSCMOpJDVxg3yI+hHosFWyS+v8Zvq0BgYIQRLyozZVNj1wNnIJkQqGs+cUmx5qf6T98eoiR9GomxYF30cneY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=UsTLmn7q; arc=none smtp.client-ip=209.85.221.49 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="UsTLmn7q" Received: by mail-wr1-f49.google.com with SMTP id ffacd0b85a97d-47df6a5655aso232614f8f.1 for ; Sat, 15 Aug 2026 13:42:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786826573; x=1787431373; darn=vger.kernel.org; h=mime-version:content-transfer-encoding:content-type:references :in-reply-to:message-id:date:subject:cc:to:from:from:to:cc:subject :date:message-id:reply-to:content-type; bh=g3g0AYahBP3aN4rc9/ufJfxyt9G+mfOpDwe9Ft7yd84=; b=UsTLmn7qimYkM/nRmTzIoGwlNo4p2qdGbWaXClzvwcPxtZE4qKFny4EhTer0sp9JMX L4YwTsVzYIRlcFtWsm/yQfGaAUWi06ErWPPxHtcePCrL1XsmECMgdIV9qId03nG4rSFa /eLMws2ShTxK56GzhdN+SVFv8eSlAy+YQrW0UwdZqbU+ZUlTpe8djWNfHCxSBNIeUskq SDB9ZB004oldYKCrEt7GP5TtxLaXQTUHkRIbluxTKO89eCoLXE8LVLKGGPcl/iyHGUyL 8WWn/iuguT8fjK6dQ4w4F1i6BtXYiB4PwGX6Ym0I2+HFe/8GhieAQZPH4CaGzZR39fYx 4iTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786826573; x=1787431373; h=mime-version:content-transfer-encoding:content-type:references :in-reply-to:message-id:date:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=g3g0AYahBP3aN4rc9/ufJfxyt9G+mfOpDwe9Ft7yd84=; b=Z5Th8whxR/F3QHyaA8KTmEDkN2b/lLPAIjpS3O5dYV/a7hekeCyZa+tyOw802SF36u vrn+LW9t2HuHWTsW66wTwXLNiXCG6NQu6hl04gPmqfkP0nvD9cdA+Vw9ulhGpvTZA7Bz Ws/nIZLxG4P1XRdwir5fm/iHynjZJpj7qrtku7RQlnTjwk1mEVEZbsPGV5oCW+9IBt23 cc2gi0FR1HfGwh00MfsRIWicSfFNMo9cLxJH27LQooX4R7haihWsD50Rh9Q7lifb2vhd wPFIHXoQR070Gm3FB1x1RCvRkPy5m/ZHgxg4VZk3SrjGWFJwuDPOnJ7v7ptXyOzzQlA/ /HwQ== X-Forwarded-Encrypted: i=1; AHgh+RoecWwIxsGHN0YJ5sa9FCCZ+1v6QPbq5AJZBifRF/QAUAFhRiXhUseRoQN+Hx72dHpOfz4NTwOURbHGJ+0=@vger.kernel.org X-Gm-Message-State: AOJu0YxUJ/TjaSFtML6QI0Q0oXWJzhRpe+crc6jhbyPVLJCGlwDJkDKw iEWyB1hKyx8WnzMODOPm3/5h0wCrqdlvkkyT5/0ZvDJ9mpOSwSkxMbcV X-Gm-Gg: AR+sD11FtERq7ZYRzRuLOuKxINR0IVowQeOn9/ivu88uWo7jVCeaxSMnz2fPid11Vyf SCKII+sUhWPeyI2yeXTNphe9WWXqjNEDQPC4aifRljOQyn4cI9PB7UUlZIG1BHRgFtSpB95HM5N BQH6S3hZJd2QsncGkpo6BpVTb34sh8ArqSx7wxp1B1mOPNEkeRd/U4XMHmyJYrFkOOkaz6mSyoN AFRlcH1Xk5UrXUnB4Y70hc72CQCLvrot9Qv+SySB7zUxEbtmWcK0smtPJCNTOKv4ubWIQme98JO TDembyWUpDflO5kSbwJDgjH/rgTdCutabCiqtHnn/q8936qfhMET4KyNziXFnEWzF3YunH/4y8V ex8xMJSmCKxGyoJ4b5AXTETzNO8UnQJdBS3s+JPpfX/roEV6oMH7Lpz71Kl79Mp9V9W+LFYZuY6 eqIblcN2xiU+l40G54wqSlGtskMqsM5hhf6gMGfIMdQYeoy1RMmNVkeIuTFjkGPszocBPCqC8mw ugmVCnfSXHO4fvx+E6cX0I2N5R+EDiC+52TRqR9fg== X-Received: by 2002:a05:600c:354f:b0:495:650b:4c61 with SMTP id 5b1f17b1804b1-499879690acmr105425405e9.3.1786826572997; Sat, 15 Aug 2026 13:42:52 -0700 (PDT) Received: from [127.0.0.1] (ip-109-193-028-127.um39.pools.vodafone-ip.de. [109.193.28.127]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-499899afa39sm164118155e9.2.2026.08.15.13.42.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 15 Aug 2026 13:42:52 -0700 (PDT) From: Marek Czernohous To: nouveau@lists.freedesktop.org, dri-devel@lists.freedesktop.org Cc: sashiko-bot@kernel.org, linux-kernel@vger.kernel.org, Danilo Krummrich , Lyude Paul , David Airlie , Simona Vetter Subject: Re: [PATCH 2/3] drm/nouveau: cancel the DP IRQ work before freeing the connector Date: Sat, 15 Aug 2026 22:42:51 +0200 Message-ID: <178682657122.3795552.6920623796751043528@gmail.com> In-Reply-To: <20260815201130.7BDDF1F000E9@smtp.kernel.org> References: <178682366001.3748010.7798811159846779765@gmail.com> <178682366002.3748010.4096452389040554615@gmail.com> <20260815201130.7BDDF1F000E9@smtp.kernel.org> X-Mailer: python-smtplib Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Three findings, three different answers, so let me take them in turn. The NULL dereference in nouveau_dp_irq() is 3/3 of this series. Same thread, sent alongside this patch. Nothing further needed there, and the two are related on purpose: 2/3 drains the work, 3/3 fixes the handler that work runs. The LVDS error path in nouveau_connector_create() is real as far as I can see, and independent of anything here. drm_connector_init() has already put the connector on dev->mode_config.connector_list when the nouveau_bios_parse_lvds_table() failure path kfree()s it without drm_connector_cleanup(). I am not touching it in this series; it wants its own patch and I have no way to reach that path on my hardware. The hpd_work point is the interesting one, and I owe a correction on it. 2/3 does not create that path. Without this patch the same already queued irq_work still runs to completion and still ends in nouveau_connector_hpd(), which schedules drm->hpd_work under drm->hpd_lock; the only thing this patch adds is that the destroy now waits for it. If anything that narrows the exposure, because without the wait the work can run later still, potentially after the connector is gone. That is the bug 2/3 is about. But the wider question the bot is asking is fair, and my cover letter answered it too confidently. It says "there is no fourth patch here" on the strength of drm->hpd_work being drained in nouveau_display_fini(). Having looked again after the bot's mail: that drain runs at nouveau_display.c:600 under "if (!runtime && !drm->headless)", and disp->fini() drains it a second time under the same condition (dispnv50/disp.c:2686, dispnv04/disp.c:72, which I had not spotted when I wrote the cover). Both of those are before drm_mode_config_cleanup() reaches nouveau_connector_destroy(). So a late irq_work really can re-arm hpd_work after every drain, and nothing drains it again. Whether that is reachable in practice I do not know: nvif_event_block() on conn->irq has already run by then, so it needs work that was queued before the block and has not run yet. I cannot rule it out, so I should not have written that sentence as a finding. It should have said that I looked and did not find a fourth patch, not that there is none. If the maintainers want, the shape of a fix is probably a drain of hpd_work after the connectors are gone, or making nouveau_connector_hpd() a no-op once teardown has started, but that is a separate change from this series and I would rather someone who knows the hotplug path weighs in before I write it. For the avoidance of doubt: 2/3 and 3/3 still stand as posted. 1/3 is withdrawn, for an unrelated reason, in the sibling thread.