AFAICS, videobuf-vmalloc use of mem->vma and mem->vmalloc is
bogus.
You obtain the latter with vmalloc_user(); so far, so good. Then you have
retval=remap_vmalloc_range(vma, mem->vmalloc,0);
where vma is given to you by mmap(); again, fine - we get the memory
pointed to be mem->vmalloc() mapped at vma->vm_start.
Now we get the trouble: things like
static void vivi_fillbuff(struct vivi_dev *dev,struct vivi_buffer *buf)
{
...
void *vbuf=videobuf_to_vmalloc (&buf->vb);
...
copy_to_user(vbuf + ..., ..., ...)
get vbuf equal to ->vmalloc of buf->vp.priv and that is _not_ a userland
address. Giving it to copy_to_user() is not going to do anything good.
On some targets it'll fail, on some - write to unrelated user memory.
What is going on there? If that's an attempt to copy into that buffer
allocated by vmalloc_user(), why are we doing copy_to_user() at all?
But there's more; we have made a copy of vma (kmalloc+memcpy), stored it in
mem->vma and later we cheerfully do remap_vmalloc_range(mem->vma,....).
And kfree that mem->vma immediately afterwards. What the hell? It might
not break now, but that seems to be playing very fast and loose with the
warranties provided by VM.
-
| Greg KH | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Greg Kroah-Hartman | [PATCH 001/196] Chinese: Add the known_regression URI to the HOWTO |
| Andy Whitcroft | clam |
| Ingo Molnar | [patch] paravirt: VDSO page is essential |
git: | |
| David Miller | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| Lovich, Vitali | RE: [PATCH] Packet socket: mmapped IO: PACKET_TX_RING |
| David Miller | [GIT]: Networking |
