On Tue, Oct 04, 2016 at 02:10:39AM -0800, Kent Overstreet wrote:
> > with that filesystem type.
> >
> > Hmm.. I will try to improve it. The problem is that mount(8) interprets
> > EACCES/EROFS as information about the device, then flip to RO makes sense
> > for all next mount(2) attempts.
> >
> > > > > The end result is that if we're trying to mount by trying every filesystem type
> > > > > (your libblkid doesn't know about your filesystem yet..), and the correct
> > > > > filesystem was listed after iso9600 in /proc/filesystems, mount will always
> > > > > mount RO (unless you specify the filesystem type with -t).
> > > >
> > > > Not sure if I understand. Does it mean that iso9600 driver returns
> > > > EACCES for all devices although there is no this FS on the device? Or
> > > > your FS shares the device with iso9600?
> > >
> > > Yes, iso9660 return EACCES when no iso9600 filesystem is present.
> >
> >
> > static struct dentry *isofs_mount(struct file_system_type *fs_type,
> > int flags, const char *dev_name, void *data)
> > {
> > /* We don't support read-write mounts */
> > if (!(flags & MS_RDONLY))
> > return ERR_PTR(-EACCES);
> > return mount_bdev(fs_type, flags, dev_name, data, isofs_fill_super);
> > }
> >
> > This is crazy... iso9600 driver starts analyze mount options although
> > the mount request is maybe completely irrelevant for the driver and
> > there is no iso9600 on the device.
> >
> > If we will write FS drivers in this way then old good "try all from /{proc,etc}/filesystems"
> > will be useless...
> >
> > See another filesystems, for example ext4, first be sure there is
> > superblock and magic string (or return EINVAL) and then try
> > validate mount options.
> >
> > CC to Jan Kara (he did the kernel change in Jun 2013).
>
> Given that the error code is coming from driver code, I think taking it to mean
> anything about the underlying device is going to be flakey at best - we could
That's what we do in last 20 years, good to know it's wrong now.
> fix iso9660, sure, but there's a crap ton of filesystems in the kernel and I'm
> certainly not going to try to audit all their error paths. Even if a driver
> waits until after it verifies its magic string before returnig an error, you
> have cases where multiple drivers may be able to mount the filesystem or - even
> more fun - different filesystem types may have superblocks that don't live at
> the same offset, so the presense of ext4's magic number doesn't mean that not
> actually a completely different filesystem type (don't laugh! I've actually been
> bit by this).
:-)
> What's wrong with just changing mount(8) to only flip to RO for further attempts
> with that particular filesystem type?
As I said, I'll improve mount(8).
Karel
--
Karel Zak <kzak@xxxxxxxxxx>
http://karelzak.blogspot.com
--
To unsubscribe from this list: send the line "unsubscribe util-linux" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
