Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753215AbZL3SGQ (ORCPT ); Wed, 30 Dec 2009 13:06:16 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753193AbZL3SGP (ORCPT ); Wed, 30 Dec 2009 13:06:15 -0500 Received: from mail-bw0-f227.google.com ([209.85.218.227]:45112 "EHLO mail-bw0-f227.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753147AbZL3SGO (ORCPT ); Wed, 30 Dec 2009 13:06:14 -0500 MIME-Version: 1.0 In-Reply-To: <87my14h9vo.fsf@devron.myhome.or.jp> References: <20091223194955.GB18101@kroah.com> <1261597963-18323-2-git-send-email-gregkh@suse.de> <87my14h9vo.fsf@devron.myhome.or.jp> From: Kay Sievers Date: Wed, 30 Dec 2009 19:05:58 +0100 Message-ID: Subject: Re: [PATCH 02/10] vfs: get_sb_single() - do not pass options twice To: OGAWA Hirofumi Cc: Greg Kroah-Hartman , linux-kernel@vger.kernel.org, Miklos Szeredi Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1375 Lines: 33 On Sun, Dec 27, 2009 at 13:36, OGAWA Hirofumi wrote: >> Filesystem code usually destroys the option buffer while >> parsing it. This leads to errors when the same buffer is >> passed twice. In case we fill a new superblock do not call >> remount. > This breaks the historical behavior. Several users of get_sb_single() is > parse data only on ->remount_fs. Well, ok, I like new behavior actually. > But we need to convert to new behavior such users. > > I've listed all possibly affected users up (if I'm not missing). This > means, using both data on ->fill_super and ->remount_fs is devtmpfs > only. And capifs, usbfs, devpts would be needed the patch. Hmm, these filesystem are probably not going to overwrite their own default options with their own special parameters to parse when they allocate their superblock. That would be pretty weird, wouldn't it? Seems they currently don't even pass "data" pointer around at that time. It's a bit different with tmpfs as we use it as a generic backend for a special purpose filesystem. What's the issue you are seeing, or have in mind? Thanks, Kay -- 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/