From owner-svn-src-all@FreeBSD.ORG Fri May 30 16:55:10 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 193285E7; Fri, 30 May 2014 16:55:10 +0000 (UTC) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (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 DE3002A22; Fri, 30 May 2014 16:55:08 +0000 (UTC) Received: by mail-wg0-f42.google.com with SMTP id y10so2237123wgg.25 for ; Fri, 30 May 2014 09:55:07 -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=aUm1T1nASgXtQ8rkBmzO+3agl5xCkeFcYBMmOcJcOM4=; b=YkNHGpoE9le0NUmThbYDPOdgfcl1khhpWTSOjhcOmOUNG8lVfM5WCpDeICnojxBWsk pOwvH67n4eT/AzaRbewaNjhTL1L+2Mll6SR7TR2TA4jMvuFblV3q++pfuealaFW6Bzdp C63ufYzh286STHcfStTrHy2SI6Zin2Aa+uMmGFojaaDRq2KaFLrT3zu57L9zysQLb1kd jFWySv2SqfrKqd30c5MK6koJ+83lMnwT3ybOPdv3HGSXgYMNFHGZc/s6Puds3xJJYzdC eFMFLgcOWagDxN74cfmRqh52/VBeG8HUzw5+/FtTeFr88OtMjiLq0BmwJ12zZ2zZ0vnw wkfw== MIME-Version: 1.0 X-Received: by 10.194.7.232 with SMTP id m8mr23948565wja.47.1401468906173; Fri, 30 May 2014 09:55:06 -0700 (PDT) Reply-To: attilio@FreeBSD.org Sender: asmrookie@gmail.com Received: by 10.217.61.196 with HTTP; Fri, 30 May 2014 09:55:06 -0700 (PDT) In-Reply-To: <201405301244.07316.jhb@freebsd.org> References: <201405272131.s4RLVBEU035321@svn.freebsd.org> <201405301147.46872.jhb@freebsd.org> <201405301244.07316.jhb@freebsd.org> Date: Fri, 30 May 2014 18:55:06 +0200 X-Google-Sender-Auth: owgUQMcGubFhIXsjqdUqzZSR1Lg 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 16:55:10 -0000 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). That was prompted to look at the dma_alloc_*() bits of drivers. We need to make a real sweep at drivers on these bits. > > TL;DR: > > - Scott's change did not introduce any new behavior so we don't need to > worry about a spate of new bugs uncovered in drivers because of it. Not entirely true. For ATA it was before a panic and now it is a silent memory leak. For other drivers it may be the opposite. I could just find this one becaue I got bitten by it. Attilio -- Peace can only be achieved by understanding - A. Einstein