Date: Thu, 20 Dec 2007 17:16:36 -0800 From: Sean Bruno <sbruno@miralink.com> To: Hidetoshi Shimokawa <simokawa@FreeBSD.ORG> Cc: freebsd-firewire@freebsd.org Subject: Re: sbp_targ memory leak Message-ID: <476B13F4.5050409@miralink.com> In-Reply-To: <626eb4530712182320q237c344crd309893a82fe8ef8@mail.gmail.com> References: <476610E5.2060108@miralink.com> <626eb4530712162258s4dfe1448o1102f20a623d3f95@mail.gmail.com> <476696C4.60408@miralink.com> <626eb4530712182320q237c344crd309893a82fe8ef8@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hidetoshi Shimokawa wrote: > I think you are right and page table is not freed when CAM_SEND_STATUS > is not set. > Maybe we should always free page tables if refcont == 0 rather than > free in sbp_targ_send_status(). > > You patch is not just adding debug printfs, right? > What is the mtx locks for? > > On 12/18/07, Sean Bruno <sbruno@miralink.com> wrote: > >> Hidetoshi Shimokawa wrote: >> >>> Thanks for the tracking of the problem. >>> Could you resend the patch in unified or context diff? >>> >>> Thanks, >>> >>> On 12/17/07, Sean Bruno <sbruno@miralink.com> 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 >>>> >>>> >>>> >>>> >> Diff updated at http://consultcsg.com/RELENG_6.diff >> >> Sean >> >> I moved the free around as you suggested and the memory leak does indeed go away and there are no further crashes. Here is my current diff --> http://consultcsg.com/RELENG_6.diff . It does look like the data is not being written or read to the backend correctly however. I.e. the page_table is not being setup correctly when more than one read or write is required to service an ORB. Any ideas on how to look into that? Sean
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?476B13F4.5050409>