From owner-freebsd-arch@FreeBSD.ORG Tue Apr 28 14:47:50 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5CB0A1BD; Tue, 28 Apr 2015 14:47:50 +0000 (UTC) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 22876176C; Tue, 28 Apr 2015 14:47:50 +0000 (UTC) Received: by obbeb7 with SMTP id eb7so109723254obb.3; Tue, 28 Apr 2015 07:47:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=mKS1Vuc2xwpr85kVpktLCtktynSHmLjCBPWh5fmR2uw=; b=yA+AnwvOvYvgIEwmzNS9YbrhIscZH2N3BLeMBkS0FiunpIbEml04iOyQnd2bdHhSwj C+pnjNx2n8dfhUpCfH3sQFdcEUEtBaFQ99mTX6fy3546Pj4S3Wq2HGqjlKCtJGZl+q4S h6pptbbTS6S0OcmtHny6vV5JCutgygXh5wr+a+cZjhPUxSo3RHAsMyQ3HTSh+u2PJQw1 WzYH4tl2H7hU/8MWkN9afJ2JXe/7LtxJuxE3M2zhILREfSUH8ROG6gQGipPCiPJaxI3s nT/QN5u2eAtgEyfQD/zlRlRsTMZISz7fMGMmetuPQi1N2AdErdSXeLqByaXmMxaNb3IU 6mtQ== X-Received: by 10.202.225.65 with SMTP id y62mr13884239oig.78.1430232469407; Tue, 28 Apr 2015 07:47:49 -0700 (PDT) Received: from corona.austin.rr.com (cpe-72-177-6-10.austin.res.rr.com. [72.177.6.10]) by mx.google.com with ESMTPSA id ph19sm9959705oeb.9.2015.04.28.07.47.48 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Apr 2015 07:47:48 -0700 (PDT) Message-ID: <553F9DE2.5080908@gmail.com> Date: Tue, 28 Apr 2015 09:49:06 -0500 From: Jason Harmening User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: John Baldwin , freebsd-arch@freebsd.org CC: Konstantin Belousov , Svatopluk Kraus Subject: Re: bus_dmamap_sync() for bounced client buffers from user address space References: <553B9E64.8030907@gmail.com> <20150425163444.GL2390@kib.kiev.ua> <1876382.0PQNo3Rp24@ralph.baldwin.cx> In-Reply-To: <1876382.0PQNo3Rp24@ralph.baldwin.cx> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="FdFxoWkPFWu4kEMfT2l2KniOuEbJax1dd" 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 14:47:50 -0000 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--