linux-kernel - Re: [PATCH] [media] videobuf-dma-contig: replace vm_iomap_memory() with remap_pfn

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 24 Sep 2014 14:40:59 +0200
From:	Marek Szyprowski <m.szyprowski@...sung.com>
To:	Hans Verkuil <hverkuil@...all.nl>,
	Fancy Fang <chen.fang@...escale.com>, m.chehab@...sung.com,
	viro@...IV.linux.org.uk
Cc:	shawn.guo@...escale.com, linux-media@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] [media] videobuf-dma-contig: replace vm_iomap_memory()
 with remap_pfn_range().

Hello,

On 2014-09-10 09:00, Hans Verkuil wrote:
> On 09/10/14 07:28, Fancy Fang wrote:
>> When user requests V4L2_MEMORY_MMAP type buffers, the videobuf-core
>> will assign the corresponding offset to the 'boff' field of the
>> videobuf_buffer for each requested buffer sequentially. Later, user
>> may call mmap() to map one or all of the buffers with the 'offset'
>> parameter which is equal to its 'boff' value. Obviously, the 'offset'
>> value is only used to find the matched buffer instead of to be the
>> real offset from the buffer's physical start address as used by
>> vm_iomap_memory(). So, in some case that if the offset is not zero,
>> vm_iomap_memory() will fail.
> Is this just a fix for something that can fail theoretically, or do you
> actually have a case where this happens? I am very reluctant to make
> any changes to videobuf. Drivers should all migrate to vb2.
>
> I have CC-ed Marek as well since he knows a lot more about this stuff
> than I do.

I'm sorry for a delay, I was really busy with other things.

>> Signed-off-by: Fancy Fang <chen.fang@...escale.com>
>> ---
>>   drivers/media/v4l2-core/videobuf-dma-contig.c | 4 +++-
>>   1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/media/v4l2-core/videobuf-dma-contig.c b/drivers/media/v4l2-core/videobuf-dma-contig.c
>> index bf80f0f..8bd9889 100644
>> --- a/drivers/media/v4l2-core/videobuf-dma-contig.c
>> +++ b/drivers/media/v4l2-core/videobuf-dma-contig.c
>> @@ -305,7 +305,9 @@ static int __videobuf_mmap_mapper(struct videobuf_queue *q,
>>   	/* Try to remap memory */
>>   	size = vma->vm_end - vma->vm_start;
>>   	vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
>> -	retval = vm_iomap_memory(vma, mem->dma_handle, size);
>> +	retval = remap_pfn_range(vma, vma->vm_start,
>> +				 mem->dma_handle >> PAGE_SHIFT,
>> +				 size, vma->vm_page_prot);
>>   	if (retval) {
>>   		dev_err(q->dev, "mmap: remap failed with error %d. ",
>>   			retval);

I think we don't need to revert the code to use remap_pfn_range() again 
(like
it was in pre v3.10 times). The simplest way will be to correctly fix
vma->vm_pgoff and set it to zero before calling vm_iomap_memory(). It is
done the same way in vb2_dma_contig.c:vb2_dc_mmap().

To sum up - please change your patch: keep vm_iomap_memory() call and add
"vma->vm_pgoff = 0;" line before it with suitable comment.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/