On Tue, 1 Sep 2009, Eric B Munson wrote:
> On Mon, 31 Aug 2009, Hugh Dickins wrote:
> > On Wed, 26 Aug 2009, Eric B Munson wrote:
> > > This patch adds a flag for mmap that will be used to request a huge
> > > page region that will look like anonymous memory to user space. This
> > > is accomplished by using a file on the internal vfsmount. MAP_HUGETLB
> > > is a modifier of MAP_ANONYMOUS and so must be specified with it. The
> > > region will behave the same as a MAP_ANONYMOUS region using small pages.
> > >
> > > Signed-off-by: Eric B Munson <[email protected]>
> > > ---
> > > include/asm-generic/mman-common.h | 1 +
> > > include/linux/hugetlb.h | 7 +++++++
> > > mm/mmap.c | 19 +++++++++++++++++++
> > > 3 files changed, 27 insertions(+), 0 deletions(-)
> > >
> > > diff --git a/include/asm-generic/mman-common.h b/include/asm-generic/mman-common.h
> > > index 3b69ad3..12f5982 100644
> > > --- a/include/asm-generic/mman-common.h
> > > +++ b/include/asm-generic/mman-common.h
> > > @@ -19,6 +19,7 @@
> > > #define MAP_TYPE 0x0f /* Mask for type of mapping */
> > > #define MAP_FIXED 0x10 /* Interpret addr exactly */
> > > #define MAP_ANONYMOUS 0x20 /* don't use a file */
> > > +#define MAP_HUGETLB 0x40 /* create a huge page mapping */
> > >
> > > #define MS_ASYNC 1 /* sync memory asynchronously */
> > > #define MS_INVALIDATE 2 /* invalidate the caches */
> >
> > I'm afraid you can't put MAP_HUGETLB in mman-common.h: that is picked
> > up by most or all architectures (which is of course what you wanted!)
> > but conflicts with a definition in at least one of them. When I boot
> > up mmotm on powerpc, I get a warning:
> >
> > Using mlock ulimits for SHM_HUGETLB deprecated
> > ------------[ cut here ]------------
> > Badness at fs/hugetlbfs/inode.c:941
> > NIP: c0000000001f3038 LR: c0000000001f3034 CTR: 0000000000000000
> > REGS: c0000000275d7960 TRAP: 0700 Not tainted (2.6.31-rc7-mm2)
> > MSR: 9000000000029032 <EE,ME,CE,IR,DR> CR: 24000484 XER: 00000000
> > TASK = c000000029fa94a0[1321] 'console-kit-dae' THREAD: c0000000275d4000 CPU: 3
> > GPR00: c0000000001f3034 c0000000275d7be0 c00000000071a908 0000000000000032
> > GPR04: 0000000000000000 ffffffffffffffff ffffffffffffffff 0000000000000000
> > GPR08: c0000000297dc1d0 c0000000275d4000 d00008008247fa08 0000000000000000
> > GPR12: 0000000024000442 c00000000074ba00 000000000fedb9a4 000000001049cd18
> > GPR16: 00000000100365d0 00000000104a9100 000000000fefc350 00000000104a9098
> > GPR20: 00000000104a9160 000000000fefc238 0000000000000000 0000000000200000
> > GPR24: 0000000000000000 0000000001000000 c0000000275d7d20 0000000001000000
> > GPR28: c00000000058c738 ffffffffffffffb5 c0000000006a93d0 c000000000791400
> > NIP [c0000000001f3038] .hugetlb_file_setup+0xd0/0x254
> > LR [c0000000001f3034] .hugetlb_file_setup+0xcc/0x254
> > Call Trace:
> > [c0000000275d7be0] [c0000000001f3034] .hugetlb_file_setup+0xcc/0x254 (unreliable)
> > [c0000000275d7cb0] [c0000000000ee240] .do_mmap_pgoff+0x184/0x424
> > [c0000000275d7d80] [c00000000000a9c8] .sys_mmap+0xc4/0x13c
> > [c0000000275d7e30] [c0000000000075ac] syscall_exit+0x0/0x40
> > Instruction dump:
> > f89a0000 4bef7111 60000000 2c230000 41820034 e93e8018 80090014 2f800000
> > 40fe0030 e87e80b0 4823ff09 60000000 <0fe00000> e93e8018 38000001 90090014
> >
> > Which won't be coming from any use of MAP_HUGETLB, but presumably
> > from something using MAP_NORESERVE, defined as 0x40 in
> > arch/powerpc/include/asm/mman.h.
> >
> > I think you have to put your #define MAP_HUGETLB into
> > include/asm-generic/mman.h (seems used by only three architectures),
> > and into the arch/whatever/include/asm/mman.h of each architecture
> > which uses asm-generic/mman-common.h without asm-generic/mman.h.
> >
> > Hugh
> >
>
> This problem is the same that Mel Gorman reported (and fixed) in response to patch
> 1 of this series. I have forwarded the patch that addresses this problem on,
> but it has not been picked up.
>
> The bug is not where MAP_HUGETLB is defined, rather how the patch handled
> can_do_hugetlb_shm(). If MAP_HUGETLB was specified, can_do_hugetlb_shm() returned
> 0 forcing a call to user_shm_lock() which is responisble for the warning about
> SHM_HUGETLB and mlock ulimits. The fix is to check if the file is to be used
> for SHM_HUGETLB and if not, skip the calls to can_do_hugetlb_shm() and
> user_shm_lock().
Sorry, no, I disagree.
I agree that the fs/hugetlbfs/inode.c:941 message and backtrace in
themselves are symptoms of the can_do_hugetlb_shm() bug that Mel
reported and fixed (I'm agreeing a little too readily, I've not
actually studied that bug and fix, I'm taking it on trust).
But that does not explain how last year's openSUSE 11.1 userspace
was trying for a MAP_HUGETLB mapping at startup on PowerPC (but
not on x86), while you're only introducing MAP_HUGETLB now.
That is explained by you #defining MAP_HUGETLB in include/asm-generic/
mman-common.h to a number which is already being used for other MAP_s
on some architectures. That's a separate bug which needs to be fixed
by distributing the MAP_HUGETLB definition across various asm*/mman.h.
Hugh