linux-kernel - Re: [PATCH v2 02/10] media: v4l2-dev: Add support for try state

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <175916253442.2234821.5624749898039510125@freya>
Date: Mon, 29 Sep 2025 21:45:34 +0530
From: Jai Luthra <jai.luthra@...asonboard.com>
To: Hans Verkuil <hverkuil+cisco@...nel.org>, Hans Verkuil <hverkuil@...nel.org>, Jacopo Mondi <jacopo.mondi@...asonboard.com>, Laurent Pinchart <laurent.pinchart@...asonboard.com>, Mauro Carvalho Chehab <mchehab@...nel.org>, Sakari Ailus <sakari.ailus@...ux.intel.com>, Tomi Valkeinen <tomi.valkeinen@...asonboard.com>, linux-media@...r.kernel.org
Cc: Ricardo Ribalda <ribalda@...omium.org>, Laurent Pinchart <laurent.pinchart+renesas@...asonboard.com>, Ma Ke <make24@...as.ac.cn>, Bartosz Golaszewski <bartosz.golaszewski@...aro.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 02/10] media: v4l2-dev: Add support for try state

Hi Hans,

Quoting Hans Verkuil (2025-09-22 13:28:26)
> On 22/09/2025 09:52, Hans Verkuil wrote:
> > On 19/09/2025 11:55, Jai Luthra wrote:
> >> Format negotiation performed via the TRY_FMT ioctl should only affect
> >> the temporary context of a specific filehandle, not the active state
> >> stored in the video device structure. To support this distinction, we
> >> need separate storage for try and active states.
> >>
> >> Introduce an enum to distinguish between these two state types and store
> >> the try state in struct v4l2_fh instead of the video device structure.
> >> The try state is allocated during file handle initialization in
> >> v4l2_fh_init() and released in v4l2_fh_exit().
> > 
> > There is a major difference between TRY in video devices and TRY in subdev
> > devices: TRY for video devices is not persistent, i.e. it doesn't need to
> > be stored anywhere since nobody will be using that information.
> > 

Yes, the v4l2 format sent with VIDIOC_TRY_FMT is currently not stored by
the drivers, but simply modified and returned back to userspace. From the
userspace point of view, that should still work the same way with this
series.

The drivers will get access to the correct state (active) for internal use
through framework helpers (that will be introduced in next revision), so
the try state doesn't have any real "use" today.

> > If the plan is to change that in later patch series, then that should be
> > very clearly stated. And I think I would need to know the details of those
> > future plans before I can OK this.
> > 
> > So how is this try state intended to be used in the future?
> 
> Follow-up: if there are no plans to change/enhance the VIDIOC_TRY_FMT semantics,
> then I don't really see the point of this since there is no need to store this
> information.

There are no plans to change the userspace side of this. The main
motivation to allocate and keep a try state in the framework is to simplify
the driver implementation. A single function can serve as both s_fmt and
try_fmt ioctl handler, and operate on the passed state argument without
caring if it will be applied on the device or just for negotiation.

In future, drivers may subclass the state with their device specific data,
so that nothing tied to the hardware state is stored in the driver
structures directly, but I don't see why drivers will need to inspect TRY
formats.

> 
> Regards,
> 
>         Hans
> 
> > 
> > Regards,
> > 
> >       Hans
> > 

Thanks,
Jai

[snip]