Re: [patch] [bugfix] loop.c

2007-03-23 Thread Jiri Kosina
On Fri, 23 Mar 2007, Michael Tokarev wrote: > Speaking of which, I wonder... Here, and in many other places. > If some variable is marked as MODULE_PARAM (or whatever it is called > nowadays), used in module init routine, AND subsequently used for > various bound checks and loops... [...] > and

Re: [patch] [bugfix] loop.c

2007-03-23 Thread Michael Tokarev
Eric Dumazet wrote: [] > > MODULE_PARM_DESC(max_loop, "Maximum number of loop devices (1-16384)"); Speaking of which, I wonder... Here, and in many other places. If some variable is marked as MODULE_PARAM (or whatever it is called nowadays), used in module init routine, AND subsequently used fo

Re: [patch] [bugfix] loop.c

2007-03-23 Thread Al Viro
On Fri, Mar 23, 2007 at 03:48:09PM +0100, Eric Dumazet wrote: > On Fri, 23 Mar 2007 14:36:05 + > Al Viro <[EMAIL PROTECTED]> wrote: > > > On Fri, Mar 23, 2007 at 03:19:56PM +0100, Eric Dumazet wrote: > > > I cooked the following patch (untested), feel free to test it. > > > > Please, get the

Re: [patch] [bugfix] loop.c

2007-03-23 Thread Eric Dumazet
On Fri, 23 Mar 2007 15:25:23 +0100 (CET) Jiri Kosina <[EMAIL PROTECTED]> wrote: > On Fri, 23 Mar 2007, Eric Dumazet wrote: > > > - if (max_loop < 1 || max_loop > 256) { > > - printk(KERN_WARNING "loop: invalid max_loop (must be between" > > - " 1 and 256)

Re: [patch] [bugfix] loop.c

2007-03-23 Thread Al Viro
On Fri, Mar 23, 2007 at 02:41:09PM +, Christoph Hellwig wrote: > The right thing to start with is to split the allocation up, and allocate > each loop device by itself, like in the untested patch below: > > After that you're not wasting memory for any off number of loop devices > and can creat

Re: [patch] [bugfix] loop.c

2007-03-23 Thread Eric Dumazet
On Fri, 23 Mar 2007 14:36:05 + Al Viro <[EMAIL PROTECTED]> wrote: > On Fri, Mar 23, 2007 at 03:19:56PM +0100, Eric Dumazet wrote: > > I cooked the following patch (untested), feel free to test it. > > Please, get the cleanup into saner shape. This is too ugly. out_mem: while (nba--)

Re: [patch] [bugfix] loop.c

2007-03-23 Thread Christoph Hellwig
On Fri, Mar 23, 2007 at 03:04:54PM +0100, Tomas M wrote: > I posted this yesterday but it seems people didn't understand the real > goal of my patch. So I will explain once more again: > > This is a bugfix for loop.c block driver, as it currently allocates more > memory then it needs, without an

Re: [patch] [bugfix] loop.c

2007-03-23 Thread Al Viro
On Fri, Mar 23, 2007 at 03:19:56PM +0100, Eric Dumazet wrote: > On Fri, 23 Mar 2007 15:04:54 +0100 > Tomas M <[EMAIL PROTECTED]> wrote: > > > I posted this yesterday but it seems people didn't understand the real > > goal of my patch. So I will explain once more again: > > > > This is a bugfix f

Re: [patch] [bugfix] loop.c

2007-03-23 Thread William Lee Irwin III
On Fri, 23 Mar 2007 15:04:54 +0100 Tomas M <[EMAIL PROTECTED]> wrote: >> I posted this yesterday but it seems people didn't understand the real >> goal of my patch. So I will explain once more again: >> This is a bugfix for loop.c block driver, as it currently allocates more >> memory then it nee

Re: [patch] [bugfix] loop.c

2007-03-23 Thread Jiri Kosina
On Fri, 23 Mar 2007, Eric Dumazet wrote: > - if (max_loop < 1 || max_loop > 256) { > - printk(KERN_WARNING "loop: invalid max_loop (must be between" > - " 1 and 256), using default (8)\n"); > + if (max_loop < 1) { > + printk(KERN_WARN

Re: [patch] [bugfix] loop.c

2007-03-23 Thread Eric Dumazet
On Fri, 23 Mar 2007 15:04:54 +0100 Tomas M <[EMAIL PROTECTED]> wrote: > I posted this yesterday but it seems people didn't understand the real > goal of my patch. So I will explain once more again: > > This is a bugfix for loop.c block driver, as it currently allocates more > memory then it nee

Re: [patch] [bugfix] loop.c

2007-03-23 Thread Jiri Kosina
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_d

[patch] [bugfix] loop.c

2007-03-23 Thread Tomas M
I posted this yesterday but it seems people didn't understand the real goal of my patch. So I will explain once more again: 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