Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753963Ab0DYTgS (ORCPT ); Sun, 25 Apr 2010 15:36:18 -0400 Received: from kroah.org ([198.145.64.141]:57386 "EHLO coco.kroah.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753724Ab0DYTgR (ORCPT ); Sun, 25 Apr 2010 15:36:17 -0400 Date: Sun, 25 Apr 2010 12:36:58 -0700 From: Greg KH To: Tomas Winkler Cc: Johannes Berg , Kay Sievers , David Woodhouse , "Rafael J. Wysocki" , Emmanuel Grumbach , linux-kernel@vger.kernel.org Subject: Re: request_firmware API exhaust memory Message-ID: <20100425193658.GA24039@kroah.com> References: <20100419145934.GA10893@kroah.com> <20100425163711.GA20196@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1857 Lines: 43 On Sun, Apr 25, 2010 at 10:22:54PM +0300, Tomas Winkler wrote: > On Sun, Apr 25, 2010 at 7:37 PM, Greg KH wrote: > > On Thu, Apr 22, 2010 at 01:22:51AM +0300, Tomas Winkler wrote: > >> On Mon, Apr 19, 2010 at 5:59 PM, Greg KH wrote: > >> > On Mon, Apr 19, 2010 at 03:20:34PM +0300, Tomas Winkler wrote: > >> >> Lately we've been developing a device that rather more extensively > >> >> used request_firmware API in load and also using pm_notifiers to load > >> >> firmware. > >> > > >> > Do you have a pointer to your driver source anywhere that shows how you > >> > are trying to use the firmware api in this manner? > >> > >> I've attached a very simple ??test driver I'm using. ??Just wanted to > >> eliminate anything else. > >> Bellow is a little script that loads and releases the firmware. My > >> previous observation was wrong. > >> The free memory gradually decreases regardless of number or dangling > >> udevd forks, which are eventually collected if the sleep period is > >> long enough ~10s. > > > > That sounds normal for the free memory. ??Kay, that's also to be expected > > for the udevd forks as well, right? > > Sorry maybe I was not clear what I mean that the memory will be > eventually exhausted and system will crash > Is this normal? Ah, no, that's not normal. Have you run kmemleak on your module (or test module) to verify that you are properly freeing up the memory? > Actually I less suspect now udevd as the same happens on android > platform where there is no udev Which is a sad thing for a whole other range of issues... thanks, greg k-h -- 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/