Message-Id: <20250802-media-private-data-v1-14-eb140ddd6a9d@ideasonboard.com>
Date: Sat, 02 Aug 2025 11:22:36 +0200
From: Jacopo Mondi <jacopo.mondi@...asonboard.com>
To: Mauro Carvalho Chehab <mchehab@...nel.org>, 
 Devarsh Thakkar <devarsht@...com>, Benoit Parrot <bparrot@...com>, 
 Hans Verkuil <hverkuil@...nel.org>, Mike Isely <isely@...ox.com>, 
 Laurent Pinchart <laurent.pinchart@...asonboard.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>
Cc: 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, 
 Jacopo Mondi <jacopo.mondi@...asonboard.com>
Subject: [PATCH 14/65] media: amphion: Delete v4l2_fh synchronously in
 .release()

From: Laurent Pinchart <laurent.pinchart@...asonboard.com>

The v4l2_fh initialized and added in vpu_v4l2_open() is delete and
cleaned up when the last reference to the vpu_inst is released. This may
happen later than at vpu_v4l2_close() time.

Not deleting and cleaning up the v4l2_fh when closing the file handle to
the video device is not ideal, as the v4l2_fh will still be present in
the video device's fh_list, and will store a copy of events queued to
the video device. There may also be other side effects of keeping alive
an object that represents an open file handle after the file handle is
closed.

The v4l2_fh instance is embedded in the vpu_inst structure, and is
accessed in two different ways:

- in vpu_notify_eos() and vpu_notify_source_change(), to queue V4L2
  events to the file handle ; and

- through the driver to access the v4l2_fh.m2m_ctx pointer.

The v4l2_fh.m2m_ctx pointer is not touched by v4l2_fh_del() and
v4l2_fh_exit(). It is set to NULL by the driver when closing the file
handle, in vpu_v4l2_close().

The vpu_notify_eos() and vpu_notify_source_change() functions are called
in vpu_set_last_buffer_dequeued() and vdec_handle_resolution_change()
respectively, only if the v4l2_fh.m2m_ctx pointer is not NULL. There is
therefore a guarantee that no new event will be queued to the v4l2_fh
after vpu_v4l2_close() destroys the m2m_ctx.

The vpu_notify_eos() function is also called from vpu_vb2_buf_finish(),
which is guaranteed to be called for all queued buffers when
vpu_v4l2_close() calls v4l2_m2m_ctx_release(), and will not be called
later.

It is therefore safe to assume that the driver will not touch the
v4l2_fh, except to check the m2m_ctx pointer, after vpu_v4l2_close()
destroys the m2m_ctx. We can safely delete and cleanup the v4l2_fh
synchronously in vpu_v4l2_close().

Signed-off-by: Laurent Pinchart <laurent.pinchart@...asonboard.com>
Signed-off-by: Jacopo Mondi <jacopo.mondi@...asonboard.com>
---
 drivers/media/platform/amphion/vpu_v4l2.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/amphion/vpu_v4l2.c b/drivers/media/platform/amphion/vpu_v4l2.c
index 306d94e0f8e79faaacfa35b28e5786860f7bd1ca..57ca6262bb04b356a85e217ef51cfb13cb9a0a36 100644
--- a/drivers/media/platform/amphion/vpu_v4l2.c
+++ b/drivers/media/platform/amphion/vpu_v4l2.c
@@ -724,8 +724,6 @@ static int vpu_v4l2_release(struct vpu_inst *inst)
 
 	v4l2_ctrl_handler_free(&inst->ctrl_handler);
 	mutex_destroy(&inst->lock);
-	v4l2_fh_del(&inst->fh);
-	v4l2_fh_exit(&inst->fh);
 
 	call_void_vop(inst, cleanup);
 
@@ -794,6 +792,8 @@ int vpu_v4l2_open(struct file *file, struct vpu_inst *inst)
 
 	return 0;
 error:
+	v4l2_fh_del(&inst->fh);
+	v4l2_fh_exit(&inst->fh);
 	vpu_inst_put(inst);
 	return ret;
 }
@@ -813,6 +813,9 @@ int vpu_v4l2_close(struct file *file)
 	call_void_vop(inst, release);
 	vpu_inst_unlock(inst);
 
+	v4l2_fh_del(&inst->fh);
+	v4l2_fh_exit(&inst->fh);
+
 	vpu_inst_unregister(inst);
 	vpu_inst_put(inst);
 

-- 
2.49.0

Powered by blists - more mailing lists