Re: cdevpriv and mmap(2)

From: Robert Watson <rwatson_at_FreeBSD.org>
Date: Sun, 14 Sep 2008 20:15:04 +0100 (BST)
On Sun, 14 Sep 2008, Kostik Belousov wrote:

> When implementing cdevpriv, I completeley missed the support for d_mmap() 
> driver method. This method is called by the kernel (at least) twice: one 
> time to validate the mmaped region and protection mode (see 
> vm/device_pager.c:dev_pager_alloc()), and second time to obtain the physical 
> address when serving page fault (see dev_pager_getpages()).
>
> Support for cdevpriv for the first call(s) is trivial, and is implemented by 
> the patch below. Second calls are much harder and essentially require 
> attaching cdevpriv bookkeeping data to the struct vm_map_entry. In fact, I 
> am not sure whether this support for the second time calls is needed at all 
> in real usage.
>
> I Cc:ed people that pointed me to the issue, please evaluate the patch 
> against your needs. I think I will commit it shortly after your feedback. On 
> the other hand, I would think about implementing full support for d_mmap 
> only if actually needed.

I'm not really sure that these changes "make sense" given the way our device 
pager works right now.  My understanding is that most consumers of cdevpriv 
use it in order to provide session-centric device nodes as a cleaner 
alternative to cloning.  However, even with your change, it's not possible to 
support session-centric memory mapping of devices as the memory map and device 
pager code assumes there is one VM object for each device, and hence all pages 
mapped independently from different file descriptors on the same device are 
from the same set of pages (and hence in the same VM object page cache).  In 
order to implement session-centric semantics, I think it's actually quite a 
bit more complicated than just adding vm_map_entry book-keeping -- we also 
need to have a different VM object for each session.

And, arguably, we need a more mature device_pager that understands that pages 
might someday no longer be associated with a device due to that device being 
removed...

Robert N M Watson
Computer Laboratory
University of Cambridge


>
> Thanks !
>
> diff --git a/sys/vm/vm_mmap.c b/sys/vm/vm_mmap.c
> index 7e6b04f..c3f08b0 100644
> --- a/sys/vm/vm_mmap.c
> +++ b/sys/vm/vm_mmap.c
> _at__at_ -391,8 +391,10 _at__at_ map:
> 		goto done;
> 	}
>
> +	td->td_fpop = fp;
> 	error = vm_mmap(&vms->vm_map, &addr, size, prot, maxprot,
> 	    flags, handle_type, handle, pos);
> +	td->td_fpop = NULL;
> #ifdef HWPMC_HOOKS
> 	/* inform hwpmc(4) if an executable is being mapped */
> 	if (error == 0 && handle_type == OBJT_VNODE &&
>
Received on Sun Sep 14 2008 - 17:15:05 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:35 UTC