On (24/10/25 12:50), Dikshita Agarwal wrote: > > diff --git a/drivers/media/platform/qcom/venus/vdec.c b/drivers/media/platform/qcom/venus/vdec.c > > index 6252a6b3d4ba..0013c4704f03 100644 > > --- a/drivers/media/platform/qcom/venus/vdec.c > > +++ b/drivers/media/platform/qcom/venus/vdec.c > > @@ -1752,13 +1752,14 @@ static int vdec_close(struct file *file) > > cancel_work_sync(&inst->delayed_process_work); > > v4l2_m2m_ctx_release(inst->m2m_ctx); > > v4l2_m2m_release(inst->m2m_dev); > > - vdec_ctrl_deinit(inst); > > ida_destroy(&inst->dpb_ids); > > hfi_session_destroy(inst); > > - mutex_destroy(&inst->lock); > > - mutex_destroy(&inst->ctx_q_lock); > > v4l2_fh_del(&inst->fh); > > v4l2_fh_exit(&inst->fh); > > + vdec_ctrl_deinit(inst); > Why vdec_ctrl_deinit ->v4l2_ctrl_handler_free(&inst->ctrl_handler) needs to > be called after v4l2_fh_exit? > Ideally it should be before v4l2_fh_exit. Because ->fh holds a pointer to ->ctrl_handler inst->fh.ctrl_handler = &inst->ctrl_handler so after vdec_ctrl_deinit() fh holds stale (released) data. In general destruction in reverse order of initialization is safer. init: init ctrl init fh // using ctrl de-init: release fh release ctrl
