Re: [patch] remove artificial software max_loop limit
From: Bill Davidsen
Date: Fri Apr 06 2007 - 16:32:38 EST
Jan Engelhardt wrote:
On Apr 1 2007 11:10, Ken Chen wrote:
On 4/1/07, Tomas M <tomas@xxxxxxxx> wrote:
I believe that IF you _really_ need to preserve the max_loop module
parameter, then the parameter should _not_ be ignored, rather it
should have the same function like before - to limit the loop driver
so if you use max_loop=10 for example, it should not allow loop.c to
create more than 10 loops.
Blame on the dual meaning of max_loop that it uses currently: to
initialize a set of loop devices and as a side effect, it also sets
the upper limit. People are complaining about the former constrain,
isn't it? Does anyone uses the 2nd meaning of upper limit?
Who cares if the user specifies max_loop=8 but still is able to open up
/dev/loop8, loop9, etc.? max_loop=X basically meant (at least to me)
"have at least X" loops ready.
You have just come up with a really good reason not to do unlimited
loops. With the current limit people can count on a script mounting
files, or similar, to neither loop for a VERY long time or to eat their
memory. Whatever you think of programs without limit checking, this
falls in the range of expecting an unsigned char to have a certain upper
bound, and argues that the default limit should be the current limit and
that setting a lower bound should work as a real and enforced limit.
If a new capability is being added, and I think it's a great one, then
people using the capability should be the ones explicitly doing
something different. Plauger's law of least astonishment.
--
Bill Davidsen <davidsen@xxxxxxx>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/