From owner-freebsd-arch@FreeBSD.ORG Tue Apr 28 13:45:10 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1A28BD3B for ; Tue, 28 Apr 2015 13:45:10 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E88CD1FD4 for ; Tue, 28 Apr 2015 13:45:09 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-54-116-245.nwrknj.fios.verizon.net [173.54.116.245]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id CF0B4B93C; Tue, 28 Apr 2015 09:45:07 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org Cc: Konstantin Belousov , Jason Harmening , Svatopluk Kraus Subject: Re: bus_dmamap_sync() for bounced client buffers from user address space Date: Tue, 28 Apr 2015 09:40:33 -0400 Message-ID: <1876382.0PQNo3Rp24@ralph.baldwin.cx> User-Agent: KMail/4.14.2 (FreeBSD/10.1-STABLE; KDE/4.14.2; amd64; ; ) In-Reply-To: <20150425163444.GL2390@kib.kiev.ua> References: <553B9E64.8030907@gmail.com> <20150425163444.GL2390@kib.kiev.ua> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 28 Apr 2015 09:45:07 -0400 (EDT) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 13:45:10 -0000 On Saturday, April 25, 2015 07:34:44 PM Konstantin Belousov wrote: > On Sat, Apr 25, 2015 at 09:02:12AM -0500, Jason Harmening wrote: > > It seems like in general it is too hard for drivers using busdma to deal > > with usermode memory in a way that's both safe and efficient: > > --bus_dmamap_load_uio + UIO_USERSPACE is apparently really unsafe > > --if they do things the other way and allocate in the kernel, then then > > they better either be willing to do extra copying, or create and > > refcount their own vm_objects and use d_mmap_single (I still haven't > > seen a good example of that), or leak a bunch of memory (if they use > > d_mmap), because the old device pager is also really unsafe. > munmap(2) does not free the pages, it removes the mapping and dereferences > the backing vm object. If the region was wired, munmap would decrement > the wiring count for the pages. So if a kernel code wired the regions > pages, they are kept wired, but no longer mapped into the userspace. > So bcopy() still does not work. > > d_mmap_single() is used by GPU, definitely by GEM and TTM code, and possibly > by the proprietary nvidia driver. Yes, the nvidia driver uses it. I've also used it for some proprietary driver extensions. > I believe UIO_USERSPACE is almost unused, it might be there for some > obscure (and buggy) driver. I believe it was added (and only ever used) in crypto drivers, and that they all did bus_dma operations in the context of the thread that passed in the uio. I definitely think it is fragile and should be replaced with something more reliable. -- John Baldwin