From owner-freebsd-firewire@FreeBSD.ORG Mon Dec 17 06:02:16 2007 Return-Path: Delivered-To: freebsd-firewire@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B3D316A419; Mon, 17 Dec 2007 06:02:16 +0000 (UTC) (envelope-from sbruno@miralink.com) Received: from plato.miralink.com (mail.miralink.com [70.103.185.20]) by mx1.freebsd.org (Postfix) with ESMTP id 103C913C44B; Mon, 17 Dec 2007 06:02:16 +0000 (UTC) (envelope-from sbruno@miralink.com) Received: from localhost (localhost.localdomain [127.0.0.1]) by plato.miralink.com (Postfix) with ESMTP id B83961C818D; Sun, 16 Dec 2007 22:02:15 -0800 (PST) Received: from plato.miralink.com ([127.0.0.1]) by localhost (plato.miralink.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25446-10; Sun, 16 Dec 2007 22:02:14 -0800 (PST) Received: from [10.47.1.118] (vpn.office.miralink.com [10.0.0.5]) by plato.miralink.com (Postfix) with ESMTP id 6F1931C8180; Sun, 16 Dec 2007 22:02:14 -0800 (PST) Message-ID: <476610E5.2060108@miralink.com> Date: Sun, 16 Dec 2007 22:02:13 -0800 From: Sean Bruno User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: freebsd-firewire@freebsd.org, Hidetoshi Shimokawa Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DSPAM-Result: Innocent X-DSPAM-Processed: Sun Dec 16 22:02:15 2007 X-DSPAM-Confidence: 0.9997 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 476610e715761214584237 X-DSPAM-Factors: 27, X-Virus-Scanned: amavisd-new at X-Spam-Status: No, score=-4.499 tagged_above=-10 required=6.6 autolearn=ham tests=[ALL_TRUSTED=-1.8, BAYES_00=-2.599, DSPAM_HAM=-0.1] X-Spam-Score: -4.499 X-Spam-Level: Cc: Subject: sbp_targ memory leak X-BeenThere: freebsd-firewire@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Firewire support in FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2007 06:02:16 -0000 In trying to understand and make sbp_targ functional, I've noted that the code seems to lose track of how many page tables it allocates for any give orbi. I had to add a lot of debugging code around the malloc/free's to find out what was going on, and I'm not sure what the code is supposed to do in this case. Please review the patch diff at --> http://consultcsg.com/RELENG_6.diff And the log at -->http://consultcsg.com/malloc_failure.txt This clearly shows that a new page table is being allocated for the same IO operation, which should be fine, but then a second malloc is attempted and stored in the same variable effectively leaking the data. I'm sure that this type of operation is supposed to be possible, but my interpretation of SBP-2 is suspect! :) Sean