Re: [PATCH v2] firmware/sysfb: Fix device reference count leak in sysfb_disable()

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Low] firmware/sysfb: conversational reply and mbox headers in commit
  message
--

commit 138aa0cb748b38d7396e354631327333b8c26fd3
Author: Wentao Liang <vulab@iscas.ac.cn>

> firmware/sysfb: Fix device reference count leak in sysfb_disable()
>
> Hi Thomas, Alex,
>
> Sorry for the very late reply, and thanks for the review.
>
> Alex, you asked whether sysfb_unregister() would still need to be called
> when the parent device lookup returns an error. It does: without a known
> parent we cannot tell whether the system framebuffer belongs to the
> calling device, and leaving it registered could make sysfb interfere with
> the native driver. Thomas, that is the defensive behaviour you suggested,
> so v2 unregisters unconditionally when sysfb_parent_dev() fails and only
> drops the reference on the non-error path.
>
> The reference leak fix itself is unchanged.
>
> From 8c5f084941a3b6aca5d3ae8cff0c3bd1d4ae1e6f Mon Sep 17 00:00:00 2001
> From: Wentao Liang <vulab@iscas.ac.cn>
> Date: Sat, 7 Nov 2026 17:02:27 +0000
> Subject: [PATCH v2] firmware/sysfb: Fix device reference count leak in
>  sysfb_disable()
>
> sysfb_parent_dev() returns a pointer to &pdev->dev with an acquired
> reference when it finds the PCI device that contains the system
> framebuffer. sysfb_disable() never drops that reference, so a reference
> to the PCI device is leaked on every call that resolves a parent.
>
> Release the reference with put_device() before leaving the critical
> section.
>
> If the parent device cannot be determined, unregister the system
> framebuffer unconditionally, as it might still belong to the calling
> device. Leaving sysfb registered in that case can make it interfere
> with the native driver.
>
> Fixes: b49420d6a1ae ("video/aperture: optionally match the device in sysfb_disable()")
> Cc: stable@vger.kernel.org
> Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>

[Severity: Low]
The commit message includes a conversational reply and a duplicate
git-format-patch header block above the "---" tear line without a
scissors line ("-- >8 --"), so git am records them in the commit log.
The reply notes belong below "---" (or above a scissors line), and the
extra mbox headers should be removed from the changelog body.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/1794071765.2669957.4378216502938475@iscas.ac.cn?part=1