From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1ECD9347FF8; Tue, 11 Nov 2025 01:07:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762823220; cv=none; b=ASTp4eujOMBooWTpobrTsl6lu59RZSuxGJEbHNWrLupesDmHroBs96asYEF5RiLqNDkAvGnzj6Mxh2+9PatYUd+rDoJJAqqdbygI9TZgU9LJvHiRQmLyVIAt5j5UK2Hlm6pOw5fHu2acDUcsu8rLm/u4xk0Mq1DoLx2xGtyhhNg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762823220; c=relaxed/simple; bh=Hk59xLn0zMHI9BHhHcCnOzcbsy3LVte2MDot1uTPgZ0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=rP/nRQC3/8FaS22zZWzNRJzWdC5FM8mdxKn2pmwpYmB7gmI6ArTd5mT2QpvVf307glnFxtjOa8WhqAYG12tyIgRXy0oe4q9lVW2cD5WVrKtSBGFXaLPNtHbeedD7nOlvNCSRKJo/5Gilkc7Iig016j2NLw/m3am9XmfURhG2aTg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=y9+Ii1hd; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="y9+Ii1hd" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A575EC19425; Tue, 11 Nov 2025 01:06:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1762823219; bh=Hk59xLn0zMHI9BHhHcCnOzcbsy3LVte2MDot1uTPgZ0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=y9+Ii1hd2yQRUQWGT19s0ct+ieAEkQCej19+mI4yyZ9ukqyfu1YkALRyXHVkn9+vw 9LmsdyHd4YNHK2Hkg7DiMjiOK1nAUpTK0ybeyZY7Wfp+/uLqeUaiQrDP3MIadEiCBw oGmCd59ZlVFUbqPsgT4XfSph9d2Jut6q27qYa3L0= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Laurent Pinchart , Ming Qian , Hans Verkuil , Sasha Levin Subject: [PATCH 6.12 199/565] media: amphion: Delete v4l2_fh synchronously in .release() Date: Tue, 11 Nov 2025 09:40:55 +0900 Message-ID: <20251111004531.405601401@linuxfoundation.org> X-Mailer: git-send-email 2.51.2 In-Reply-To: <20251111004526.816196597@linuxfoundation.org> References: <20251111004526.816196597@linuxfoundation.org> User-Agent: quilt/0.69 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: patches@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 6.12-stable review patch. If anyone has any objections, please let me know. ------------------ From: Laurent Pinchart [ Upstream commit 19fb9c5b815f70eb90d5b545f65b83bc9c490ecd ] 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 Reviewed-by: Ming Qian Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin --- 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 f0b1ec79d2961..7f66bfef2abbe 100644 --- a/drivers/media/platform/amphion/vpu_v4l2.c +++ b/drivers/media/platform/amphion/vpu_v4l2.c @@ -709,8 +709,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); @@ -779,6 +777,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; } @@ -798,6 +798,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.51.0