Re: [PATCH] ramfs: ignore tmpfs options when we emulate it

[Wu Fengguang]

On Sun, Jun 14, 2009 at 06:39:56PM +0800, Hugh Dickins wrote:
> On Sun, 14 Jun 2009, Wu Fengguang wrote:
> > On Sat, Jun 13, 2009 at 10:15:51PM +0800, Hugh Dickins wrote:
> > > On Sat, 13 Jun 2009, Mike Frysinger wrote:
> > > 
> > > > On systems where CONFIG_SHMEM is disabled, mounting tmpfs filesystems can
> > > > fail when tmpfs options are used.  This is because tmpfs creates a small
> > > > wrapper around ramfs which rejects unknown options, and ramfs itself only
> > > > supports a tiny subset of what tmpfs supports.  This makes it pretty hard
> > > > to use the same userspace systems across different configuration systems.
> > > > As such, ramfs should ignore the tmpfs options when tmpfs is merely a
> > > > wrapper around ramfs.
> > > 
> > > Yes, indeed, thanks a lot for reporting this.
> > > 
> > > But I'm uneasy with making ramfs behaviour differ with CONFIG_SHMEM
> > > (perhaps that's silly: certainly tmpfs behaviour differs with it),
> > > and uneasy with coding a list of options we need to remember to keep
> > > in synch with mm/shmem.c.  It's easier to justify ignoring all options,
> > > than rejecting some while ignoring others yet not respecting them.
> > 
> > We can avoid the burden of syncing a list of options between
> > ramfs<>tmpfs by a slightly differently patch. Hopefully this makes
> > ramfs behave like other filesystems when used standalone.
> 
> We could do; but I'm still preferring not.  How about you, Matt?
> You decide, I think Andrew has chosen a different race track from
> "The Merge Window" this weekend.
> 
> Either of our patches (or Mike's orginal) fixes Mike's actual problem:
> but I'd rather keep ramfs as close as we can to its original behaviour,
> and as simple as possible; not making it behave differently in the
> CONFIG_SHMEM=y and CONFIG_SHMEM=n cases (you can still "mount -t ramfs"
> when ramfs is also being used to serve "mount -t tmpfs").

Right. Compatibility and simplicity makes sense. Do you agree to emit
a warning message though? This updated patch changes KERN_ERR to KERN_WARNING.

Thanks,
Fengguang

---
[PATCH] ramfs: ignore unknown mount options

From: Mike Frysinger <vapier@xxxxxxxxxx>

On systems where CONFIG_SHMEM is disabled, mounting tmpfs filesystems can
fail when tmpfs options are used.  This is because tmpfs creates a small
wrapper around ramfs which rejects unknown options, and ramfs itself only
supports a tiny subset of what tmpfs supports.  This makes it pretty hard
to use the same userspace systems across different configuration systems.
As such, ramfs should ignore the tmpfs options when tmpfs is merely a
wrapper around ramfs.

This used to work before commit c3b1b1cbf0 as previously, ramfs would
ignore all options.  But now, we get:
ramfs: bad mount option: size=10M
mount: mounting mdev on /dev failed: Invalid argument

Another option might be to restore the previous behavior, where ramfs
simply ignored all unknown mount options ... which is what Hugh prefers.

Acked-by: Matt Mackall <mpm@xxxxxxxxxxx>
Signed-off-by: Mike Frysinger <vapier@xxxxxxxxxx>
Signed-off-by: Hugh Dickins <hugh.dickins@xxxxxxxxxxxxx>
Signed-off-by: Wu Fengguang <fengguang.wu@xxxxxxxxx>
Cc: stable@xxxxxxxxxx
---

 fs/ramfs/inode.c |    9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

--- linux.orig/fs/ramfs/inode.c
+++ linux/fs/ramfs/inode.c
@@ -202,9 +202,14 @@ static int ramfs_parse_options(char *dat
 				return -EINVAL;
 			opts->mode = option & S_IALLUGO;
 			break;
+		/*
+		 * Traditionally ramfs has ignored all mount options,
+		 * and as it is used as a !CONFIG_SHMEM simple substitute
+		 * for tmpfs, ignore other mount options with a warning.
+		 */
 		default:
-			printk(KERN_ERR "ramfs: bad mount option: %s\n", p);
-			return -EINVAL;
+			printk(KERN_WARNING "ramfs: bad mount option: %s\n", p);
+			break;
 		}
 	}
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/