Date: Sat, 25 Apr 2015 19:34:44 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Jason Harmening <jason.harmening@gmail.com> Cc: Svatopluk Kraus <onwahe@gmail.com>, FreeBSD Arch <freebsd-arch@freebsd.org> Subject: Re: bus_dmamap_sync() for bounced client buffers from user address space Message-ID: <20150425163444.GL2390@kib.kiev.ua> In-Reply-To: <553B9E64.8030907@gmail.com> References: <CAFHCsPXMjge84AR2cR8KXMXWP4kH2YvuV_uqtPKUvn5C3ygknw@mail.gmail.com> <CAM=8qan-4SbKJaddrfkv=HG3n%2BHaOPDL5MEPS9DoaTvnhrJPZQ@mail.gmail.com> <20150425094152.GE2390@kib.kiev.ua> <553B9E64.8030907@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. I believe UIO_USERSPACE is almost unused, it might be there for some obscure (and buggy) driver.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150425163444.GL2390>