From owner-svn-src-head@FreeBSD.ORG Fri May 30 15:51:42 2014 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A18D2CD; Fri, 30 May 2014 15:51:42 +0000 (UTC) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) (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 764602420; Fri, 30 May 2014 15:51:41 +0000 (UTC) Received: by mail-we0-f176.google.com with SMTP id q59so2154631wes.21 for ; Fri, 30 May 2014 08:51:39 -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=h8gc5cdCXUW3khzU4B3IrjVavaf8Fhc4WM0kBJ+jz/8=; b=vpMRMgearK8SsK+NdkJYq5Jrp8W9ZDwnK+B923il4Kq94xBx/dDaN+vFbL55EuMQLu eJhXlr7evHv1cgWGVHUc8uNOw+IkoyRU5uU79FHJAIBlgJXBUxAAhesPVRjVVzPUXJbE KU+k7j+ngl+sye4S8VIX7TmjH1Z0siRAlxPBbgWgvtZyET6MQp4UXRPotfCFz2JPCQ3m /JhrY3D5AcQEGYN3U7Cmvu0SIAObWAXm/aFxzm9k2fMyexTe/EOo1ENMayQwatYgcK5S ZVexlBC8Whe7iYGJm0nmsbYmXYg2jOjr22Xit3V27eJUuIiubAnWKk7gpdKcMDcIGeQK dgBw== MIME-Version: 1.0 X-Received: by 10.181.8.67 with SMTP id di3mr8081271wid.8.1401465098830; Fri, 30 May 2014 08:51:38 -0700 (PDT) Reply-To: attilio@FreeBSD.org Sender: asmrookie@gmail.com Received: by 10.217.61.196 with HTTP; Fri, 30 May 2014 08:51:38 -0700 (PDT) In-Reply-To: <201405301147.46872.jhb@freebsd.org> References: <201405272131.s4RLVBEU035321@svn.freebsd.org> <201405301103.11980.jhb@freebsd.org> <201405301147.46872.jhb@freebsd.org> Date: Fri, 30 May 2014 17:51:38 +0200 X-Google-Sender-Auth: UNRXeJU9dwNugudsPO8GXvkGdfo 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-head@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 15:51:42 -0000 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. Attilio -- Peace can only be achieved by understanding - A. Einstein