All of lore.kernel.org
 help / color / mirror / Atom feed
From: Archit Taneja <archit@ti.com>
To: "Hiremath, Vaibhav" <hvaibhav@ti.com>
Cc: "Valkeinen, Tomi" <tomi.valkeinen@ti.com>,
	"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
	"Semwal, Sumit" <sumit.semwal@ti.com>,
	"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>
Subject: Re: [PATCH 1/5] [media]: OMAP_VOUT: Fix check in reqbuf & mmap for buf_size allocation
Date: Wed, 21 Sep 2011 16:19:38 +0530	[thread overview]
Message-ID: <4E79C142.80508@ti.com> (raw)
In-Reply-To: <19F8576C6E063C45BE387C64729E739404EC941E1C@dbde02.ent.ti.com>

Hi,

On Wednesday 21 September 2011 02:10 PM, Hiremath, Vaibhav wrote:
>
>> -----Original Message-----
>> From: Taneja, Archit
>> Sent: Friday, September 16, 2011 3:30 PM
>> To: Hiremath, Vaibhav
>> Cc: Valkeinen, Tomi; linux-omap@vger.kernel.org; Semwal, Sumit; linux-
>> media@vger.kernel.org; Taneja, Archit
>> Subject: [PATCH 1/5] [media]: OMAP_VOUT: Fix check in reqbuf&  mmap for
>> buf_size allocation
>>
>> The commit 383e4f69879d11c86ebdd38b3356f6d0690fb4cc makes reqbuf and mmap
>> prevent
>> requesting a larger size buffer than what is allocated at kernel boot
>> during
>> omap_vout_probe.
>>
>> The requested size is compared with vout->buffer_size, this isn't correct
>> as
>> vout->buffer_size is later set to the size requested in reqbuf. When the
>> video
>> device is opened the next time, this check will prevent us to allocate a
>> buffer
>> which is larger than what we requested the last time.
>>
>> Don't use vout->buffer_size, always check with the parameters
>> video1_bufsize
>> or video2_bufsize.
>>
>> Signed-off-by: Archit Taneja<archit@ti.com>
>> ---
>>   drivers/media/video/omap/omap_vout.c |   10 ++++++++--
>>   1 files changed, 8 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/media/video/omap/omap_vout.c
>> b/drivers/media/video/omap/omap_vout.c
>> index 95daf98..e14c82b 100644
>> --- a/drivers/media/video/omap/omap_vout.c
>> +++ b/drivers/media/video/omap/omap_vout.c
>> @@ -664,10 +664,14 @@ static int omap_vout_buffer_setup(struct
>> videobuf_queue *q, unsigned int *count,
>>   	u32 phy_addr = 0, virt_addr = 0;
>>   	struct omap_vout_device *vout = q->priv_data;
>>   	struct omapvideo_info *ovid =&vout->vid_info;
>> +	int vid_max_buf_size;
>>
>>   	if (!vout)
>>   		return -EINVAL;
>>
>> +	vid_max_buf_size = vout->vid == OMAP_VIDEO1 ? video1_bufsize :
>> +		video2_bufsize;
>> +
>>   	if (V4L2_BUF_TYPE_VIDEO_OUTPUT != q->type)
>>   		return -EINVAL;
>>
>> @@ -690,7 +694,7 @@ static int omap_vout_buffer_setup(struct
>> videobuf_queue *q, unsigned int *count,
>>   		video1_numbuffers : video2_numbuffers;
>>
>>   	/* Check the size of the buffer */
>> -	if (*size>  vout->buffer_size) {
>> +	if (*size>  vid_max_buf_size) {
> Good catch !!!
>
>>   		v4l2_err(&vout->vid_dev->v4l2_dev,
>>   				"buffer allocation mismatch [%u] [%u]\n",
>>   				*size, vout->buffer_size);
>> @@ -865,6 +869,8 @@ static int omap_vout_mmap(struct file *file, struct
>> vm_area_struct *vma)
>>   	unsigned long size = (vma->vm_end - vma->vm_start);
>>   	struct omap_vout_device *vout = file->private_data;
>>   	struct videobuf_queue *q =&vout->vbq;
>> +	int vid_max_buf_size = vout->vid == OMAP_VIDEO1 ? video1_bufsize :
>> +		video2_bufsize;
>>
>>   	v4l2_dbg(1, debug,&vout->vid_dev->v4l2_dev,
>>   			" %s pgoff=0x%lx, start=0x%lx, end=0x%lx\n", __func__,
>> @@ -887,7 +893,7 @@ static int omap_vout_mmap(struct file *file, struct
>> vm_area_struct *vma)
>>   		return -EINVAL;
>>   	}
>>   	/* Check the size of the buffer */
>> -	if (size>  vout->buffer_size) {
>> +	if (size>  vid_max_buf_size) {
> Don't you think in case of mmap we should still check for the
> vout->buffer_size, since this is the size user has requested in req_buf.

Ah, you are right, the check for the maximum size should only be in the 
reqbuf path. vout->buffer_size would have been updated correctly at time 
of mmap. I'll change this back to vout->buffer_size.

Thanks,
Archit

>
> Thanks,
> Vaibhav
>
>
>>   		v4l2_err(&vout->vid_dev->v4l2_dev,
>>   				"insufficient memory [%lu] [%u]\n",
>>   				size, vout->buffer_size);
>> --
>> 1.7.1
>
>


  reply	other threads:[~2011-09-21 10:47 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-16 10:00 [PATCH 0/5] [media]: OMAP_VOUT: Misc fixes and cleanup patches for 3.2 Archit Taneja
2011-09-16 10:00 ` Archit Taneja
2011-09-16 10:00 ` [PATCH 1/5] [media]: OMAP_VOUT: Fix check in reqbuf & mmap for buf_size allocation Archit Taneja
2011-09-16 10:00   ` Archit Taneja
2011-09-21  8:40   ` Hiremath, Vaibhav
2011-09-21 10:49     ` Archit Taneja [this message]
2011-09-16 10:00 ` [PATCH 2/5] [media]: OMAP_VOUT: CLEANUP: Remove redundant code from omap_vout_isr Archit Taneja
2011-09-16 10:00   ` Archit Taneja
2011-09-21 10:05   ` Hiremath, Vaibhav
2011-09-21 10:45     ` Archit Taneja
2011-09-26  5:34       ` Archit Taneja
2011-09-16 10:00 ` [PATCH 3/5] [media]: OMAP_VOUT: Fix VSYNC IRQ handling in omap_vout_isr Archit Taneja
2011-09-16 10:00   ` Archit Taneja
2011-09-21 13:34   ` Hiremath, Vaibhav
2011-09-22  6:15     ` Archit Taneja
2011-09-26 10:19       ` Hiremath, Vaibhav
     [not found]         ` <CAB2ybb8ab9jSFB1J_CQfObB11QcdtQ=6Kf9zdbg0v5Jckf09sw@mail.gmail.com>
     [not found]           ` <CAB2ybb-rZgDvS9Bo6AJF=KVd0irXHa0S0LrPJ=SWr0daJ6gX1w@mail.gmail.com>
2011-09-27  5:41             ` Semwal, Sumit
2011-09-27  5:41               ` Semwal, Sumit
2011-09-27  6:39               ` Hiremath, Vaibhav
2011-09-27  6:49                 ` Tomi Valkeinen
2011-09-27  6:54                   ` Hiremath, Vaibhav
2011-09-27  7:01                     ` Archit Taneja
2011-09-27  7:09                       ` Hiremath, Vaibhav
2011-09-27  7:05                     ` Tomi Valkeinen
2011-09-27  6:51                 ` Semwal, Sumit
2011-09-27  6:51                   ` Semwal, Sumit
2011-09-16 10:00 ` [PATCH 4/5] [media] OMAP_VOUT: Add support for DSI panels Archit Taneja
2011-09-16 10:00   ` Archit Taneja
2011-09-16 10:00 ` [PATCH 5/5] [media]: OMAP_VOUT: Don't trigger updates in omap_vout_probe Archit Taneja
2011-09-16 10:00   ` Archit Taneja

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=4E79C142.80508@ti.com \
    --to=archit@ti.com \
    --cc=hvaibhav@ti.com \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=sumit.semwal@ti.com \
    --cc=tomi.valkeinen@ti.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.