From owner-freebsd-arch@FreeBSD.ORG Mon Aug 27 19:31:53 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0A4EE106568A; Mon, 27 Aug 2012 19:31:53 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id CDF9E8FC15; Mon, 27 Aug 2012 19:31:52 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 0C5F3B983; Mon, 27 Aug 2012 15:31:52 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org Date: Mon, 27 Aug 2012 15:31:42 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <10307B47-13F3-45C0-87F7-66FD3ACA3F86@bsdimp.com> <20120827185346.GE33100@deviant.kiev.zoral.com.ua> In-Reply-To: <20120827185346.GE33100@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201208271531.42725.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 27 Aug 2012 15:31:52 -0400 (EDT) Cc: Ian Lepore , Mark Tinguely , Hans Petter Selasky , freebsd-arm@freebsd.org, freebsd-mips@freebsd.org, Konstantin Belousov Subject: Re: Partial cacheline flush problems on ARM and MIPS X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 19:31:53 -0000 On Monday, August 27, 2012 2:53:46 pm Konstantin Belousov wrote: > On Sun, Aug 26, 2012 at 05:13:31PM -0600, Warner Losh wrote: > > > > On Aug 26, 2012, at 12:25 PM, Ian Lepore wrote: > > > In this regard, it's the busdma implementation that's broken, because it > > > should bounce those IOs through a DMA-safe buffer. There's absolutely > > > no rule that I've ever heard of in FreeBSD that says IO can only take > > > place using memory allocated from busdma. > > > > That's partially true. Since BUSDMA grew up in the storage area, you > > must allocate the memory from busdma, or it must be page aligned has > > been the de-facto rule here. The mbuf and uio variants of load were > > invented to cope with common cases of mbufs and user I/O to properly > > flag things. > > I once looked at x86 bus_dmamap_load_uio(), and I was unable to > understand how to use it with usermode uio. I think this is a good > moment to ask. Most existing users use UIO_SYSSPACE, but several crypto > drivers might allow the UIO_USERSPACE for them. > > For UIO_USERSPACE, if the page is not resident, the pmap_extract() call from > _bus_dmamap_load_buffer() returns 0. So the i/o happens to the page > located at 0, which contains real mode IVT and other BIOS sensitive tables. > > Worse, if the page is resident, but it is mapped at the region which > requires COW on write, then DMA will be performed to the wrong page > which is typically shared with other innocent users. to the COW area > which was not yet copied, > > Am I missing some trick there ? No. The caller is required to wire the pages first in some manner. In general bus_dmamap_load_uio() isn't a good idea. I do believe the crypto drivers are careful to wire the buffer first. I think requiring the caller to wire is the only sane way that can be used. Also, doing DMA to a stack variable is absolutely horrible for a related reason since presumably the thread will block while it waits for the DMA to complete, and a sleeping thread can be swapped out (including having it's stack swapped out). -- John Baldwin