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

Powered by blists - more mailing lists