linux-kernel - Re: request_firmware API exhaust memory

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <z2iac3eb2511004190535pa4209f50n80708879a6b705e1@mail.gmail.com>
Date:	Mon, 19 Apr 2010 14:35:13 +0200
From:	Kay Sievers <kay.sievers@...y.org>
To:	Tomas Winkler <tomasw@...il.com>
Cc:	Johannes Berg <johannes@...solutions.net>,
	Greg KH <greg@...ah.com>,
	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 Mon, Apr 19, 2010 at 14:20, Tomas Winkler <tomasw@...il.com> 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. In some stress  testing the usage will exhaust the system
> memory. First we suspected there is a memory leak in the
> firwmare_class but eventually what is that udevd piles up it takes
> time to collect the process.

What version of the kernel, and what version of udev?

> We loose ~ 500K for each
> request/release_firmware iteration.

You mean you lose 500k, not taken by any process?

> After the stress the process table will will look something like shown below,

What are these processes doing (strace)? Do they have child processes?
If yes, what are they doing (strace)?

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/