All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrey Borzenkov <arvidjaar@mail.ru>
To: Kay Sievers <kay.sievers@vrfy.org>
Cc: Uwe Bugla <uwe.bugla@gmx.de>, Ken Chen <kenchen@google.com>,
	Ray Lee <ray-lk@madrabbit.org>, Al Viro <viro@ftp.linux.org.uk>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Michal Piotrowski <michal.k.k.piotrowski@gmail.com>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: bug in 2.6.22-rc2: loop mount limited to one single iso image
Date: Mon, 21 May 2007 21:51:28 +0400	[thread overview]
Message-ID: <200705212151.44667.arvidjaar@mail.ru> (raw)
In-Reply-To: <1179767466.3320.48.camel@lov.localdomain>

[-- Attachment #1: Type: text/plain, Size: 2309 bytes --]

On Monday 21 May 2007, Kay Sievers wrote:
> On Mon, 2007-05-21 at 18:50 +0200, Uwe Bugla wrote:
> > Am Montag, 21. Mai 2007 18:37 schrieben Sie:
> > > On 5/21/07, Ken Chen <kenchen@google.com> wrote:
> > > > yes and no. in that commit, I automatically create n+1 device when
> > > > loop device n is created, allergically was tested to be fine with
> > > > casual usage of "losetup" and "mount -o loop".  However, there is a
> > > > bug in that commit when loop.c was compiled as a module.  And when Al
> > > > fixed it, he also removed that magic "n+1" trick.
> > > >
> > > > Nevertheless, yes, I'm guilty of introducing the new behavior.
> > >
> > > The easiest way is to reinstate max_loop and create "max_loop" device
> > > up front at module load time.  However, that will lose all the "fancy
> > > on-demand device instantiation feature".
> > >
> > > So I propose we do the following:
> > >
> > > 1. have the module honor "max_loop" parameter and create that many
> > > device upfront on module load (max_loop will also be a hard max) iff
> > > user specify the parameter.
> > > 2. if max_loop is not specified, default create 8 loop device.  User
> > > can extent more loop device by create device node themselves and have
> > > kernel automatically instantiate loop device on-demand.
> >
> > Sorry, Ken:
> > My question on point 2 would be: Does "User can extent more loop device
> > by create device node themselves and......." correspond or conflict to
> > working with udev?
>
> Udev shouldn't care if the kernel tells udev about the new device, and
> the node with the correct dev_t is already there, it will leave it as it
> is, and only apply the configured user,group,mode values.
>
> The loop tools should probably extended to be able to request new
> devices from the kernel in a different way than open().
>

Except as already mentioned it will introduce races between tool requesting 
new device and udev creating new node. We already had this with raw devices. 
My comparison with /dev/pts was incorrect because it is using internal 
filesystem that creates devices synchronously.

May be all such cases has to be converted to use common file system.

mount -t nodefs -o device=pts none /dev/pts
mount -t nodefs -o device=loop none /dev/loop

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2007-05-21 17:52 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-19 18:33 bug in 2.6.22-rc2: loop mount limited to one single iso image Ray Lee
2007-05-19 19:17 ` Andrey Borzenkov
     [not found]   ` <200705200124.13026.uwe.bugla@gmx.de>
2007-05-20  4:45     ` Andrey Borzenkov
2007-05-20  6:16       ` Ray Lee
2007-05-20  6:28         ` Al Viro
2007-05-20  6:58           ` Andrey Borzenkov
2007-05-20 14:52             ` Uwe Bugla
2007-05-20 15:26               ` Ray Lee
2007-05-20 15:22           ` Ray Lee
2007-05-20 15:54             ` Kay Sievers
2007-05-20 16:02               ` Andrey Borzenkov
2007-05-20 16:23                 ` Andreas Schwab
2007-05-20 16:10               ` Ray Lee
2007-05-20 16:16                 ` Kay Sievers
2007-05-20 16:29                   ` Uwe Bugla
2007-05-20 19:53                     ` Michael Mauch
2007-05-21 16:11                   ` Linus Torvalds
2007-05-21 16:27                     ` Ken Chen
2007-05-21 16:35                       ` Ray Lee
2007-05-21 16:37                       ` Ken Chen
2007-05-21 16:50                         ` Uwe Bugla
2007-05-21 17:11                           ` Kay Sievers
2007-05-21 17:51                             ` Andrey Borzenkov [this message]
2007-05-21 17:04                         ` Linus Torvalds
2007-05-21 20:48                         ` Ken Chen
2007-05-21 21:20                           ` Uwe Bugla
2007-05-21 22:04                             ` Andrew Morton
2007-05-22  0:10                     ` Al Viro
2007-05-22  0:13                       ` Al Viro
2007-05-20 16:09             ` Andrey Borzenkov
2007-05-20 16:14               ` Ray Lee
2007-05-22 20:18           ` Jan Engelhardt
2007-05-22 21:35             ` Uwe Bugla
2007-05-21  6:08         ` Ken Chen
2007-05-21  6:40           ` Ray Lee
2007-05-21  7:59             ` Uwe Bugla
  -- strict thread matches above, loose matches on Subject: below --
2007-05-19 13:53 Uwe Bugla

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200705212151.44667.arvidjaar@mail.ru \
    --to=arvidjaar@mail.ru \
    --cc=akpm@linux-foundation.org \
    --cc=kay.sievers@vrfy.org \
    --cc=kenchen@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michal.k.k.piotrowski@gmail.com \
    --cc=ray-lk@madrabbit.org \
    --cc=torvalds@linux-foundation.org \
    --cc=uwe.bugla@gmx.de \
    --cc=viro@ftp.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.