From: Claude Code Review Bot <claude-review@example.com>
To: dri-devel-reviews@example.com
Subject: Claude review: fbdev: fbcon: fix memory leak in error path of fbcon_do_set_font()
Date: Tue, 26 May 2026 07:32:11 +1000 [thread overview]
Message-ID: <review-patch1-20260525082741.600003-1-w15303746062@163.com> (raw)
In-Reply-To: <20260525082741.600003-1-w15303746062@163.com>
Patch Review
**Bug Analysis: Correct**
The commit message clearly explains the root cause — the `p->userfont = old_userfont` assignment is inside the `if (userfont)` block in `err_out`, so when a builtin font set (`userfont == 0`) fails, the old userfont state is never restored. The kmemleak backtrace and the Fixes tag to `a5a923038d70` are appropriate.
**Code Change: Correct (for old code)**
```diff
+ /* Unconditionally restore the previous userfont state */
+ p->userfont = old_userfont;
+
if (userfont) {
- p->userfont = old_userfont;
if (--REFCOUNT(data) == 0)
kfree(data - FONT_EXTRA_WORDS * sizeof(int));
}
```
Moving `p->userfont = old_userfont` outside the `if (userfont)` block is the right fix. The restore should be unconditional regardless of the type of font that was being set, because the error path's job is to fully roll back state. The `if (userfont)` block that remains correctly handles freeing the *new* font data (which only needs freeing if it was a user-allocated font), so that conditional stays correct.
**Issues:**
1. **Not applicable to mainline.** The `[PATCH 7.0]` tag in the subject and the note in the commit message acknowledge this, but the patch was sent to dri-devel rather than stable@vger.kernel.org. It should target the 7.0.y stable tree directly. Mainline's `fbcon_do_set_font()` now uses `font_data_t` with reference counting and has no `userfont` field at all.
2. **Comment is unnecessary.** The added `/* Unconditionally restore the previous userfont state */` comment just restates what the code does. In the kernel style, this would typically be omitted — the variable name `old_userfont` already makes the intent clear. Minor nit.
3. **Subject tag `[PATCH 7.0]` is non-standard.** For stable submissions, the standard practice is to send the patch with `Cc: stable@vger.kernel.org` and optionally note the affected versions in the commit message body, not use a version tag in the subject bracket.
**Summary:** The fix itself is sound and addresses a real bug. It just needs to go through the correct stable-tree submission process rather than being sent as a mainline patch to dri-devel.
---
Generated by Claude Code Patch Reviewer
prev parent reply other threads:[~2026-05-25 21:32 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-25 8:27 [PATCH 7.0] fbdev: fbcon: fix memory leak in error path of fbcon_do_set_font() w15303746062
2026-05-25 21:32 ` Claude review: " Claude Code Review Bot
2026-05-25 21:32 ` Claude Code Review Bot [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=review-patch1-20260525082741.600003-1-w15303746062@163.com \
--to=claude-review@example.com \
--cc=dri-devel-reviews@example.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox