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

Hugh Dickins
2009-06-14T10:41:09Z

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").

>
> Thanks,
> Fengguang
>
> ---
> [PATCH] ramfs: ignore unknown mount options
>
> From: Mike Frysinger <vapier@gentoo.org>
>
> 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@selenic.com>
> Signed-off-by: Mike Frysinger <vapier@gentoo.org>
> Signed-off-by: Hugh Dickins <hugh.dickins@tiscali.co.uk>

Sorry, no, this one is not yet Signed-off-by me (nor Acked yet by Matt).
Though I admit we're arguing over a trifle!

Hugh

> Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
> Cc: stable@kernel.org
> ---
>
> fs/ramfs/inode.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> --- linux.orig/fs/ramfs/inode.c
> +++ linux/fs/ramfs/inode.c
> @@ -202,9 +202,17 @@ static int ramfs_parse_options(char *dat
> return -EINVAL;
> opts->mode = option & S_IALLUGO;
> break;
> +#ifndef CONFIG_SHMEM
> + /*
> + * We might like to report bad mount options here;
> + * but traditionally ramfs has ignored all mount options,
> + * and as it is used as a !CONFIG_SHMEM simple substitute
> + * for tmpfs, better continue to ignore other mount options.
> + */
> default:
> printk(KERN_ERR "ramfs: bad mount option: %s\n", p);
> return -EINVAL;
> +#endif
> }
> }