Re: bug in 2.6.22-rc2: loop mount limited to one single iso image

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 5/20/07, Ken Chen <[email protected]> wrote:
On 5/19/07, Ray Lee <[email protected]> wrote:
> Yeah, that's the only one left. I was hoping it wasn't that one, as it
> claimed to have been tested extensively. Guess it wasn't tested with
> udev.
>
> Ken? Ball's in your court. As the patch isn't providing a killer
> feature for 2.6.22, I'd suggest just reverting it for now until the
> issues are ironed out.

The real solution is to have the user space tool to create these
device nodes in advance.

Maybe. But requiring people upgrade their userspace tools or setup for
2.6.22 isn't a reasonable solution.

The original loop patch was coded such that when we open a loop device
N, the immediate adjacent device "N + 1" is created.  This will keep
"mount -o loop" happy because it typically does a linear scan to find
a free device.  This might be somewhat hackary, but certainly will be
backward compatible before user space solution is deployed.

Except userspace is currently expecting 8 loop nodes upon bootup.
Creating n+1 when n is opened is good, but racy if userspace tries to
mount serveral loop devices in parallel.

If the loop device instantiates 8 (or max_loop) upon init, then we're
compatible with how things are being done in 2.6.21 and earlier.

However, the code was removed by Al in this commit:

commit 07002e995638b83a6987180f43722a0eb39d4932
Author: Al Viro <[email protected]>
Date:   Sat May 12 16:23:15 2007 -0400

  fix the dynamic allocation and probe in loop.c

No, backing that code out wasn't good enough -- the reporter tested
reverting both of Al's patches out and was still getting errors on
boot. It took reverting your original one out as well to make it work.

So, a compromise? Let's start with 8 (or max_loop) populated, and then
we can move forward separately with teaching userspace new loop
tricks.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux