Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753088Ab0D0MFo (ORCPT ); Tue, 27 Apr 2010 08:05:44 -0400 Received: from mail-bw0-f219.google.com ([209.85.218.219]:39773 "EHLO mail-bw0-f219.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752473Ab0D0MFn convert rfc822-to-8bit (ORCPT ); Tue, 27 Apr 2010 08:05:43 -0400 MIME-Version: 1.0 In-Reply-To: References: <20100419145934.GA10893@kroah.com> <20100425163711.GA20196@kroah.com> <20100425193658.GA24039@kroah.com> <1272295140.2434.8.camel@yio.site> From: Kay Sievers Date: Tue, 27 Apr 2010 14:05:25 +0200 Message-ID: Subject: Re: request_firmware API exhaust memory To: Tomas Winkler Cc: Greg KH , Johannes Berg , David Woodhouse , "Rafael J. Wysocki" , Emmanuel Grumbach , linux-kernel@vger.kernel.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1582 Lines: 37 On Tue, Apr 27, 2010 at 13:18, Tomas Winkler 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/