bug-hurd
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]