From owner-freebsd-firewire@FreeBSD.ORG Mon Dec 17 06:58:54 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 C91B616A419 for ; Mon, 17 Dec 2007 06:58:54 +0000 (UTC) (envelope-from freebsd@gm.nunu.org) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.191]) by mx1.freebsd.org (Postfix) with ESMTP id B439313C461 for ; Mon, 17 Dec 2007 06:58:54 +0000 (UTC) (envelope-from freebsd@gm.nunu.org) Received: by rv-out-0910.google.com with SMTP id l15so1982991rvb.43 for ; Sun, 16 Dec 2007 22:58:53 -0800 (PST) Received: by 10.142.212.19 with SMTP id k19mr271462wfg.193.1197874733573; Sun, 16 Dec 2007 22:58:53 -0800 (PST) Received: by 10.142.224.12 with HTTP; Sun, 16 Dec 2007 22:58:53 -0800 (PST) Message-ID: <626eb4530712162258s4dfe1448o1102f20a623d3f95@mail.gmail.com> Date: Mon, 17 Dec 2007 15:58:53 +0900 From: "Hidetoshi Shimokawa" Sender: freebsd@gm.nunu.org To: "Sean Bruno" In-Reply-To: <476610E5.2060108@miralink.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <476610E5.2060108@miralink.com> X-Google-Sender-Auth: ae82b4ba317c02df Cc: freebsd-firewire@freebsd.org Subject: Re: 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:58:54 -0000 Thanks for the tracking of the problem. Could you resend the patch in unified or context diff? Thanks, On 12/17/07, Sean Bruno wrote: > 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 > > > -- /\ Hidetoshi Shimokawa \/ simokawa@FreeBSD.ORG