Date: Tue, 28 Apr 2015 09:49:06 -0500 From: Jason Harmening <jason.harmening@gmail.com> To: John Baldwin <jhb@freebsd.org>, freebsd-arch@freebsd.org Cc: Konstantin Belousov <kostikbel@gmail.com>, Svatopluk Kraus <onwahe@gmail.com> Subject: Re: bus_dmamap_sync() for bounced client buffers from user address space Message-ID: <553F9DE2.5080908@gmail.com> In-Reply-To: <1876382.0PQNo3Rp24@ralph.baldwin.cx> References: <CAFHCsPXMjge84AR2cR8KXMXWP4kH2YvuV_uqtPKUvn5C3ygknw@mail.gmail.com> <553B9E64.8030907@gmail.com> <20150425163444.GL2390@kib.kiev.ua> <1876382.0PQNo3Rp24@ralph.baldwin.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --FdFxoWkPFWu4kEMfT2l2KniOuEbJax1dd Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 04/28/15 08:40, John Baldwin wrote: > 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 d= eal >>> 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 th= en >>> 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 derefere= nces >> the backing vm object. If the region was wired, munmap would decremen= t >> 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 po= ssibly >> by the proprietary nvidia driver. > Yes, the nvidia driver uses it. I've also used it for some proprietary= > driver extensions. I've seen d_mmap_single() used in the GPU code, but I haven't seen it used in conjunction with busdma (but maybe not looking in the right place= ). > >> 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 some= thing > more reliable. > I think it's useful to make the bounce-buffering logic more robust in cases where it's not executed in the owning process; it's also a really simple set of changes. Of course doing vslock beforehand is still going to be the only safe way to use that API, but that seems reasonable if it's documented and done sparingly (which it is). In the longer term, vm_fault_quick_hold_pages + _bus_dmamap_load_ma is probably better for user buffers, at least for short transfers (which I think is most of them). load_ma needs to at least be made a public and documented KPI though. I'd like to try moving some of the drm2 code to use it once I finally have a reasonably modern machine for testing -curre= nt. Either _bus_dmamap_load_ma or out-of-context UIO_USERSPACE bounce buffering could have issues with waiting on sfbufs on some arches, including arm. That could be fixed by making each unmapped bounce buffer set up a kva mapping for the data addr when it's created, but that fix might be worse than the problem it's trying to solve. --FdFxoWkPFWu4kEMfT2l2KniOuEbJax1dd 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 iQF8BAEBCgBmBQJVP53iXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwAAoJELufi/mShB0bEIUIAN34JfagFVf9hR2fNWwHitxn pLO99FuzZCuf6WCS1eieMHPN0d0xNqnqTmKvVIQ+xbPO4dRhLSz+FhJQiwf5wSDl VCCdvSaVF4SJuASwiFzvG1XkSjMUJHvmJTIGROtqCkjvhY1qBDST/MPPJCtYbuU6 dbkoi4avwyrtVWelqcyA4HwQ09wPVSKl3p2HF9DXIwpGDFecf7y8FaHeflsopUja b/V5dwI/j1SLYls7rtgdjZ39kHX4iU4AjSuk2DY/yaRItgE6LPMa+YaTe9cz5Uhm lfhsZj8xPiTMRRt1/y5UI40taGcADz8h/mt7AmdE/SzLJjPYb82bRPKr7lhsy34= =NAS+ -----END PGP SIGNATURE----- --FdFxoWkPFWu4kEMfT2l2KniOuEbJax1dd--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?553F9DE2.5080908>