Messages in this thread Patch in this message | | | From | Heinz Mauelshagen <> | Subject | Re: defvs patch v84 for linux 2.2.0-pre9 bugfix | Date | Sun, 24 Jan 1999 3:12:44 MET |
| |
> > Heinz Mauelshagen writes: > > > > Hi Richard! > > > > Yesterday i gave myself a chance to have a look at your devfs patch > > for Linux 2.2.0-pre9 8*) > > > > I found a little bug, which seems to cause non standard block devices > > beeing _not_ mountable any more. > > In detail, my logical volume manager block devices don't work. > > The block device specials are created by lvm user commands. > > > > I think any software creating block specials should fail with the > > v84 code in super.c, where your patch looks like: > > > > @@ -1067,8 +1079,9 @@ > > if (MAJOR(dev) >= MAX_BLKDEV) > > goto dput_and_out; > > > > - retval = -ENOTBLK; > > - dummy.f_op = get_blkfops(MAJOR(dev)); > > + retval = devfs_fill_file (inode, &dummy, NULL); > > + if ( !retval && !S_ISBLK (inode->i_mode) ) retval = -ENOTBLK; > > + if (retval < 0) dummy.f_op = get_blkfops(MAJOR(dev)); > > if (!dummy.f_op) > > goto dput_and_out; > > Can you please explain why you think my patch is not working?
Please see below.
> > Also, please send me the output of ls -lF on the device node you are > trying to mount.
brw-r----- 1 root root 58, 1 Jan 24 03:48 /dev/vg00/u1
> > I do have one theory why my patch is failing. See the line: > if ( !retval && !S_ISBLK (inode->i_mode) ) retval = -ENOTBLK; > ^^ > If the device is non-standard (i.e. the device node was created with > mknod(2) and not internally by the driver calling devfs_register()), > *and* the previous contents of the inode were for a block device, then > the condition fails. This means that reval will not be set to -ENOTBLK > and the fops are subsequently not filled. Hence you can't mount. > This is a braino on my part. > > I suggest changing the "&&" to a "||". This should fix your problem > and also provides the desired behaviour. Please let me know if this > works for you.
That's o.k. for me, but why do you test for block device again anyway? It's already tested a couple of lines above in linux/fs/super.c based on the actual dentry (line 1343).
The only difference (at least for me 8*)) is another test after filling inode->i_mode in devfs_fill_file with contents of devfs internal cached inode (get_devfs_inode_from_vfs_inode()).
> > > Patch against stock linux-2.2.0-pre9/fs/super.c to fix the problem > > follows: > > In future, could you please provide patches against kernel+devfs, > rather than providing a replacement devfs patch? This makes it easier > for me to understand what you're doing and also makes it easier to > integrate a patch.
I thought i had done this 8*(
The example below only was the extract from your original patch for reference.
> > > @@ -1067,8 +1079,9 @@ > > if (MAJOR(dev) >= MAX_BLKDEV) > > goto dput_and_out; > > > > - retval = -ENOTBLK; > > - dummy.f_op = get_blkfops(MAJOR(dev)); > > + if ( !( retval = devfs_fill_file (inode, &dummy, NULL))) > > + retval = -ENOTBLK; > > + if ( retval < 0) dummy.f_op = get_blkfops(MAJOR(dev)); > > if (!dummy.f_op) > > goto dput_and_out; > > > > I'm assuming that this is the (only) part of the devfs patch that you > suggest changing.
Correct.
> What you have done here is removed the check for a > block device returned from devfs. So now, the user could attempt to > mount a character device. I don't think this is a good fix to the > problem. See above for a suggested fix.
No, i don't think so because it has already been tested before (see my arguments above).
Thank you and best regards, Heinz
P.S.: i found another flaw. If someone does chmod a devfs block special sys_chmod/sys_fchmod in linux/fs/open.c updates the dentry but devfs internal cached mode for the inode never changes. If the block special contains a filesystem and you do mount/umount it, your changed permissions are gone afterwards.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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/
| |