linux-kernel - Re: [patch] [bugfix] loop.c

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: <Pine.LNX.4.64.0703231514000.5030@twin.jikos.cz>
Date:	Fri, 23 Mar 2007 15:18:33 +0100 (CET)
From:	Jiri Kosina <jikos@...os.cz>
To:	Tomas M <tomas@...x.org>
cc:	linux-kernel@...r.kernel.org
Subject: Re: [patch] [bugfix] loop.c

On Fri, 23 Mar 2007, Tomas M wrote:

> This is a bugfix for loop.c block driver, as it currently allocates more 
> memory then it needs, without any further use.
> If 'max_loop=255' parameter is given, the loop.c driver allocates this 
> amount of memory:
>   kmalloc(max_loop * sizeof(struct loop_device))
> But in this case, (max_loop * sizeof) is greater than 65536, and thus kmalloc
> must allocate the next bigger size (which is 128KB of RAM).

Which is very unlikely to work after some time of uptime, as the memory 
will be too fragmented to successfully kmalloc(128k). I guess that the 
code should be rather rewritten not to allocate such large contignuous 
chunks of memory through kmalloc().

-- 
Jiri Kosina
-
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/