[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <1260887961.2161.6.camel@yio.site>
Date: Tue, 15 Dec 2009 15:39:21 +0100
From: Kay Sievers <kay.sievers@...y.org>
To: Miklos Szeredi <miklos@...redi.hu>
Cc: linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
greg@...ah.com
Subject: Re: get_sb_single() - do not pass options twice
On Tue, 2009-12-15 at 10:48 +0100, Miklos Szeredi wrote:
> On Sat, 12 Dec 2009, Kay Sievers wrote:
> > Ping! Can someone please have a look and comment on that?
> > Something like this will now be needed for 2.6.33 to silent a warning.
> > > --- a/fs/super.c
> > > +++ b/fs/super.c
> > > @@ -900,6 +900,8 @@ int get_sb_single(struct file_system_typ
> > > deactivate_locked_super(s);
> > > return error;
> > > }
> > > + /* options usually get mangled and can only be parsed once */
> > > + data = NULL;
> > > s->s_flags |= MS_ACTIVE;
> > > }
> > > do_remount_sb(s, flags, data, 0);
>
> I think the do_remount_sb() is a NOP in that case. So shouldn't it
> rather be
>
> } else {
> do_remount_sb(s, flags, data, 0);
> }
Yeah, sounds good to me. I wasn't sure if this was done for some
non-obvious reason. In case we can do it this way, here is the patch.
Thanks,
Kay
From: Kay Sievers <kay.sievers@...y.org>
Subject: vfs: get_sb_single() - do not pass options twice
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.
Cc: Greg KH <greg@...ah.com>
Cc: Miklos Szeredi <miklos@...redi.hu>
Signed-off-by: Kay Sievers <kay.sievers@...y.org>
---
fs/super.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/fs/super.c
+++ b/fs/super.c
@@ -901,8 +901,9 @@ int get_sb_single(struct file_system_typ
return error;
}
s->s_flags |= MS_ACTIVE;
+ } else {
+ do_remount_sb(s, flags, data, 0);
}
- do_remount_sb(s, flags, data, 0);
simple_set_mnt(mnt, s);
return 0;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists