Date: Wed, 14 Jul 2010 09:46:30 -0400 From: John Baldwin <jhb@freebsd.org> To: pebu3op@googlemail.com Cc: Perforce Change Reviews <perforce@freebsd.org> Subject: Re: PERFORCE change 180741 for review Message-ID: <201007140946.30672.jhb@freebsd.org> In-Reply-To: <201007141432.33140.pebu3op@googlemail.com> References: <201007110309.o6B39Lr2057896@repoman.freebsd.org> <201007121013.30769.jhb@freebsd.org> <201007141432.33140.pebu3op@googlemail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201007140946.30672.jhb>