From owner-p4-projects@FreeBSD.ORG Wed Jul 14 15:28:12 2010 Return-Path: Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id BEDBB1065677; Wed, 14 Jul 2010 15:28:11 +0000 (UTC) Delivered-To: perforce@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 835171065672 for ; Wed, 14 Jul 2010 15:28:11 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 53AAA8FC20 for ; Wed, 14 Jul 2010 15:28:11 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id DFAD146B45; Wed, 14 Jul 2010 11:28:10 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 73DCB8A03C; Wed, 14 Jul 2010 11:28:09 -0400 (EDT) From: John Baldwin To: pebu3op@googlemail.com Date: Wed, 14 Jul 2010 09:46:30 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100217; KDE/4.4.5; amd64; ; ) References: <201007110309.o6B39Lr2057896@repoman.freebsd.org> <201007121013.30769.jhb@freebsd.org> <201007141432.33140.pebu3op@googlemail.com> In-Reply-To: <201007141432.33140.pebu3op@googlemail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201007140946.30672.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 14 Jul 2010 11:28:09 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Perforce Change Reviews Subject: Re: PERFORCE change 180741 for review X-BeenThere: p4-projects@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: p4 projects tree changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 15:28:12 -0000 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