Messages in this thread | | | Date | Sun, 14 Jun 2009 11:39:56 +0100 (BST) | From | Hugh Dickins <> | Subject | Re: [PATCH] ramfs: ignore tmpfs options when we emulate it |
| |
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 > } > }
| |