On Wed, Aug 19, 2026 at 04:38:57PM +0530, Mallesh, Koujalagi wrote:
> 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.
Which would still fail with this patch applied because WEDGE_STR_LEN
remains the same.
So again. This isn't really fixing anything, it's just a robust refactor.
Raag
