Linux Media Controller development
 help / color / mirror / Atom feed
From: hverkuil+cisco@kernel.org
To: Nicolas Dufresne <nicolas@ndufresne.ca>,
	Younho Choi <gdool88@mju.ac.kr>,
	linux-media@vger.kernel.org
Cc: mchehab@kernel.org, laurent.pinchart@ideasonboard.com,
	sakari.ailus@linux.intel.com, benjamin.gaignard@collabora.com,
	ysk@kzalloc.com, kees@kernel.org, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org
Subject: Re: [PATCH] media: vim2m: keep transaction buffer count stable while streaming
Date: Tue, 8 Sep 2026 12:02:52 +0200	[thread overview]
Message-ID: <a2b33cbd-f16e-4e42-ad5d-053ad94f7a46@kernel.org> (raw)
In-Reply-To: <71a3fa9710cf1afbb80ebe850878557c3e95a1b2.camel@ndufresne.ca>

On 16/07/2026 00:14, Nicolas Dufresne wrote:
> Hi,
> 
> Le mardi 26 mai 2026 à 21:22 +0900, Younho Choi a écrit :
>> V4L2_CID_TRANS_NUM_BUFS controls how many buffer pairs a vim2m
>> mem2mem job processes before the job is completed. The driver stores
>> the value in ctx->translen and device_work() uses it later to decide
>> whether the current transaction should continue.
>>
>> Letting userspace change this control while streaming is active can
>> make a queued job observe a different transaction length than the one
>> it started with. That leaves the transaction state inconsistent with
>> the buffers currently queued for the job.
>>
>> Grab the transaction buffer count control while either queue is
>> streaming, and release it only after both queues have stopped
>> streaming. The V4L2 control framework then rejects changes with
>> -EBUSY while the value is in use, while still allowing userspace to
>> configure the value before streaming starts.
>>
>> Keep the control handler alive until after v4l2_m2m_ctx_release(),
>> since releasing the mem2mem context can call stop_streaming(), which
>> now ungrabs the control.
>>
>> Fixes: 96d8eab5d0a1 ("V4L/DVB: [v5,2/2] v4l: Add a mem-to-mem videobuf
>> framework test device")
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Younho Choi <gdool88@mju.ac.kr>
> 
> I think this patch make sense, though I was pretty surprise of the private
> control offset, which I've tracked down to an undocumented change made by Hans
> in 2017. I've delegated this patch to him so we can sort this out first.

Actually, that was 2012.

I suspect that at that time we didn't yet reserve control ranges in v4l2-controls.h.

In any case, we're in a bit of luck in that the 0x1000-0x100f range is reserved in
v4l2-controls.h for the removed meye driver. Best solution is to just add a new
#define V4L2_CID_USER_VIM2M_BASE there. No control IDs have to change, so this is
safe.

I'll post a patch for that.

Regards,

	Hans

> 
> Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
> 
>> ---
>>  drivers/media/test-drivers/vim2m.c | 29 ++++++++++++++++++++++++++---
>>  1 file changed, 26 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/media/test-drivers/vim2m.c b/drivers/media/test-
>> drivers/vim2m.c
>> index bb2dd11eef0e..f4a2c4083829 100644
>> --- a/drivers/media/test-drivers/vim2m.c
>> +++ b/drivers/media/test-drivers/vim2m.c
>> @@ -205,6 +205,7 @@ struct vim2m_ctx {
>>  	struct vim2m_dev	*dev;
>>  
>>  	struct v4l2_ctrl_handler hdl;
>> +	struct v4l2_ctrl	*trans_num_bufs_ctrl;
>>  
>>  	/* Processed buffers in this transaction */
>>  	u8			num_processed;
>> @@ -1258,9 +1259,27 @@ static int vim2m_start_streaming(struct vb2_queue *q,
>> unsigned int count)
>>  		ctx->aborting = 0;
>>  
>>  	q_data->sequence = 0;
>> +	v4l2_ctrl_grab(ctx->trans_num_bufs_ctrl, true);
>> +
>>  	return 0;
>>  }
>>  
>> +static bool vim2m_other_queue_is_streaming(struct vim2m_ctx *ctx,
>> +					   struct vb2_queue *q)
>> +{
>> +	struct vb2_queue *other_vq;
>> +
>> +	if (!ctx->fh.m2m_ctx)
>> +		return false;
>> +
>> +	if (V4L2_TYPE_IS_OUTPUT(q->type))
>> +		other_vq = v4l2_m2m_get_dst_vq(ctx->fh.m2m_ctx);
>> +	else
>> +		other_vq = v4l2_m2m_get_src_vq(ctx->fh.m2m_ctx);
>> +
>> +	return vb2_is_streaming(other_vq);
>> +}
>> +
>>  static void vim2m_stop_streaming(struct vb2_queue *q)
>>  {
>>  	struct vim2m_ctx *ctx = vb2_get_drv_priv(q);
>> @@ -1274,11 +1293,14 @@ static void vim2m_stop_streaming(struct vb2_queue *q)
>>  		else
>>  			vbuf = v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
>>  		if (!vbuf)
>> -			return;
>> +			break;
>>  		v4l2_ctrl_request_complete(vbuf->vb2_buf.req_obj.req,
>>  					   &ctx->hdl);
>>  		v4l2_m2m_buf_done(vbuf, VB2_BUF_STATE_ERROR);
>>  	}
>> +
>> +	if (!vim2m_other_queue_is_streaming(ctx, q))
>> +		v4l2_ctrl_grab(ctx->trans_num_bufs_ctrl, false);
>>  }
>>  
>>  static void vim2m_buf_request_complete(struct vb2_buffer *vb)
>> @@ -1380,7 +1402,8 @@ static int vim2m_open(struct file *file)
>>  
>>  	vim2m_ctrl_trans_time_msec.def = default_transtime;
>>  	v4l2_ctrl_new_custom(hdl, &vim2m_ctrl_trans_time_msec, NULL);
>> -	v4l2_ctrl_new_custom(hdl, &vim2m_ctrl_trans_num_bufs, NULL);
>> +	ctx->trans_num_bufs_ctrl =
>> +		v4l2_ctrl_new_custom(hdl, &vim2m_ctrl_trans_num_bufs, NULL);
>>  	if (hdl->error) {
>>  		rc = hdl->error;
>>  		v4l2_ctrl_handler_free(hdl);
>> @@ -1435,10 +1458,10 @@ static int vim2m_release(struct file *file)
>>  
>>  	v4l2_fh_del(&ctx->fh, file);
>>  	v4l2_fh_exit(&ctx->fh);
>> -	v4l2_ctrl_handler_free(&ctx->hdl);
>>  	mutex_lock(&dev->dev_mutex);
>>  	v4l2_m2m_ctx_release(ctx->fh.m2m_ctx);
>>  	mutex_unlock(&dev->dev_mutex);
>> +	v4l2_ctrl_handler_free(&ctx->hdl);
>>  	kfree(ctx);
>>  
>>  	atomic_dec(&dev->num_inst);
>>
>> base-commit: 5d6919055dec134de3c40167a490f33c74c12581


      reply	other threads:[~2026-09-08 10:03 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-26 12:22 [PATCH] media: vim2m: keep transaction buffer count stable while streaming Younho Choi
2026-07-15 22:14 ` Nicolas Dufresne
2026-09-08 10:02   ` hverkuil+cisco [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a2b33cbd-f16e-4e42-ad5d-053ad94f7a46@kernel.org \
    --to=hverkuil+cisco@kernel.org \
    --cc=benjamin.gaignard@collabora.com \
    --cc=gdool88@mju.ac.kr \
    --cc=kees@kernel.org \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@kernel.org \
    --cc=nicolas@ndufresne.ca \
    --cc=sakari.ailus@linux.intel.com \
    --cc=stable@vger.kernel.org \
    --cc=ysk@kzalloc.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox