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

[Hugh Dickins]

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@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>

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@xxxxxxxxx>
> Cc: stable@xxxxxxxxxx
> ---
> 
>  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
>  		}
>  	}
--
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/