Messages in this thread | | | From | Kay Sievers <> | Date | Tue, 27 Apr 2010 14:05:25 +0200 | Subject | Re: request_firmware API exhaust memory |
| |
On Tue, Apr 27, 2010 at 13:18, Tomas Winkler <tomasw@gmail.com> wrote:
> The difference between vfree and vunmap is that vfree request for > deallocating the pages while vunmap leaves the pages allocated.
No, that's not the problem, as described in the earlier mail. Only if the are vmalloc'd they will ever get free'd. The kernel will not take over custom pages you just mapped. They will never get touched by vfree. The page count in the vm area will always be zero.
> I > don't think you can replace vfree with vunmap the way you did. > The transition from vmalloc to alloc_pages were done by the patch > bellow.
Sure, if you do vmap, you need to do vunmap, not vfree. But the pages you need to take care of yourself, like you have allocated them. vfree in that context makes only sense if you use vmalloc.
The patch I posted makes the issue go away. It's still not the right fix, because the pages are only get freed when the device id cleaned up, not on calling release_firmware. But it should illustrate the underlying issue, and that there is no leaked memory anymore.
> I think this needs some more review.
If David does not fix it, it probably just needs to be reverted. And instead of implementing our own "memory management", we should rather add a vrealloc(), and the firmware loader should use that.
Thanks, Kay -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |