Date: Mon, 27 Aug 2012 15:31:42 -0400 From: John Baldwin <jhb@freebsd.org> To: freebsd-arch@freebsd.org Cc: Ian Lepore <freebsd@damnhippie.dyndns.org>, Mark Tinguely <marktinguely@gmail.com>, Hans Petter Selasky <hans.petter.selasky@bitfrost.no>, freebsd-arm@freebsd.org, freebsd-mips@freebsd.org, Konstantin Belousov <kostikbel@gmail.com> Subject: Re: Partial cacheline flush problems on ARM and MIPS Message-ID: <201208271531.42725.jhb@freebsd.org> In-Reply-To: <20120827185346.GE33100@deviant.kiev.zoral.com.ua> References: <FD8DC82C-AD3B-4EBC-A625-62A37B9ECBF1@bsdimp.com> <10307B47-13F3-45C0-87F7-66FD3ACA3F86@bsdimp.com> <20120827185346.GE33100@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201208271531.42725.jhb>