Date: Sat, 25 Apr 2015 12:07:29 -0500 From: Jason Harmening <jason.harmening@gmail.com> To: Konstantin Belousov <kostikbel@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: <553BC9D1.1070502@gmail.com> In-Reply-To: <20150425163444.GL2390@kib.kiev.ua> References: <CAFHCsPXMjge84AR2cR8KXMXWP4kH2YvuV_uqtPKUvn5C3ygknw@mail.gmail.com> <CAM=8qan-4SbKJaddrfkv=HG3n%2BHaOPDL5MEPS9DoaTvnhrJPZQ@mail.gmail.com> <20150425094152.GE2390@kib.kiev.ua> <553B9E64.8030907@gmail.com> <20150425163444.GL2390@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --o69MO6Bb4S2i7LQq19KNltmn3TMAc9FfI Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 04/25/15 11:34, 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 de= al >> 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 the= n >> 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 dereferen= ces > 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. Ok, my question wasn't whether munmap frees the pages, but whether it accounts for wire count when attempting to remove the mapping. It doesn't, so yes bcopy will be unsafe. > > d_mmap_single() is used by GPU, definitely by GEM and TTM code, and pos= sibly > by the proprietary nvidia driver. > > I believe UIO_USERSPACE is almost unused, it might be there for some > obscure (and buggy) driver. It may be nearly unused, but we still document it in busdma.9, and we still explicitly check for it when setting the pmap in _bus_dmamap_load_uio. If it's not safe to use, then it's not OK for us to do that. We need to either a) remove support for it by adding a failure/KASSERT on UIO_USERSPACE in _busdmamap_load_uio() and remove the paragraph on it from busdma.9, or b) make it safe. I'd be in favor of b), because I think it is still valid to support some non-painful way of using DMA with userspace buffers. Right now, the only safe way to do that seems to be: 1) vm_fault_quick_hold_pages 2) kva_alloc 3) pmap_qenter 4) bus_dmamap_load That seems both unnecessarily complex and wasteful of KVA space. --o69MO6Bb4S2i7LQq19KNltmn3TMAc9FfI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJVO8nRXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwAAoJELufi/mShB0bLo8IAIcGMrX09DjmKnhFf0k4ujDE iPoxNlN20mT9Ai1GlmSG4roVTHgBR4F2JSESZO/Mu14bDzmfCpzM0qbnojT1Ig2d CK6/WCmE8RzkjdOHJvWKjZrX7bBdbscizXlL+NW4enpaCkMAHxcSeQDEZrdQmJ5q Dce2fzwxDNdKRpr8rGt0t52+ikuaiYTKb+nxOOH5xUus5VlLEky5aBSD/Zbm2YQx yiZd4URYYmeY2f6Gcku7OExeRqLnNkmGIgYHxoHX1Qdw4PJy60LAQztzG792wnEa YLYTzEXN10ro2mlDF+179hceGqYKGBrPBSva2qLX5s1mCCHSx//HuKzkQdMs7i8= =KqVS -----END PGP SIGNATURE----- --o69MO6Bb4S2i7LQq19KNltmn3TMAc9FfI--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?553BC9D1.1070502>