From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 11 01:35:59 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 06DB71065670; Mon, 11 Jan 2010 01:35:59 +0000 (UTC) (envelope-from tinguely@casselton.net) Received: from casselton.net (casselton.net [63.165.140.2]) by mx1.freebsd.org (Postfix) with ESMTP id 9CBC98FC14; Mon, 11 Jan 2010 01:35:58 +0000 (UTC) Received: from casselton.net (localhost [127.0.0.1]) by casselton.net (8.14.3/8.14.3) with ESMTP id o0B1ZvoD071841; Sun, 10 Jan 2010 19:35:57 -0600 (CST) (envelope-from tinguely@casselton.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=casselton.net; s=ccnMail; t=1263173757; bh=4J5IBzmAbBNs62fmn5g2lD7hnOmYKopvzMJNvVAgk0I=; h=Date:From:Message-Id:To:Subject:Cc:In-Reply-To; b=D4IMXHnjgRieLSxEmKgbvqpo2uz26NOic5KmXtc7OA45l/cQv+xaz3msLEQf5Qgek LnqC0RYeWmIzBQaBOnFV+d2xa8K0+MDqVcf2HWLeToF0GPTJ+S8YckOyPTkN5riEJS LceV7cWq8AIx5TBsz1ru95UqSCJY8mMVKuwTvJMc= Received: (from tinguely@localhost) by casselton.net (8.14.3/8.14.2/Submit) id o0B1ZuIR071840; Sun, 10 Jan 2010 19:35:56 -0600 (CST) (envelope-from tinguely) Date: Sun, 10 Jan 2010 19:35:56 -0600 (CST) From: Mark Tinguely Message-Id: <201001110135.o0B1ZuIR071840@casselton.net> To: freebsd-hackers@freebsd.org, max@love2party.net In-Reply-To: <201001102112.59479.max@love2party.net> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.2 (casselton.net [127.0.0.1]); Sun, 10 Jan 2010 19:35:57 -0600 (CST) X-Mailman-Approved-At: Mon, 11 Jan 2010 02:30:41 +0000 Cc: tinguely@casselton.net Subject: Re: bus_dmamap_load_uio() and user data X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2010 01:35:59 -0000 > > Ahh. I think bus_dmamap_load_uio() doesn't do deferred callbacks (i.e. > > mandates BUS_DMA_NOWAIT), and probably is always invoked from curthread. > > Even in the case of aio, the thread's vmspace is the effective one at the > > time bus_dmamap_load_uio() would be invoked, so in practice it is safe. > > I ran into ?this? problem with bus_dmamap_sync and bounce buffers while trying > to do a BUS_DMASYNC_POSTREAD in interrupt context. The sync code was trying > to copy from bounce buffer to the UVA without proper context -> SEGFAULT. I > tried to move the sync to the ioctl context that is used by the userland to > figure out which part of the buffer is "ready" ... this /kind of/ worked, but > lead to DMA problems in ata (which I didn't yet investigate) when trying to > write the buffer to disk. > > I meanwhile moved to exporting a kernel buffer instead, using OBJT_SG - which > is a bit more work and eats KVA, but at least on amd64 there is no shortage of > that. > > -- > Max Thank-you for the information. If it is possible for the user context to be inactive in the DMA routines, (as you pointed out the interrupt context) then I was thinking we would have to: 1) include the pmap in the bounce buffer structures in busdma_load_buffer(). 2) if pmap is not kernel pmap, and not equal to the current pmap then a) map physical page in current pmap b) copy from buffer using the new mapping unfortunately, it is possible one of the L2 cache is VIPT which will introducing page color issue and requiring every color KVAs. we have the same situation in the bus dma sync routine. I will see if those with this hardware would put a test case for inactive user pmap into the code. We would see it more often in cache syncing than just happen to trip over bounce buffer situation. --Mark Tinguely.