From owner-svn-src-all@FreeBSD.ORG Fri May 30 23:10:15 2014 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A94E6A45; Fri, 30 May 2014 23:10:15 +0000 (UTC) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7B27F29D4; Fri, 30 May 2014 23:10:14 +0000 (UTC) Received: by mail-wi0-f177.google.com with SMTP id f8so1918372wiw.10 for ; Fri, 30 May 2014 16:10:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=CodSFOAh/ofROA9uxCNOFBD7s3syfpGI1FNic7RUeEM=; b=ipcmBSChZO0GMUoZRxQwU6bgyXAPNnSLtzL3rkZcxThMlWE0a3HjvjXozdta7sQnl9 nWOdMG0OCBpKx0lIdrfI7H06iyVDk9Gfhdb50Vfdb1M6w42rD9+l1TwG6B4Uobm8r8Bb s2pqnmOwbGDG7vjJohct+2LSv8nBFnE4JKzChdBm+CjUYdF+awIs4z7nb38pGeAK2T5T rUC7rnqSlaimrZcharHcRsII4NNoPPlier15hp9r71BGf3zK3wJ+7Ohx+g+Z+ulQww0F Zc+5ukBZj+pIxzahf7jKS6HcqkU/o9gIhTsLc+sjjs3hGDVBGQYx6rj1y3CuT7ABqcgU etGQ== MIME-Version: 1.0 X-Received: by 10.180.126.97 with SMTP id mx1mr783782wib.29.1401491412752; Fri, 30 May 2014 16:10:12 -0700 (PDT) Reply-To: attilio@FreeBSD.org Sender: asmrookie@gmail.com Received: by 10.217.61.196 with HTTP; Fri, 30 May 2014 16:10:12 -0700 (PDT) In-Reply-To: <201405301406.42782.jhb@freebsd.org> References: <201405272131.s4RLVBEU035321@svn.freebsd.org> <201405301244.07316.jhb@freebsd.org> <201405301406.42782.jhb@freebsd.org> Date: Sat, 31 May 2014 01:10:12 +0200 X-Google-Sender-Auth: xhcGb-Zd5YjCDOaoiBqBb5VZqds Message-ID: Subject: Re: svn commit: r266775 - head/sys/x86/x86 From: Attilio Rao To: John Baldwin Content-Type: text/plain; charset=UTF-8 Cc: "src-committers@freebsd.org" , Benno Rice , "svn-src-all@freebsd.org" , Scott Long , "svn-src-head@freebsd.org" , "Peel, Casey" X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 23:10:15 -0000 On Fri, May 30, 2014 at 8:06 PM, John Baldwin wrote: > On Friday, May 30, 2014 12:55:06 pm Attilio Rao wrote: >> On Fri, May 30, 2014 at 6:44 PM, John Baldwin wrote: >> > On Friday, May 30, 2014 11:51:38 am Attilio Rao wrote: >> >> On Fri, May 30, 2014 at 5:47 PM, John Baldwin wrote: >> >> > On Friday, May 30, 2014 11:39:24 am Attilio Rao wrote: >> >> >> On Fri, May 30, 2014 at 5:03 PM, John Baldwin wrote: >> >> >> > On Friday, May 30, 2014 10:54:06 am Attilio Rao wrote: >> >> >> >> On Tue, May 27, 2014 at 11:31 PM, Scott Long > wrote: >> >> >> >> > Author: scottl >> >> >> >> > Date: Tue May 27 21:31:11 2014 >> >> >> >> > New Revision: 266775 >> >> >> >> > URL: http://svnweb.freebsd.org/changeset/base/266775 >> >> >> >> > >> >> >> >> > Log: >> >> >> >> > Eliminate the fake contig_dmamap and replace it with a new > flag, >> >> >> >> > BUS_DMA_KMEM_ALLOC. They serve the same purpose, but using the > flag >> >> >> >> > means that the map can be NULL again, which in turn enables > significant >> >> >> >> > optimizations for the common case of no bouncing. >> >> >> >> >> >> >> >> While I think this is in general a good idea, unfortunately our >> >> >> >> drivers do so many dumb things when freeing DMA allocated buffers > that >> >> >> >> having a NULL map is going to cause some "turbolence" and make such >> >> >> >> bugs more visible. >> >> >> >> An example is with ATA, where I think this fix is needed: >> >> >> >> http://www.freebsd.org/~attilio/dmamem_free-ata.patch >> >> >> >> >> >> >> >> Otherwise, what can happen with bounce buffers, is that the > allocated >> >> >> >> memory via contig malloc was not going to be freed anytime. >> >> >> >> >> >> >> >> I tried to look around and I found questionable (read broken) code > in >> >> >> >> basically every driver which allocates DMA buffers, so I really > don't >> >> >> >> feel I want to fix the majority of our drivers. I just think such >> >> >> >> paths are not excercised enough to be seen in practice often or the >> >> >> >> bugs just get unnoticed. >> >> >> > >> >> >> > Eh, many maps for static allocations were already NULL and have been > for a >> >> >> > long time. This is nothign new. Plus, the diff you posted has a > bug >> >> >> > regardless of explicitly destroying a map created by > bus_dmamem_alloc(). >> >> >> >> >> >> Did you notice that I *removed* the destroy not *added*? >> >> > >> >> > Yes, my point was that that bug in the original code you are fixing was > there >> >> > regardless of Scott's change. >> >> >> >> And when I did say something different? >> >> I don't understand what's the point of your messages, besides showing >> >> that you didn't read correctly my patch. >> > >> > I read yours correctly but worded mine poorly. My point is that Scott's >> > change does not introduce anything new. We've had NULL maps for static >> > allocations for many, many years. It's only been recently that we've >> > had more maps not be NULL for this. However, even if you discounted >> > the whole NULL vs non-NULL maps thing, the driver in question that you >> > are fixing was broken regardless. That is, due to the extra >> > bus_dmamap_destroy() the driver was broken regardless of whether the map >> > was NULL or non-NULL. >> >> To be honest, pre-266775 the kernel would actually panic for this >> specific driver, because we were going to free memory that was never >> allocated (by having a valid mapping but an invalid dma memory >> pointer). > > pre-239354 bus_dma would have used a NULL map just as it does now. And > even some allocations during that window could still use a NULL map. The > idea of a NULL map is not a new concept. Most maps from bus_dmamem_alloc() > have been NULL for most of bus_dma's existence. > >> That was prompted to look at the dma_alloc_*() bits of drivers. >> We need to make a real sweep at drivers on these bits. > > I did a start: http://p4web.freebsd.org/@@1194266?ac=10 I had converted if_alc.c, if_ale.c and e1000/ stuff before to give up. The first 2 looks good to me. Attilio -- Peace can only be achieved by understanding - A. Einstein