lkml.org 
[lkml]   [2016]   [Nov]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: [RFC PATCH] hugetlbfs: fix the hugetlbfs can not be mounted
[Re: [RFC PATCH] hugetlbfs: fix the hugetlbfs can not be mounted] On 03/11/2016 (Thu 12:17) Andrew Morton wrote:

> On Sat, 29 Oct 2016 14:08:31 +0800 zhongjiang <zhongjiang@huawei.com> wrote:
>
> > From: zhong jiang <zhongjiang@huawei.com>
> >
> > Since 'commit 3e89e1c5ea84 ("hugetlb: make mm and fs code explicitly non-modular")'
> > bring in the mainline. mount hugetlbfs will result in the following issue.
> >
> > mount: unknown filesystme type 'hugetlbfs'

The fact that the above has a typo makes me doubt it was real output
from "mount". In any case, that just means they didn't enable the
Kconfig option for it and hence it is not in /proc/filesystems as they
can easily verify.

> >
> > because previous patch remove the module_alias_fs, when we mount the fs type,
> > the caller get_fs_type can not find the filesystem.
> >
> > The patch just recover the module_alias_fs to identify the hugetlbfs.
>
> hm, 3e89e1c5ea84 ("hugetlb: make mm and fs code explicitly
> non-modular") was merged almost a year ago. And you are apparently the
> first person to discover this regression. Can you think why that is?

Agreed -- I'd like to know just how this conclusion was reached. Maybe
they are running some out-of-tree patches to make it modular? Who
knows. It would be nice if we hear back, but I don't have high hopes.

In any case, 3e89e1c5ea84 commit log says:

Also note that MODULE_ALIAS is a no-op for non-modular code.

This isn't fundamentally hard to verify; the macros are:

#define MODULE_ALIAS_FS(NAME) MODULE_ALIAS("fs-" NAME)

#define MODULE_ALIAS(_alias) MODULE_INFO(alias, _alias)

#define MODULE_INFO(tag, info) __MODULE_INFO(tag, tag, info)

...and then finally:

#ifdef MODULE
#define __MODULE_INFO(tag, name, info) \
static const char __UNIQUE_ID(name)[] \
__used __attribute__((section(".modinfo"), unused, aligned(1))) \
= __stringify(tag) "=" info
#else /* !MODULE */
/* This struct is here for syntactic coherency, it is not used */
#define __MODULE_INFO(tag, name, info) \
struct __UNIQUE_ID(name) {}
#endif

...so a commit like this would have to explain how the patch does anything in
the !MODULE case, when the syntax comment above even indicates it is not used.

I remember this commit since there was patch order issue that the kbuild
robot uncovered (as listed in the commit log) in an earlier version of it.

So I can assure the patch poster that hugetlbfs was mounted for testing,
and they should revisit the logic that led to this no-op patch.

Paul.
--

>
> > index 4fb7b10..b63e7de 100644
> > --- a/fs/hugetlbfs/inode.c
> > +++ b/fs/hugetlbfs/inode.c
> > @@ -35,6 +35,7 @@
> > #include <linux/security.h>
> > #include <linux/magic.h>
> > #include <linux/migrate.h>
> > +#include <linux/module.h>
> > #include <linux/uio.h>
> >
> > #include <asm/uaccess.h>
> > @@ -1209,6 +1210,7 @@ static struct dentry *hugetlbfs_mount(struct file_system_type *fs_type,
> > .mount = hugetlbfs_mount,
> > .kill_sb = kill_litter_super,
> > };
> > +MODULE_ALIAS_FS("hugetlbfs");
> >
> > static struct vfsmount *hugetlbfs_vfsmount[HUGE_MAX_HSTATE];
> >
>

\
 
 \ /
  Last update: 2016-11-03 21:55    [W:0.506 / U:0.184 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site