>-----Original Message----- >From: Jacopo Mondi <jacopo.mondi@xxxxxxxxxxxxxxxx> >Sent: Saturday, August 2, 2025 5:23 PM >To: Mauro Carvalho Chehab <mchehab@xxxxxxxxxx>; Devarsh Thakkar ><devarsht@xxxxxx>; Benoit Parrot <bparrot@xxxxxx>; Hans Verkuil ><hverkuil@xxxxxxxxxx>; Mike Isely <isely@xxxxxxxxx>; Laurent Pinchart ><laurent.pinchart@xxxxxxxxxxxxxxxx>; Hans de Goede <hansg@xxxxxxxxxx>; >Parthiban Veerasooran <parthiban.veerasooran@xxxxxxxxxxxxx>; Christian >Gromm <christian.gromm@xxxxxxxxxxxxx>; Greg Kroah-Hartman ><gregkh@xxxxxxxxxxxxxxxxxxx>; Alex Shi <alexs@xxxxxxxxxx>; Yanteng Si ><si.yanteng@xxxxxxxxx>; Dongliang Mu <dzm91@xxxxxxxxxxx>; Jonathan >Corbet <corbet@xxxxxxx>; Tomasz Figa <tfiga@xxxxxxxxxxxx>; Marek >Szyprowski <m.szyprowski@xxxxxxxxxxx>; Andy Walls ><awalls@xxxxxxxxxxxxxxxx>; Michael Tretter <m.tretter@xxxxxxxxxxxxxx>; >Pengutronix Kernel Team <kernel@xxxxxxxxxxxxxx>; Bin Liu ><bin.liu@xxxxxxxxxxxx>; Matthias Brugger <matthias.bgg@xxxxxxxxx>; >AngeloGioacchino Del Regno <angelogioacchino.delregno@xxxxxxxxxxxxx>; >Dmitry Osipenko <digetx@xxxxxxxxx>; Thierry Reding ><thierry.reding@xxxxxxxxx>; Jonathan Hunter <jonathanh@xxxxxxxxxx>; >Mirela Rabulea <mirela.rabulea@xxxxxxx>; Shawn Guo ><shawnguo@xxxxxxxxxx>; Sascha Hauer <s.hauer@xxxxxxxxxxxxxx>; Fabio >Estevam <festevam@xxxxxxxxx>; Kieran Bingham ><kieran.bingham+renesas@xxxxxxxxxxxxxxxx>; Michal Simek ><michal.simek@xxxxxxx>; Ming Qian <ming.qian@xxxxxxx>; Eagle Zhou ><eagle.zhou@xxxxxxx>; Xavier Roumegue (OSS) ><xavier.roumegue@xxxxxxxxxxx>; Philipp Zabel <p.zabel@xxxxxxxxxxxxxx>; >Vikash Garodia <quic_vgarodia@xxxxxxxxxxx>; Dikshita Agarwal ><quic_dikshita@xxxxxxxxxxx>; Abhinav Kumar <abhinav.kumar@xxxxxxxxx>; >Bryan O'Donoghue <bryan.odonoghue@xxxxxxxxxx>; Sylwester Nawrocki ><sylvester.nawrocki@xxxxxxxxx>; Jernej Skrabec <jernej.skrabec@xxxxxxxxx>; >Chen-Yu Tsai <wens@xxxxxxxx>; Samuel Holland <samuel@xxxxxxxxxxxx>; >Daniel Almeida <daniel.almeida@xxxxxxxxxxxxx>; Neil Armstrong ><neil.armstrong@xxxxxxxxxx>; Kevin Hilman <khilman@xxxxxxxxxxxx>; Jerome >Brunet <jbrunet@xxxxxxxxxxxx>; Martin Blumenstingl ><martin.blumenstingl@xxxxxxxxxxxxxx>; Nas Chung ><nas.chung@xxxxxxxxxxxxxxx>; Jackson Lee ><jackson.lee@xxxxxxxxxxxxxxx>; Minghsiu Tsai ><minghsiu.tsai@xxxxxxxxxxxx>; Houlong Wei <houlong.wei@xxxxxxxxxxxx>; >Andrew-CT Chen <andrew-ct.chen@xxxxxxxxxxxx>; Tiffany Lin ><tiffany.lin@xxxxxxxxxxxx>; Yunfei Dong <yunfei.dong@xxxxxxxxxxxx>; >Geert Uytterhoeven <geert+renesas@xxxxxxxxx>; Magnus Damm ><magnus.damm@xxxxxxxxx>; Mikhail Ulyanov ><mikhail.ulyanov@xxxxxxxxxxxxxxxxxx>; Jacob Chen <jacob- >chen@xxxxxxxxxx>; Ezequiel Garcia <ezequiel@xxxxxxxxxxxxxxxxxxxx>; Heiko >Stuebner <heiko@xxxxxxxxx>; Detlev Casanova ><detlev.casanova@xxxxxxxxxxxxx>; Krzysztof Kozlowski <krzk@xxxxxxxxxx>; >Alim Akhtar <alim.akhtar@xxxxxxxxxxx>; Sylwester Nawrocki ><s.nawrocki@xxxxxxxxxxx>; Łukasz Stelmach <l.stelmach@xxxxxxxxxxx>; >Andrzej Pietrasiewicz <andrzejtp2010@xxxxxxxxx>; Jacek Anaszewski ><jacek.anaszewski@xxxxxxxxx>; Andrzej Hajda <andrzej.hajda@xxxxxxxxx>; >Fabien Dessenne <fabien.dessenne@xxxxxxxxxxx>; Hugues Fruchet ><hugues.fruchet@xxxxxxxxxxx>; Jean-Christophe Trotin <jean- >christophe.trotin@xxxxxxxxxxx>; Maxime Coquelin ><mcoquelin.stm32@xxxxxxxxx>; Alexandre Torgue ><alexandre.torgue@xxxxxxxxxxx>; Nicolas Dufresne ><nicolas.dufresne@xxxxxxxxxxxxx>; Benjamin Gaignard ><benjamin.gaignard@xxxxxxxxxxxxx>; Steve Longerbeam ><slongerbeam@xxxxxxxxx>; Maxime Ripard <mripard@xxxxxxxxxx>; Paul >Kocialkowski <paulk@xxxxxxxxxxx>; Niklas Söderlund ><niklas.soderlund@xxxxxxxxxxxx>; Robert Foss <rfoss@xxxxxxxxxx>; Todor >Tomov <todor.too@xxxxxxxxx>; Vladimir Zapolskiy ><vladimir.zapolskiy@xxxxxxxxxx>; Corentin Labbe <clabbe@xxxxxxxxxxxx>; >Sakari Ailus <sakari.ailus@xxxxxxxxxxxxxxx>; Bingbu Cao ><bingbu.cao@xxxxxxxxx>; Tianshu Qiu <tian.shu.qiu@xxxxxxxxx>; Stanislaw >Gruszka <stanislaw.gruszka@xxxxxxxxxxxxxxx> >Cc: linux-media@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; linux- >staging@xxxxxxxxxxxxxxx; linux-doc@xxxxxxxxxxxxxxx; linux-arm- >kernel@xxxxxxxxxxxxxxxxxxx; linux-mediatek@xxxxxxxxxxxxxxxxxxx; linux- >tegra@xxxxxxxxxxxxxxx; imx@xxxxxxxxxxxxxxx; linux-renesas-soc@xxxxxxxxxxxxxxx; >linux-arm-msm@xxxxxxxxxxxxxxx; linux-samsung-soc@xxxxxxxxxxxxxxx; linux- >sunxi@xxxxxxxxxxxxxxx; linux-usb@xxxxxxxxxxxxxxx; linux- >amlogic@xxxxxxxxxxxxxxxxxxx; linux-rockchip@xxxxxxxxxxxxxxxxxxx; linux- >stm32@xxxxxxxxxxxxxxxxxxxxxxxxxxxx; mjpeg-users@xxxxxxxxxxxxxxxxxxxxx; >Jacopo Mondi <jacopo.mondi@xxxxxxxxxxxxxxxx> >Subject: [EXT] [PATCH 14/65] media: amphion: Delete v4l2_fh synchronously >in .release() > >Caution: This is an external email. Please take care when clicking links or >opening attachments. When in doubt, report the message using the 'Report >this email' button > > >From: Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> > >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@xxxxxxxxxxxxxxxx> >Signed-off-by: Jacopo Mondi <jacopo.mondi@xxxxxxxxxxxxxxxx> Reviewed-by: Ming Qian <ming.qian@xxxxxxxxxxx> >--- > 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..57ca6262bb04b356a85e217ef >51cfb13cb9a0a36 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
