On 19-08-2026 04:22 pm, Raag Jadav wrote:
On Wed, Aug 19, 2026 at 03:48:31PM +0530, Mallesh, Koujalagi wrote:
On 19-08-2026 09:58 am, Raag Jadav wrote:
On Tue, Aug 18, 2026 at 07:06:11PM +0530, Mallesh Koujalagi wrote:
event_string[] has a fixed size of WEDGE_STR_LEN (32) bytes.
The original scnprintf()-based loop required a manual pre-flight
bounds check.
Replace the manual bookkeeping with seq_buf, which tracks overflow
internally. seq_buf_printf() writes each "method," token into the
buffer.
On overflow, len retains the position of the last
successful write, so the trailing comma is stripped cleanly without
including any partial method name in the uevent payload.
Fixes: b7cf9f4ac1b8 ("drm: Introduce device wedged event")
This actually doesn't fix anything, it just adds a WARN() splat.
So I'm not sure if this is needed here.
In previous implementation multiple recovery methods may exceed
WEDGE_STR_LEN (32) that
cause silently truncate a recovery method and emit a malformed uevent string
containing a
partial token, however using seq_buf makes overflow
explicit, when it occurs, emits a WARN and include complete recovery name
in the uevent string so IMO, it's fix.
Is there an existing drm_dev_wedged_event() user that is facing this
issue? Please attach bug reports along with reproducers (if any).
Currently Sashiko is already reported that issue, here is details:
https://sashiko.dev/#/patchset/20260720101815.526813-5-mallesh.koujalagi%40intel.com
Improvements are good, but not everything is a bug because AI said so :)
Agreed!, however in future, if we support multiple recovery method,
definitely we encounter such issue.
Thanks,
-/Mallesh
Raag
