[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <o2qac3eb2511004260338xd8146a7dy415d3f0f4f1c8bbc@mail.gmail.com>
Date: Mon, 26 Apr 2010 12:38:47 +0200
From: Kay Sievers <kay.sievers@...y.org>
To: Tomas Winkler <tomasw@...il.com>
Cc: Greg KH <greg@...ah.com>,
Johannes Berg <johannes@...solutions.net>,
David Woodhouse <dwmw2@...radead.org>,
"Rafael J. Wysocki" <rjw@...k.pl>,
Emmanuel Grumbach <egrumbach@...il.com>,
linux-kernel@...r.kernel.org
Subject: Re: request_firmware API exhaust memory
On Sun, Apr 25, 2010 at 22:09, Tomas Winkler <tomasw@...il.com> wrote:
> Said thing is that I don't see where the memory goes.... Anyhow I will
> try to run valgrin on udev just to be sure.
Nah, that memory would be freed, if you kill all udev processes, which
it doesn't.
The many udev worker processes you see for a few seconds was caused by
udevd handling events with TIMEOUT= set special. We need to make sure,
that firmware events run immediately and don't wait for other
processes to finish. The logic who does that was always creating a new
worker. I changed this now, but this will not affect the underlying
problem you are seeing, it will just make the udev workers not grow in
a timeframe of less than 10 seconds. The change is here:
http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h=665ee17def2caa6811ae032ae68ebf8239a18cf8
but as mentioned, this change is unrelated to the memory leak you are seeing.
> I'll be glad If someone can run my simple driver I posted and confirm
> that sees the same problem
I can confirm that memory gets lost. I suspect for some reason the
firmware does not get properly cleaned up. If you increase the size of
the firmware image, it will leak memory much faster.
Kay
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists