Re: [PATCHv2] videobuf2-core: take mmap_sem before calling __qbuf_userptr

[Jan Kara]

On Fri 22-08-14 23:31:31, Hans Verkuil wrote:
> (Changes since v1: fix the embarrassing bug where mmap_sem wasn't initialized)
> 
> Commit f035eb4e976ef5a059e30bc91cfd310ff030a7d3 (videobuf2: fix lockdep 
> warning)
> unfortunately removed the mmap_sem lock that is needed around the call to
> __qbuf_userptr. Amazingly nobody noticed this (especially me as the author)
> until Jan Kara pointed this out to me.
> 
> Signed-off-by: Hans Verkuil <hans.verk...@cisco.com>
> Reported-by: Jan Kara <j...@suse.cz>
  The patch looks good to me. You can add:
Reviewed-by: Jan Kara <j...@suse.cz>
        
                                                                Honza

> ---
>  drivers/media/v4l2-core/videobuf2-core.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
> b/drivers/media/v4l2-core/videobuf2-core.c
> index 5b808e2..a0ab6af 100644
> --- a/drivers/media/v4l2-core/videobuf2-core.c
> +++ b/drivers/media/v4l2-core/videobuf2-core.c
> @@ -1591,6 +1591,7 @@ static void __enqueue_in_driver(struct vb2_buffer *vb)
>  static int __buf_prepare(struct vb2_buffer *vb, const struct v4l2_buffer *b)
>  {
>       struct vb2_queue *q = vb->vb2_queue;
> +     struct rw_semaphore *mmap_sem;
>       int ret;
>  
>       ret = __verify_length(vb, b);
> @@ -1627,7 +1628,10 @@ static int __buf_prepare(struct vb2_buffer *vb, const 
> struct v4l2_buffer *b)
>               ret = __qbuf_mmap(vb, b);
>               break;
>       case V4L2_MEMORY_USERPTR:
> +             mmap_sem = &current->mm->mmap_sem;
> +             down_read(mmap_sem);
>               ret = __qbuf_userptr(vb, b);
> +             up_read(mmap_sem);
>               break;
>       case V4L2_MEMORY_DMABUF:
>               ret = __qbuf_dmabuf(vb, b);
> -- 
> 2.0.1
> 
-- 
Jan Kara <j...@suse.cz>
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html