Messages in this thread Patch in this message | | | From | Heinz Mauelshagen <> | Subject | test of devfs patch v88 [was Re: devfs patch v84 for linux-2.2.0-pre9 bugfix] | Date | 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/
| |