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).
Improvements are good, but not everything is a bug because AI said so :)
Raag
