On Fri, Jun 20, 2014 at 03:13:28PM +0200, Philippe De Muyter wrote: > On Fri, Jun 20, 2014 at 09:09:24AM +1000, Dave Chinner wrote: > > On Thu, Jun 19, 2014 at 02:19:50PM -0700, Andrew Morton wrote: > > > On Wed, 18 Jun 2014 18:12:44 +0200 Philippe De Muyter <p...@macqel.be> > > > wrote: > > > > > > > some combinations of filesystem and block device (at least vfat on mmc) > > > > yield -EROFS instead of -EACCES when the device is read-only. Retry > > > > mounting with MS_RDONLY set, just like for the EACCES case, instead of > > > > failing directly. > > > > > > > > ... > > > > > > > > --- a/init/do_mounts.c > > > > +++ b/init/do_mounts.c > > > > @@ -394,6 +394,7 @@ retry: > > > > case 0: > > > > goto out; > > > > case -EACCES: > > > > + case -EROFS: > > > > flags |= MS_RDONLY; > > > > goto retry; > > > > case -EINVAL: > > > > > > hm, what's going on here. I'd have thought it to be very logical that > > > file_system_type.mount() would return EROFS if the device is read-only! > > > But I'm suspecting that there is some convention that the fs is > > > supposed to return EACCES in this case. So *perhaps* it is vfat-on-mmc > > > which needs fixing. Dunno. > > > > > > Al, are you able to shed light? > > > > from the mount(2) man page: > > > > EACCES A component of a path was not searchable. (See also > > path_resolution(7).) Or, mounting a read-only filesystem > > was attempted without giving the MS_RDONLY flag. Or, the > > block device source is located on a filesystem mounted with > > the MS_NODEV option. > > > > So, when the device is read-only, the error should EACCES, not > > EROFS. Would seem to me that vfat-on-mmc needs fixing...
Only code matters, we don't compile and execute man pages... ;-) > Looking at the sources of mount(1) > > https://github.com/karelzak/util-linux/blob/master/sys-utils/mount.c > > at line 601, we clearly see that mount(1) allows mount(2) to fail > with EROFS. BTW, comment from the original mount(8) code: case EACCES: /* pre-linux 1.1.38, 1.1.41 and later */ case EROFS: /* linux 1.1.38 and later */ Karel -- Karel Zak <k...@redhat.com> http://karelzak.blogspot.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
