From owner-freebsd-arm@FreeBSD.ORG Tue Aug 7 16:09:53 2012 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B0B94106566C for ; Tue, 7 Aug 2012 16:09:53 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [76.96.30.32]) by mx1.freebsd.org (Postfix) with ESMTP id 908378FC14 for ; Tue, 7 Aug 2012 16:09:52 +0000 (UTC) Received: from omta07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by qmta03.emeryville.ca.mail.comcast.net with comcast id jo651j0031GXsucA3s9mZ4; Tue, 07 Aug 2012 16:09:46 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta07.emeryville.ca.mail.comcast.net with comcast id js9l1j00J4NgCEG8Us9ldh; Tue, 07 Aug 2012 16:09:46 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q77G9hdj008330; Tue, 7 Aug 2012 10:09:43 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: John Baldwin In-Reply-To: <201208061026.06328.jhb@freebsd.org> References: <20120703111753.GB72292@server.rulingia.com> <20120708110516.GA38312@server.rulingia.com> <201207120826.05577.jhb@freebsd.org> <201208061026.06328.jhb@freebsd.org> Content-Type: text/plain; charset="us-ascii" Date: Tue, 07 Aug 2012 10:09:42 -0600 Message-ID: <1344355782.1128.186.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: arm@freebsd.org, mips@freebsd.org, Peter Jeremy Subject: Re: On-stack allocation of DMA S/G lists X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 16:09:53 -0000 On Mon, 2012-08-06 at 10:26 -0400, John Baldwin wrote: > On Thursday, July 12, 2012 8:26:05 am John Baldwin wrote: > > On Sunday, July 08, 2012 7:05:16 am Peter Jeremy wrote: > > > BTW(2): Whilst studying busdma_machdep.c for arm and mips, I've > > > noticed they appear to potentially allocate substantial kernel stack > > > under some conditions as several bus_dma(9) functions include: > > > bus_dma_segment_t dm_segments[dmat->nsegments]; > > > What prevents this overflowing the kernel stack? > > > > That does seem dubious. x86 stores the array in the tag instead. > > I have an untested patch to change bus-dma on arm and mips to allocate a > dynamic S/G list in each DMA tag on first use instead of using on-stack > allocation (which I think is rather bogus). Can folks review and test this > patch please? Thanks. > > http://www.FreeBSD.org/~jhb/patches/arm_mips_dynamic_dma_segs.patch > I'm worried about changing a per-mapping-call resource to a per-dma-tag resource here. What prevents the situation where you have two bus_dmamap_load() calls in progress at the same time using different buffers but the same tag? I can't find anything in the docs that indicates you have to provide external locking of the tag for map load/unload calls, or that even implies the tag can be modified by a mapping operation. The lockfunc stuff related to creating the tag is documented as being used only during a deferred callback. The existing code seems to go out of its way to avoid modifying the tag during a mapping operation. For example, it decides at tag creation time whether any bounce pages might ever be needed for the tag, and if so it pre-sets a bounce zone in the tag, then at mapping time the bounce zone is protected with its own lock when it gets modified. To me this feels like a way to specifically avoid the need to lock or modify the tag during a mapping operation. Assuming that all of the foregoing is moot for some reason I've overlooked, then on a purely implementation level, could all the duplicated code to allocate the array when necessary be moved into bus_dmamap_load_buffer(), triggered by a NULL 'segs' pointer? And just for the record, looking at the problem from an even more distant vantage... is there really a problem with stack-allocating the segments? On a 64-bit arch the struct is like 16 bytes. Typical usage is to allocate a tag allowing 1 or just a few segments. Is anyone really going to create a tag specifying hundreds of segments that would overflow the stack? If they try, wouldn't failing the tag create be good enough? -- Ian