test of devfs patch v88 [was Re: devfs patch v84 for linux-2.2.0-pre9 bugfix]

Heinz Mauelshagen (mauelsha@ez-darmstadt.telekom.de)
Mon, 25 Jan 1999 3:22:42 MET

>
> Hi, Heinz.
> > > > If i do mount a filesystem using a block device special in one of
> > > > the mounted devfs i _don't_ want the permissions be changed by that
> > > > mount via the prefiously mentioned devfs_fill_file() scenario. The
> > > > permissions should be the same as before the mount.
> > >
> > > I don't understand what you're getting at. Your reference to
> > > <devfs_fill_file> confuses me more: what does the internals of the
> > > mounting process have to do with any permissions?
> >
> > Nothing!
> >
> > > I must be missing the point.
> > >
> >
> > Here's an example to hit my point:
> >
> > # ls -l /dev/blockspecial
> > brw-r----- 1 root root 58, 1 Jan 24 06:24 /dev/blockspecial
> > # chmod 660 /dev/blockspecial
> > # ls -l /dev/blockspecial
> > brw-rw---- 1 root root 58, 1 Jan 24 06:24 /dev/blockspecial
> > # mount /dev/blockspecial /mnt # assuming mount is successfull
> > # ls -l /dev/blockspecial
> > brw-r----- 1 root root 58, 1 Jan 24 06:24 /dev/blockspecial
> >
> > To my opinion, the last "ls -l" should read like this:
> >
> > brw-rw---- 1 root root 58, 1 Jan 24 06:24 /dev/blockspecial
> >
> > Explanation: the mount causes a call to devfs_fill_file() which
> > in turn fills devfs's cached mode into the parameter list
> > fiven inode.
>
> OK, I see what's happening now. I've appended a fresh devfs patch for
> you to try. I've also audited some other bits of code and discovered
> more bugs which I've also fixed.

I'v tested it and it is o.k. so far.

Found a typo in linux/fs/devfs/base.c which aborted compiling:

--- base.c.ORG Mon Jan 25 00:06:30 1999
+++ base.c Mon Jan 25 02:24:17 1999
@@ -1280,7 +1280,7 @@
}
if (de == NULL) return -ENODEV;
if (!de->registered) return -ENODEV;
- if (de->f_op == NULL) return -ENODEV;
+ if (de->u.fcb.fops == NULL) return -ENODEV;
file->f_op = de->u.fcb.fops;
file->private_data = de->u.fcb.file_private_data;
/* Initialise temporary inodes (don't touch real inodes) */

But i had another problem i didn't see before:
- i autoload cdrom and sr_mod modules trough kmod/modprobe
- modprobe hangs during a "mount -av -t nonfs,nproc" which is called
from a multiuser startup script while trying to autoload both
modules; this doesn't happen without devfs!?

There are two "solutions":
- if i hack a workaround into the multiuser startup script doing
a "modprobe sr_mod" before the "mount -av -t nonfs,nproc" it works
with devfs.
- or if i delete the cdrom entries in /etc/fstab --> o.k. with devfs.
That sounds trivial but the amazing part of it is to insert them again
after reaching multiuser and mount works!?
Can this be a devfs race?

>
> > Solution: seperate devfs internal cache(s) for each mounted devfs
> > reflecting the dentry information which gets changed
> > by chmod (sys_chmod()).
>
> Actually, I don't think that would have helped. It was a plain bug in
> <devfs_fill_file>. Each mounted devfs does have it's own cache.

I've seen it working 8*)

>
> > BTW: didn't see any change_devfs_inode() in base.c.
>
> It's not needed. Sometime later the inode will be "written", and devfs
> will update its internal cache for that inode.
>

Check.

Another issue (extension request):

devfs_mk_compat() creates a devfs entry with devfs_register
in case of _no_ compatibility symlinks boot option.

But this entry is not associated to the "original" entry.
For egg. /dev/sr0 associated to /dev/sr/c2b0t0u0.

If they where associated to each other a devfs_unregister()
of the diretory /dev/sr/ would be able to unregister any compatibility
entries too.

What do you think about an additional member in the
devfs_entry structure holding the link in the "compatible"
entry (/dev/sr0) pointing to the "original" one (/dev/sr/c2b0t0u0) to
implement this? This would not break the n:1 relationship between
compatible entries and original ones.

devfs_unregister() would then be able (in addition to the entries below
the directory beeing unregistered) to unregister the compatible entries too.

Regards,
Heinz

--


=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-


Systemmanagement Entwicklungsbereich 2           Deutsche Telekom AG
                                                 Entwicklungszentrum Darmstadt
Heinz Mauelshagen                                Otto-Roehm-Strasse 71c
                                                 Postfach 10 05 41
mge@ez-darmstadt.telekom.de                      64205 Darmstadt
                                                 Germany
                                                 +49 6151 886-425
                                                          FAX-386
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/