Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756036AbZFNKBZ (ORCPT ); Sun, 14 Jun 2009 06:01:25 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752018AbZFNKBS (ORCPT ); Sun, 14 Jun 2009 06:01:18 -0400 Received: from mga03.intel.com ([143.182.124.21]:44644 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751775AbZFNKBS (ORCPT ); Sun, 14 Jun 2009 06:01:18 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.42,217,1243839600"; d="scan'208";a="154072137" Date: Sun, 14 Jun 2009 18:01:10 +0800 From: Wu Fengguang To: Hugh Dickins Cc: Mike Frysinger , Andrew Morton , Matt Mackall , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH] ramfs: ignore tmpfs options when we emulate it Message-ID: <20090614100110.GA19875@localhost> References: <1244872920-13511-1-git-send-email-vapier@gentoo.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3221 Lines: 82 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. Thanks, Fengguang --- [PATCH] ramfs: ignore unknown mount options From: Mike Frysinger 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 Signed-off-by: Mike Frysinger Signed-off-by: Hugh Dickins Signed-off-by: Wu Fengguang 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 } } -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/