linux-kernel - Re: max

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]

Date:	Thu, 22 Mar 2007 14:42:31 +0100
From:	Jens Axboe <jens.axboe@...cle.com>
To:	Eric Dumazet <dada1@...mosbay.com>
Cc:	Tomas M <tomas@...x.org>, linux-kernel@...r.kernel.org
Subject: Re: max_loop limit

On Thu, Mar 22 2007, Eric Dumazet wrote:
> On Thu, 22 Mar 2007 12:37:54 +0100
> Tomas M <tomas@...x.org> wrote:
> 
> > The question is not "Why do we need more than 255 loops?".
> > The question should be "Why do we need the hardcoded 255-limit in kernel 
> > while there is no reason for it at all?"
> > 
> > My patch simply removes the hardcoded limitation.
> 
> Hello Tomas, welcome !
> 
> Well, its an attempt to remove a hardcoded limit, but as you said in the Changelog, it really depends on kmalloc() being able to allocate a large continous memory zone. Alas it might fail.
> The golden rule is to avoid all allocations larger than PAGE_SIZE :)
> 
> On x86_64, sizeof(struct loop_device) is 368, so the 'new limit' would be 356 instead of 256...
> 
> You might want a more radical patch : 
> 
> Instead of using :
> 
> static struct loop_device *loop_dev;
> loop_dev = kmalloc(max_loop * sizeof(struct loop_device));
> 
> Switch to :
> 
> static struct loop_device **loop_dev;
> loop_dev = kmalloc(max_loop * sizeof(void *));
> if (!loop_dev) rollback...
> for (i = 0 ; i < max_loop ; i++) {
> 	loop_dev[i] = kmalloc(sizeof(struct loop_device));
> 	if (!loop_dev[i]) rollback...
> }
> 
> This time, you would be limited to 16384 loop devices on x86_64, 32768 on i386 :)

But this still wastes memory, why not just allocate each loop device
dynamically when it is set up? The current approach is crap, it is just
wasting memory for loop devices, queues, etc.

-- 
Jens Axboe

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