* [PATCH] VFS: mount must return EACCES, not EROFS [not found] <20140619230924.GO4453@dastard> @ 2014-06-20 8:39 ` Philippe De Muyter 2014-06-27 8:20 ` [PATCH PING] " Philippe De Muyter 0 siblings, 1 reply; 6+ messages in thread From: Philippe De Muyter @ 2014-06-20 8:39 UTC (permalink / raw) To: linux-kernel Cc: Philippe De Muyter, Al Viro, Dave Chinner, Andrew Morton, linux-fsdevel mount must return EACCES, not EROFS, when one attempts to mount a read-only filesystem in read-write mode, but the file-system layer only transmits the error given by the block layer, and many block drivers return EROFS in that case, so let's fix it in do_mount. Actually it is only a small problem for a user using the mount(1) command, because EROFS is actually a more explicit answer than EACCES, but init/do_mounts.c checks only for EACCES, not EROFS, to decide to retry to mount the root file-system in read-only mode, and so we are left with an unbootable kernel, and with a cryptic error message (*) if the root partition happens to be read-only (*): VFS: Cannot open root device "mmcblk0p2" or unknown-block(179,2): error -30 Signed-off-by: Philippe De Muyter <phdm@macqel.be> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Dave Chinner <david@fromorbit.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: linux-fsdevel@vger.kernel.org --- fs/namespace.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/fs/namespace.c b/fs/namespace.c index 182bc41..6291a3f 100644 --- a/fs/namespace.c +++ b/fs/namespace.c @@ -2411,6 +2411,8 @@ long do_mount(const char *dev_name, const char *dir_name, retval = security_sb_mount(dev_name, &path, type_page, flags, data_page); + if (retval == -EROFS) + retval = -EACCES; if (!retval && !may_mount()) retval = -EPERM; if (retval) -- 1.7.5.3 ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH PING] VFS: mount must return EACCES, not EROFS 2014-06-20 8:39 ` [PATCH] VFS: mount must return EACCES, not EROFS Philippe De Muyter @ 2014-06-27 8:20 ` Philippe De Muyter 2014-07-02 19:46 ` Andrew Morton 0 siblings, 1 reply; 6+ messages in thread From: Philippe De Muyter @ 2014-06-27 8:20 UTC (permalink / raw) To: linux-kernel Cc: Al Viro, Dave Chinner, Andrew Morton, linux-fsdevel, torvalds PING Currently, the initial mount of the root file system by the linux kernel fails with a cryptic message instead of being retried with the MS_RDONLY flag set, when the device is read-only and the combination of block driver and filesystem driver yields EROFS. I do not know if POSIX mandates that mount(2) must fail with EACCES, nor if linux aims to strict compliance with POSIX on that point. Consensus amongst the messages that I have read so far seems to show that linux kernel hackers feel that EROFS is a more appropriate error code than EACCES in that case. So, do you choose for my first pragmatic and non-intrusive patch, that lets mount_block_root() retry with MS_RDONLY if the file system returns EROFS (https://lkml.org/lkml/2014/6/18/468) or for the second one that forces all file-systems to return EACCES instead of EROFS. (https://lkml.org/lkml/2014/6/20/98). Best regards Philippe On Fri, Jun 20, 2014 at 10:39:22AM +0200, Philippe De Muyter wrote: > mount must return EACCES, not EROFS, when one attempts to mount a > read-only filesystem in read-write mode, but the file-system layer > only transmits the error given by the block layer, and many block > drivers return EROFS in that case, so let's fix it in do_mount. > > Actually it is only a small problem for a user using the mount(1) > command, because EROFS is actually a more explicit answer than > EACCES, but init/do_mounts.c checks only for EACCES, not EROFS, > to decide to retry to mount the root file-system in read-only mode, > and so we are left with an unbootable kernel, and with a cryptic > error message (*) if the root partition happens to be read-only > > (*): VFS: Cannot open root device "mmcblk0p2" or unknown-block(179,2): > error -30 > > Signed-off-by: Philippe De Muyter <phdm@macqel.be> > Cc: Al Viro <viro@zeniv.linux.org.uk> > Cc: Dave Chinner <david@fromorbit.com> > Cc: Andrew Morton <akpm@linux-foundation.org> > Cc: linux-fsdevel@vger.kernel.org > --- > fs/namespace.c | 2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/fs/namespace.c b/fs/namespace.c > index 182bc41..6291a3f 100644 > --- a/fs/namespace.c > +++ b/fs/namespace.c > @@ -2411,6 +2411,8 @@ long do_mount(const char *dev_name, const char *dir_name, > > retval = security_sb_mount(dev_name, &path, > type_page, flags, data_page); > + if (retval == -EROFS) > + retval = -EACCES; > if (!retval && !may_mount()) > retval = -EPERM; > if (retval) > -- > 1.7.5.3 -- Philippe De Muyter +32 2 6101532 Macq SA rue de l'Aeronef 2 B-1140 Bruxelles ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH PING] VFS: mount must return EACCES, not EROFS 2014-06-27 8:20 ` [PATCH PING] " Philippe De Muyter @ 2014-07-02 19:46 ` Andrew Morton 2014-07-03 16:29 ` Philippe De Muyter 0 siblings, 1 reply; 6+ messages in thread From: Andrew Morton @ 2014-07-02 19:46 UTC (permalink / raw) To: Philippe De Muyter Cc: linux-kernel, Al Viro, Dave Chinner, linux-fsdevel, torvalds On Fri, 27 Jun 2014 10:20:58 +0200 Philippe De Muyter <phdm@macqel.be> wrote: > Currently, the initial mount of the root file system by the linux > kernel fails with a cryptic message instead of being retried with > the MS_RDONLY flag set, when the device is read-only and the > combination of block driver and filesystem driver yields EROFS. > > I do not know if POSIX mandates that mount(2) must fail with EACCES, nor > if linux aims to strict compliance with POSIX on that point. Consensus > amongst the messages that I have read so far seems to show that linux > kernel hackers feel that EROFS is a more appropriate error code than > EACCES in that case. > > So, do you choose for my first pragmatic and non-intrusive patch, that > lets mount_block_root() retry with MS_RDONLY if the file system > returns EROFS (https://lkml.org/lkml/2014/6/18/468) or for the second > one that forces all file-systems to return EACCES instead of EROFS. > (https://lkml.org/lkml/2014/6/20/98). They both seem a little hacky to me. Isn't the core problem that "the combination of block driver and filesystem driver yields EROFS"? That the fs should instead be returning EACCESS in this case? What fs and block driver are we talking about here, anyway? ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH PING] VFS: mount must return EACCES, not EROFS 2014-07-02 19:46 ` Andrew Morton @ 2014-07-03 16:29 ` Philippe De Muyter 2014-07-08 21:02 ` Andrew Morton 0 siblings, 1 reply; 6+ messages in thread From: Philippe De Muyter @ 2014-07-03 16:29 UTC (permalink / raw) To: Andrew Morton Cc: linux-kernel, Al Viro, Dave Chinner, linux-fsdevel, torvalds, Karel Zak On Wed, Jul 02, 2014 at 12:46:51PM -0700, Andrew Morton wrote: > On Fri, 27 Jun 2014 10:20:58 +0200 Philippe De Muyter <phdm@macqel.be> wrote: > > > Currently, the initial mount of the root file system by the linux > > kernel fails with a cryptic message instead of being retried with > > the MS_RDONLY flag set, when the device is read-only and the > > combination of block driver and filesystem driver yields EROFS. > > > > I do not know if POSIX mandates that mount(2) must fail with EACCES, nor > > if linux aims to strict compliance with POSIX on that point. Consensus > > amongst the messages that I have read so far seems to show that linux > > kernel hackers feel that EROFS is a more appropriate error code than > > EACCES in that case. > > Isn't the core problem that "the combination of block driver and > filesystem driver yields EROFS"? That the fs should instead be > returning EACCESS in this case? Does POSIX or Linux mandate that it should ? > > What fs and block driver are we talking about here, anyway? The problem happened to me with a f2fs filesystem on a sd-card that was accidentally write-protected and that was put in a SD-card slot (mmc block driver). I retested using mount(8) with a similar now intentionnaly write-protected sd card in a usb reader (usb_storage driver ?) with vfat, f2fs and ext4 filesystems with the following results : mywdesk:~ # strace -e mount mount /dev/sdb1 /mnt mount("/dev/sdb1", "/mnt", "vfat", MS_MGC_VAL, NULL) = -1 EROFS (Read-only file system) mount: /dev/sdb1 is write-protected, mounting read-only mount("/dev/sdb1", "/mnt", "vfat", MS_MGC_VAL|MS_RDONLY, NULL) = 0 +++ exited with 0 +++ mywdesk:~ # umount /mnt mywdesk:~ # strace -e mount mount -t f2fs /dev/sdb2 /mnt mount("/dev/sdb2", "/mnt", "f2fs", MS_MGC_VAL, NULL) = -1 EROFS (Read-only file system) mount: /dev/sdb2 is write-protected, mounting read-only mount("/dev/sdb2", "/mnt", "f2fs", MS_MGC_VAL|MS_RDONLY, NULL) = 0 +++ exited with 0 +++ mywdesk:~ # umount /mnt mywdesk:~ # strace -e mount mount /dev/sdb3 /mnt mount("/dev/sdb3", "/mnt", "ext4", MS_MGC_VAL, NULL) = -1 EROFS (Read-only file system) mount: /dev/sdb3 is write-protected, mounting read-only mount("/dev/sdb3", "/mnt", "ext4", MS_MGC_VAL|MS_RDONLY, NULL) = 0 +++ exited with 0 +++ mywdesk:~ # All three file-systems (vfat, f2fs & ext4) yield EROFS. I also quickly grepped for occurences of EROFS under fs/, and found no check to replace EROFS by EACCES, while the same grep under drivers/{block,cdrom,ide,md,memstick, mtd, s390/block,scsi,usb} gives plenty of "return -EROFS;" So, if no filesystem driver replaces EROFS by EACCES and many block drivers return EROFS, it seems to me that many combinations will yield EROFS. > > > > So, do you choose for my first pragmatic and non-intrusive patch, that > > lets mount_block_root() retry with MS_RDONLY if the file system > > returns EROFS (https://lkml.org/lkml/2014/6/18/468) or for the second > > one that forces all file-systems to return EACCES instead of EROFS. > > (https://lkml.org/lkml/2014/6/20/98). > > They both seem a little hacky to me. Actually I prefer my first patch, which simply adapts the kernel to the current situation, like mount(8) already does, instead of trying to impose an ABI change. Philippe -- Philippe De Muyter +32 2 6101532 Macq SA rue de l'Aeronef 2 B-1140 Bruxelles ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH PING] VFS: mount must return EACCES, not EROFS 2014-07-03 16:29 ` Philippe De Muyter @ 2014-07-08 21:02 ` Andrew Morton 2014-07-15 10:05 ` Philippe De Muyter 0 siblings, 1 reply; 6+ messages in thread From: Andrew Morton @ 2014-07-08 21:02 UTC (permalink / raw) To: Philippe De Muyter Cc: linux-kernel, Al Viro, Dave Chinner, linux-fsdevel, torvalds, Karel Zak On Thu, 3 Jul 2014 18:29:19 +0200 Philippe De Muyter <phdm@macqel.be> wrote: > On Wed, Jul 02, 2014 at 12:46:51PM -0700, Andrew Morton wrote: > > On Fri, 27 Jun 2014 10:20:58 +0200 Philippe De Muyter <phdm@macqel.be> wrote: > > > > > Currently, the initial mount of the root file system by the linux > > > kernel fails with a cryptic message instead of being retried with > > > the MS_RDONLY flag set, when the device is read-only and the > > > combination of block driver and filesystem driver yields EROFS. > > > > > > I do not know if POSIX mandates that mount(2) must fail with EACCES, nor > > > if linux aims to strict compliance with POSIX on that point. Consensus > > > amongst the messages that I have read so far seems to show that linux > > > kernel hackers feel that EROFS is a more appropriate error code than > > > EACCES in that case. > > > > Isn't the core problem that "the combination of block driver and > > filesystem driver yields EROFS"? That the fs should instead be > > returning EACCESS in this case? > > Does POSIX or Linux mandate that it should ? > > > > > What fs and block driver are we talking about here, anyway? > > The problem happened to me with a f2fs filesystem on a sd-card that was > accidentally write-protected and that was put in a SD-card slot (mmc block > driver). > > I retested using mount(8) with a similar now intentionnaly write-protected > sd card in a usb reader (usb_storage driver ?) with vfat, f2fs and ext4 > filesystems with the following results : > > mywdesk:~ # strace -e mount mount /dev/sdb1 /mnt > mount("/dev/sdb1", "/mnt", "vfat", MS_MGC_VAL, NULL) = -1 EROFS (Read-only file system) > mount: /dev/sdb1 is write-protected, mounting read-only > mount("/dev/sdb1", "/mnt", "vfat", MS_MGC_VAL|MS_RDONLY, NULL) = 0 > +++ exited with 0 +++ > mywdesk:~ # umount /mnt > mywdesk:~ # strace -e mount mount -t f2fs /dev/sdb2 /mnt > mount("/dev/sdb2", "/mnt", "f2fs", MS_MGC_VAL, NULL) = -1 EROFS (Read-only file system) > mount: /dev/sdb2 is write-protected, mounting read-only > mount("/dev/sdb2", "/mnt", "f2fs", MS_MGC_VAL|MS_RDONLY, NULL) = 0 > +++ exited with 0 +++ > mywdesk:~ # umount /mnt > mywdesk:~ # strace -e mount mount /dev/sdb3 /mnt > mount("/dev/sdb3", "/mnt", "ext4", MS_MGC_VAL, NULL) = -1 EROFS (Read-only file system) > mount: /dev/sdb3 is write-protected, mounting read-only > mount("/dev/sdb3", "/mnt", "ext4", MS_MGC_VAL|MS_RDONLY, NULL) = 0 > +++ exited with 0 +++ > mywdesk:~ # > > All three file-systems (vfat, f2fs & ext4) yield EROFS. > > I also quickly grepped for occurences of EROFS under fs/, and found no check > to replace EROFS by EACCES, > while the same grep under drivers/{block,cdrom,ide,md,memstick, mtd, > s390/block,scsi,usb} gives plenty of "return -EROFS;" > > So, if no filesystem driver replaces EROFS by EACCES and many block drivers > return EROFS, it seems to me that many combinations will yield EROFS. hm. I'm thinking that in an ideal world, those block drivers will return -EACCES rather than -EROFS. You open() a read-only device for rw, you get "permission denied". Al, speak to us. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH PING] VFS: mount must return EACCES, not EROFS 2014-07-08 21:02 ` Andrew Morton @ 2014-07-15 10:05 ` Philippe De Muyter 0 siblings, 0 replies; 6+ messages in thread From: Philippe De Muyter @ 2014-07-15 10:05 UTC (permalink / raw) To: Andrew Morton Cc: linux-kernel, Al Viro, Dave Chinner, linux-fsdevel, torvalds, Karel Zak On Tue, Jul 08, 2014 at 02:02:18PM -0700, Andrew Morton wrote: > On Thu, 3 Jul 2014 18:29:19 +0200 Philippe De Muyter <phdm@macqel.be> wrote: > > > On Wed, Jul 02, 2014 at 12:46:51PM -0700, Andrew Morton wrote: > > > On Fri, 27 Jun 2014 10:20:58 +0200 Philippe De Muyter <phdm@macqel.be> wrote: > > > > > > > Currently, the initial mount of the root file system by the linux > > > > kernel fails with a cryptic message instead of being retried with > > > > the MS_RDONLY flag set, when the device is read-only and the > > > > combination of block driver and filesystem driver yields EROFS. > > > > > > > > I do not know if POSIX mandates that mount(2) must fail with EACCES, nor > > > > if linux aims to strict compliance with POSIX on that point. Consensus > > > > amongst the messages that I have read so far seems to show that linux > > > > kernel hackers feel that EROFS is a more appropriate error code than > > > > EACCES in that case. > > > > > > Isn't the core problem that "the combination of block driver and > > > filesystem driver yields EROFS"? That the fs should instead be > > > returning EACCESS in this case? > > > > Does POSIX or Linux mandate that it should ? > > For info, SCO Unix documents that mount(2) may fail with EROFS : and adds "mount is not part of any currently supported standard" http://osr507doc.sco.com/en/man/html.S/mount.S.html Philippe ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2014-07-15 10:05 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20140619230924.GO4453@dastard>
2014-06-20 8:39 ` [PATCH] VFS: mount must return EACCES, not EROFS Philippe De Muyter
2014-06-27 8:20 ` [PATCH PING] " Philippe De Muyter
2014-07-02 19:46 ` Andrew Morton
2014-07-03 16:29 ` Philippe De Muyter
2014-07-08 21:02 ` Andrew Morton
2014-07-15 10:05 ` Philippe De Muyter
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).