| 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
| ||
|
Message-ID: <20250806094822.GA24768@pendragon.ideasonboard.com>
Date: Wed, 6 Aug 2025 12:48:22 +0300
From: Laurent Pinchart <laurent.pinchart@...asonboard.com>
To: Hans Verkuil <hverkuil+cisco@...nel.org>
Cc: Jacopo Mondi <jacopo.mondi@...asonboard.com>,
Mauro Carvalho Chehab <mchehab@...nel.org>,
Devarsh Thakkar <devarsht@...com>, Benoit Parrot <bparrot@...com>,
Hans Verkuil <hverkuil@...nel.org>, Mike Isely <isely@...ox.com>,
Hans de Goede <hansg@...nel.org>,
Parthiban Veerasooran <parthiban.veerasooran@...rochip.com>,
Christian Gromm <christian.gromm@...rochip.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Alex Shi <alexs@...nel.org>, Yanteng Si <si.yanteng@...ux.dev>,
Dongliang Mu <dzm91@...t.edu.cn>, Jonathan Corbet <corbet@....net>,
Tomasz Figa <tfiga@...omium.org>,
Marek Szyprowski <m.szyprowski@...sung.com>,
Andy Walls <awalls@...metrocast.net>,
Michael Tretter <m.tretter@...gutronix.de>,
Pengutronix Kernel Team <kernel@...gutronix.de>,
Bin Liu <bin.liu@...iatek.com>,
Matthias Brugger <matthias.bgg@...il.com>,
AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
Dmitry Osipenko <digetx@...il.com>,
Thierry Reding <thierry.reding@...il.com>,
Jonathan Hunter <jonathanh@...dia.com>,
Mirela Rabulea <mirela.rabulea@....com>,
Shawn Guo <shawnguo@...nel.org>,
Sascha Hauer <s.hauer@...gutronix.de>,
Fabio Estevam <festevam@...il.com>,
Kieran Bingham <kieran.bingham+renesas@...asonboard.com>,
Michal Simek <michal.simek@....com>, Ming Qian <ming.qian@....com>,
Zhou Peng <eagle.zhou@....com>,
Xavier Roumegue <xavier.roumegue@....nxp.com>,
Philipp Zabel <p.zabel@...gutronix.de>,
Vikash Garodia <quic_vgarodia@...cinc.com>,
Dikshita Agarwal <quic_dikshita@...cinc.com>,
Abhinav Kumar <abhinav.kumar@...ux.dev>,
Bryan O'Donoghue <bryan.odonoghue@...aro.org>,
Sylwester Nawrocki <sylvester.nawrocki@...il.com>,
Jernej Skrabec <jernej.skrabec@...il.com>,
Chen-Yu Tsai <wens@...e.org>, Samuel Holland <samuel@...lland.org>,
Daniel Almeida <daniel.almeida@...labora.com>,
Neil Armstrong <neil.armstrong@...aro.org>,
Kevin Hilman <khilman@...libre.com>,
Jerome Brunet <jbrunet@...libre.com>,
Martin Blumenstingl <martin.blumenstingl@...glemail.com>,
Nas Chung <nas.chung@...psnmedia.com>,
Jackson Lee <jackson.lee@...psnmedia.com>,
Minghsiu Tsai <minghsiu.tsai@...iatek.com>,
Houlong Wei <houlong.wei@...iatek.com>,
Andrew-CT Chen <andrew-ct.chen@...iatek.com>,
Tiffany Lin <tiffany.lin@...iatek.com>,
Yunfei Dong <yunfei.dong@...iatek.com>,
Geert Uytterhoeven <geert+renesas@...der.be>,
Magnus Damm <magnus.damm@...il.com>,
Mikhail Ulyanov <mikhail.ulyanov@...entembedded.com>,
Jacob Chen <jacob-chen@...wrt.com>,
Ezequiel Garcia <ezequiel@...guardiasur.com.ar>,
Heiko Stuebner <heiko@...ech.de>,
Detlev Casanova <detlev.casanova@...labora.com>,
Krzysztof Kozlowski <krzk@...nel.org>,
Alim Akhtar <alim.akhtar@...sung.com>,
Sylwester Nawrocki <s.nawrocki@...sung.com>,
Łukasz Stelmach <l.stelmach@...sung.com>,
Andrzej Pietrasiewicz <andrzejtp2010@...il.com>,
Jacek Anaszewski <jacek.anaszewski@...il.com>,
Andrzej Hajda <andrzej.hajda@...el.com>,
Fabien Dessenne <fabien.dessenne@...s.st.com>,
Hugues Fruchet <hugues.fruchet@...s.st.com>,
Jean-Christophe Trotin <jean-christophe.trotin@...s.st.com>,
Maxime Coquelin <mcoquelin.stm32@...il.com>,
Alexandre Torgue <alexandre.torgue@...s.st.com>,
Nicolas Dufresne <nicolas.dufresne@...labora.com>,
Benjamin Gaignard <benjamin.gaignard@...labora.com>,
Steve Longerbeam <slongerbeam@...il.com>,
Maxime Ripard <mripard@...nel.org>,
Paul Kocialkowski <paulk@...-base.io>,
Niklas Söderlund <niklas.soderlund@...natech.se>,
Robert Foss <rfoss@...nel.org>, Todor Tomov <todor.too@...il.com>,
Vladimir Zapolskiy <vladimir.zapolskiy@...aro.org>,
Corentin Labbe <clabbe@...libre.com>,
Sakari Ailus <sakari.ailus@...ux.intel.com>,
Bingbu Cao <bingbu.cao@...el.com>,
Tianshu Qiu <tian.shu.qiu@...el.com>,
Stanislaw Gruszka <stanislaw.gruszka@...ux.intel.com>,
linux-media@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-staging@...ts.linux.dev, linux-doc@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org,
linux-mediatek@...ts.infradead.org, linux-tegra@...r.kernel.org,
imx@...ts.linux.dev, linux-renesas-soc@...r.kernel.org,
linux-arm-msm@...r.kernel.org, linux-samsung-soc@...r.kernel.org,
linux-sunxi@...ts.linux.dev, linux-usb@...r.kernel.org,
linux-amlogic@...ts.infradead.org,
linux-rockchip@...ts.infradead.org,
linux-stm32@...md-mailman.stormreply.com,
mjpeg-users@...ts.sourceforge.net
Subject: Re: [PATCH 11/65] media: Replace file->private_data access with
custom functions
Hi Hans,
On Wed, Aug 06, 2025 at 10:16:37AM +0200, Hans Verkuil wrote:
> On 02/08/2025 11:22, Jacopo Mondi wrote:
> > From: Laurent Pinchart <laurent.pinchart@...asonboard.com>
> >
> > Accessing file->private_data manually to retrieve the v4l2_fh pointer is
> > error-prone, as the field is a void * and will happily cast implicitly
> > to any pointer type.
> >
> > Replace all remaining locations that read the v4l2_fh pointer directly
> > from file->private_data and cast it to driver-specific file handle
> > structures with driver-specific functions that use file_to_v4l2_fh() and
> > perform the same cast.
> >
> > No functional change is intended, this only paves the way to remove
> > direct accesses to file->private_data and make V4L2 drivers safer.
> > Other accesses to the field will be addressed separately.
> >
> > Signed-off-by: Laurent Pinchart <laurent.pinchart@...asonboard.com>
> > Signed-off-by: Jacopo Mondi <jacopo.mondi@...asonboard.com>
> > ---
> > drivers/media/pci/ivtv/ivtv-driver.h | 5 ++++
> > drivers/media/pci/ivtv/ivtv-fileops.c | 10 +++----
> > drivers/media/pci/ivtv/ivtv-ioctl.c | 8 +++---
> > drivers/media/platform/allegro-dvt/allegro-core.c | 7 ++++-
> > drivers/media/platform/amlogic/meson-ge2d/ge2d.c | 8 ++++--
> > .../media/platform/chips-media/coda/coda-common.c | 7 ++++-
> > .../platform/chips-media/wave5/wave5-helper.c | 2 +-
> > .../media/platform/chips-media/wave5/wave5-vpu.h | 5 ++++
> > drivers/media/platform/m2m-deinterlace.c | 7 ++++-
> > .../media/platform/mediatek/jpeg/mtk_jpeg_core.c | 7 ++++-
> > drivers/media/platform/mediatek/mdp/mtk_mdp_m2m.c | 7 ++++-
> > .../media/platform/mediatek/mdp3/mtk-mdp3-m2m.c | 7 ++++-
> > .../mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c | 2 +-
> > .../mediatek/vcodec/decoder/mtk_vcodec_dec_drv.h | 5 ++++
> > .../mediatek/vcodec/encoder/mtk_vcodec_enc_drv.c | 2 +-
> > .../mediatek/vcodec/encoder/mtk_vcodec_enc_drv.h | 5 ++++
> > drivers/media/platform/nxp/imx-jpeg/mxc-jpeg.c | 7 ++++-
> > drivers/media/platform/nxp/imx8-isi/imx8-isi-m2m.c | 7 ++++-
> > drivers/media/platform/nxp/mx2_emmaprp.c | 7 ++++-
> > drivers/media/platform/renesas/rcar_fdp1.c | 7 ++++-
> > drivers/media/platform/renesas/rcar_jpu.c | 7 ++++-
> > drivers/media/platform/rockchip/rga/rga.c | 3 +--
> > drivers/media/platform/rockchip/rga/rga.h | 5 ++++
> > drivers/media/platform/rockchip/rkvdec/rkvdec.c | 2 +-
> > drivers/media/platform/rockchip/rkvdec/rkvdec.h | 5 ++++
> > .../media/platform/samsung/exynos-gsc/gsc-core.h | 6 +++++
> > .../media/platform/samsung/exynos-gsc/gsc-m2m.c | 6 ++---
> > .../media/platform/samsung/exynos4-is/fimc-core.h | 5 ++++
> > .../media/platform/samsung/exynos4-is/fimc-m2m.c | 2 +-
> > drivers/media/platform/samsung/s5p-g2d/g2d.c | 7 +++--
> > .../media/platform/samsung/s5p-jpeg/jpeg-core.c | 9 +++++--
> > drivers/media/platform/samsung/s5p-mfc/s5p_mfc.c | 6 ++---
> > .../platform/samsung/s5p-mfc/s5p_mfc_common.h | 6 +++++
> > drivers/media/platform/st/sti/bdisp/bdisp-v4l2.c | 7 ++++-
> > drivers/media/platform/st/sti/delta/delta-v4l2.c | 26 +++++++++++-------
> > drivers/media/platform/st/sti/hva/hva-v4l2.c | 31 ++++++++++++----------
> > drivers/media/platform/st/sti/hva/hva.h | 2 --
> > drivers/media/platform/st/stm32/dma2d/dma2d.c | 7 +++--
> > drivers/media/platform/sunxi/sun8i-di/sun8i-di.c | 3 +--
> > .../platform/sunxi/sun8i-rotate/sun8i_rotate.c | 3 +--
> > drivers/media/platform/ti/omap3isp/ispvideo.c | 4 +--
> > drivers/media/platform/ti/omap3isp/ispvideo.h | 6 +++++
> > drivers/media/platform/verisilicon/hantro.h | 5 ++++
> > drivers/media/platform/verisilicon/hantro_drv.c | 3 +--
> > drivers/staging/media/imx/imx-media-csc-scaler.c | 7 ++++-
> > drivers/staging/media/meson/vdec/vdec.c | 24 ++++++-----------
> > drivers/staging/media/meson/vdec/vdec.h | 5 ++++
> > drivers/staging/media/sunxi/cedrus/cedrus.c | 3 +--
> > drivers/staging/media/sunxi/cedrus/cedrus.h | 5 ++++
> > drivers/staging/media/sunxi/cedrus/cedrus_video.c | 5 ----
> > 50 files changed, 237 insertions(+), 100 deletions(-)
> >
> > diff --git a/drivers/media/pci/ivtv/ivtv-driver.h b/drivers/media/pci/ivtv/ivtv-driver.h
> > index a6ffa99e16bc64a5b7d3e48c1ab32b49a7989242..cad548b28e360ecfe2bcb9fcb5d12cd8823c3727 100644
> > --- a/drivers/media/pci/ivtv/ivtv-driver.h
> > +++ b/drivers/media/pci/ivtv/ivtv-driver.h
> > @@ -388,6 +388,11 @@ static inline struct ivtv_open_id *fh2id(struct v4l2_fh *fh)
> > return container_of(fh, struct ivtv_open_id, fh);
> > }
> >
> > +static inline struct ivtv_open_id *file2id(struct file *filp)
> > +{
> > + return container_of(file_to_v4l2_fh(filp), struct ivtv_open_id, fh);
>
> Why not write:
>
> return fh2id(file_to_v4l2_fh(filp));
>
> Same for all other drivers that do this. I prefer to have the contained_of()
> in just one place.
Because fh2id gets removed in "[PATCH 57/65] media: ivtv: Access v4l2_fh
from file". I can use it in this patch and drop it later, would you
prefer that ?
> > +}
> > +
> > struct yuv_frame_info
> > {
> > u32 update;
>
> <snip>
>
> > diff --git a/drivers/media/platform/allegro-dvt/allegro-core.c b/drivers/media/platform/allegro-dvt/allegro-core.c
> > index 1f134e08923a528cc676f825da68951c97ac2f25..74977f3ae4844022c04de877f31b4fc6aaac0749 100644
> > --- a/drivers/media/platform/allegro-dvt/allegro-core.c
> > +++ b/drivers/media/platform/allegro-dvt/allegro-core.c
> > @@ -302,6 +302,11 @@ struct allegro_channel {
> > unsigned int error;
> > };
> >
> > +static inline struct allegro_channel *file_to_channel(struct file *filp)
> > +{
> > + return container_of(file_to_v4l2_fh(filp), struct allegro_channel, fh);
> > +}
> > +
> > static inline int
> > allegro_channel_get_i_frame_qp(struct allegro_channel *channel)
> > {
> > @@ -3229,7 +3234,7 @@ static int allegro_open(struct file *file)
> >
> > static int allegro_release(struct file *file)
> > {
> > - struct allegro_channel *channel = fh_to_channel(file->private_data);
> > + struct allegro_channel *channel = file_to_channel(file);
>
> So a file_to_channel inline function was added, but it is used in just one
> place.
>
> I would prefer to just drop the inline function and instead write:
>
> struct allegro_channel *channel = fh_to_channel(file_to_v4l2_fh(file));
>
> If this is needed in two or more places, then the extra inline makes sense,
> but it is a fairly common pattern that it is only needed in the release function.
>
> Adding a new inline just for that seems overkill to me.
file_to_channel() gets used in more places in "[PATCH 29/65] media:
allegro: Access v4l2_fh from file", where fh_to_channel() is dropped.
I'd rather keep it in this patch instead of having to modify the
allegro_release() function in patch 29/65.
> >
> > v4l2_m2m_ctx_release(channel->fh.m2m_ctx);
> >
--
Regards,
Laurent Pinchart
Powered by blists - more mailing lists