Under User Mode Linux in 2.6.14, would someone please explain to me why this
test:
static int graft_tree(struct vfsmount *mnt, struct nameidata *nd)
{
int err;
if (mnt->mnt_sb->s_flags & MS_NOUSER)
return -EINVAL;
Is triggering when I try to mount tmpfs? Is this happening for anybody else?
Shouldn't I be getting a fresh superblock or something? (Is this just a User
Mode Linux issue? Haven't got a spare box set up to boot it on real hardware
just yet...)
If somebody needs a reproduction sequence, I'm happy to oblige. In theory
"mount -t tmpfs /mnt /mnt" should do it, but if it was _that_ simple it
wouldn't have shipped...
Rob
On 10/30/05, Rob Landley <[email protected]> wrote:
> If somebody needs a reproduction sequence, I'm happy to oblige. In theory
> "mount -t tmpfs /mnt /mnt" should do it, but if it was _that_ simple it
> wouldn't have shipped...
I don't see this behaviour on a regular desktop box running 2.6.14.
Guess it's UML specific.
Jon.
On Sun, Oct 30, 2005 at 12:53:00PM +0000, Jon Masters wrote:
> On 10/30/05, Rob Landley <[email protected]> wrote:
>
> > If somebody needs a reproduction sequence, I'm happy to oblige. In theory
> > "mount -t tmpfs /mnt /mnt" should do it, but if it was _that_ simple it
> > wouldn't have shipped...
>
> I don't see this behaviour on a regular desktop box running 2.6.14.
> Guess it's UML specific.
Sorry, but wrong.
IIRC, this triggers when you don't have CONFIG_TMPFS enabled. If you don't,
you still get it, but you get a version that's only usable in-kernel.
Jeff
On Sunday 30 October 2005 09:15, Jeff Dike wrote:
> On Sun, Oct 30, 2005 at 12:53:00PM +0000, Jon Masters wrote:
> > On 10/30/05, Rob Landley <[email protected]> wrote:
> > > If somebody needs a reproduction sequence, I'm happy to oblige. In
> > > theory "mount -t tmpfs /mnt /mnt" should do it, but if it was _that_
> > > simple it wouldn't have shipped...
> >
> > I don't see this behaviour on a regular desktop box running 2.6.14.
> > Guess it's UML specific.
>
> Sorry, but wrong.
>
> IIRC, this triggers when you don't have CONFIG_TMPFS enabled. If you
> don't, you still get it, but you get a version that's only usable
> in-kernel.
Yup. Not CONFIG_TEMPFS. My bad.
Rob
On Sun, Oct 30, 2005 at 10:15:06AM -0500, Jeff Dike wrote:
> On Sun, Oct 30, 2005 at 12:53:00PM +0000, Jon Masters wrote:
> > On 10/30/05, Rob Landley <[email protected]> wrote:
> >
> > > If somebody needs a reproduction sequence, I'm happy to oblige. In theory
> > > "mount -t tmpfs /mnt /mnt" should do it, but if it was _that_ simple it
> > > wouldn't have shipped...
> >
> > I don't see this behaviour on a regular desktop box running 2.6.14.
> > Guess it's UML specific.
>
> Sorry, but wrong.
>
> IIRC, this triggers when you don't have CONFIG_TMPFS enabled. If you don't,
> you still get it, but you get a version that's only usable in-kernel.
That sounds like a regression. Turning off CONFIG_TMPFS replaces tmpfs
with an aliased ramfs. It should be perfectly usable everywhere that
tmpfs is, with the exception that it's not swap-backed and doesn't
have an size limiting.
--
Mathematics is the supreme nostalgia of our time.