PERFORCE change 180741 for review

[John Baldwin]

On Wednesday, July 14, 2010 8:32:32 am Alexander Fiveg wrote:
> On Monday 12 July 2010 16:13:30 you wrote:
> > On Saturday, July 10, 2010 11:09:21 pm Alexandre Fiveg wrote:
> > > http://p4web.freebsd.org/@@180741?ac=10
> > >
> > > Change 180741 by afiveg at cottonmouth on 2010/07/11 03:08:49
> > >
> > > 	d_mmap is eliminated from ringmap because of very strange behavior. 
Now:
> >
> > user-space process calls read(/dev/ringmap ... ) in order get physical
> > addres of ring. Then by calling mmap(/dev/mem, .... ,
> > offset=ring_phys_addr) the ring will be mapped into user-space.
> >
> > Oof, this is not appropriate.  You should use d_mmap.  Can you provide 
more
> > details on the problems you see with d_mmap?
> 
> 
> yes, it was a lot of problems. The first one: 
> - after calling mmap(2) (in user-space) the d_mmap() (in kernel) will be 
> called TWO times! In the first run of d_mmap() the current-thread can access 
> the private data that was previously set by devfs_set_cdevpriv(9) in the 
> d_open(). But after the first run the  d_mmap() will somehow (unexpected) 
> called again. In the second run it can NOT access private data and returns 
> with error in the user-space. The call of devfs_get_cdevpriv() in the second 
> run of d_mmap() returned error.

Yes, the first call is done at mmap() time, the second call happens when a 
page fault occurs on a mapped page.

> It was not really a big problem for me. The data needed in the d_mmap() is 
> stored in the SLIST which head is accessible through ringmap structure. But 
> traverse the SLIST in order to search our data... boring :) if we can use 
> devfs_* functions.

It may be boring, but it will only happen once per page.  Once a mapping for a 
device object is set via d_mmap() during a page fault, that physical address 
is remembered until the device is destroyed via destroy_dev().

If you are allocating buffers and sharing them to userland via d_mmap() and 
later freeing them, then you probably should be using d_mmap_single() instead 
of plain d_mmap() due to the issues with device VM objects caching mappings 
basically forever.

-- 
John Baldwin