On Wed, Dec 15, 2010 at 12:05:31AM -0500, Ted Unangst wrote:
> there is no reason for drm_bufs to be poking inside the vmspace on its
> own, this is what the uvm_map_hint function is for.
Yup, that's fine.
This was in place in this initial import of this code, suprised i've not
noticed and cleaned it up yet.
Please do put it in.
>
> Index: drm_bufs.c
> ===================================================================
> RCS file: /cvs/src/sys/dev/pci/drm/drm_bufs.c,v
> retrieving revision 1.46
> diff -u -r1.46 drm_bufs.c
> --- drm_bufs.c 15 Dec 2010 04:59:52 -0000 1.46
> +++ drm_bufs.c 15 Dec 2010 05:04:30 -0000
> @@ -922,7 +922,6 @@
> {
> struct drm_device_dma *dma = dev->dma;
> struct drm_buf_map *request = data;
> - struct vmspace *vms;
> struct vnode *vn;
> vaddr_t address, vaddr;
> voff_t foff;
> @@ -933,8 +932,6 @@
> if (!vfinddev(file_priv->kdev, VCHR, &vn))
> return EINVAL;
>
> - vms = curproc->p_vmspace;
> -
> rw_enter_write(&dma->dma_lock);
> dev->dma->buf_use++; /* Can't allocate more after this call */
> rw_exit_write(&dma->dma_lock);
> @@ -960,8 +957,8 @@
> foff = 0;
> }
>
> - vaddr = round_page((vaddr_t)vms->vm_daddr + BRKSIZ);
> - retcode = uvm_mmap(&vms->vm_map, &vaddr, size,
> + vaddr = uvm_map_hint(curproc, VM_PROT_READ | VM_PROT_WRITE);
> + retcode = uvm_mmap(&curproc->p_vmspace->vm_map, &vaddr, size,
> UVM_PROT_READ | UVM_PROT_WRITE, UVM_PROT_ALL, MAP_SHARED,
> (caddr_t)vn, foff, curproc->p_rlimit[RLIMIT_MEMLOCK].rlim_cur,
> curproc);
--
In Pocataligo, Georgia, it is a violation for a woman over 200 pounds
and attired in shorts to pilot or ride in an airplane.
