[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: memory leak in DMA buffers allocation?
From: |
Da Zheng |
Subject: |
Re: memory leak in DMA buffers allocation? |
Date: |
Sat, 13 Feb 2010 23:42:42 +0800 |
User-agent: |
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 |
Hi,
On 10-2-13 上午3:29, olafBuddenhagen@gmx.net wrote:
>
>> antrik said this implementation isn't consistent with Mach's memory
>> management and I should make it work like device_map, so there will be
>> a pager in the kernel. I basically agree with that. What should the
>> interface be? any suggestions?
>
> It should be something along these lines I think:
>
> kern_return_t mach_get_dma_pages (
> host_priv_t host_priv,
> vm_size_t size,
> mach_port_t *pager,
> vm_offset_t *phys_addr,
> mach_dma_flags_t flags
> )
>
> The last parameter would contain various options, like restricting to
> first 32 MiB of RAM (for ISA DMA) or first 4 GiB (for many other
> devices). Not sure whether we actually need any other options --
> otherwise, perhaps this should get a more specific name.
>
> "pager" returns a memory object, which can then be used in a vm_map()
> call. "phys_addr" returns the physical address of the allocated region,
> used to program the DMA hardware.
OK.
>
> BTW, I'm not sure about handling scatter-gather DMA. This still needs
> the physical addresses to be stable during the transfer, and available
> to the driver; but the region needn't be contiguous... So I guess we
> could just use "normal" memory (ideally passed directly from/to the
> clients); wire it; and use some other special function to obtain the
> physical addresses of each page.
Maybe it can work, but I'm still far from that right now:-)
>
>> + kfree (pages, npages * sizeof (vm_page_t));
>> + vm_pages_release (npages, pages, TRUE);
>
> This looks wrong -- freeing the "pages" array before using it to free
> the actual pages... But I doubt it is related to the problem you are
> experiencing, considering that this is just an error path.
Right, it's a bug.
>
> (Also, I don't think the extra vm_pages_release() function is really
> useful, considering that it's just a very simple loop, and used only in
> a single place... But here I am nitpicking again :-) )
I don't know why I did it. I cannot give a reason myself:-)
Zheng Da