From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric B Munson Subject: [PATCH 0/3] Add pseudo-anonymous huge page mappings V4 Date: Wed, 26 Aug 2009 11:44:50 +0100 Message-ID: Return-path: Sender: owner-linux-mm@kvack.org To: linux-kernel@vger.kernel.org, linux-mm@kvack.org, akpm@linux-foundation.org Cc: linux-man@vger.kernel.org, mtk.manpages@gmail.com, randy.dunlap@oracle.com, Eric B Munson List-Id: linux-man@vger.kernel.org This patch set adds a flag to mmap that allows the user to request a mapping to be backed with huge pages. This mapping will borrow functionality from the huge page shm code to create a file on the kernel internal mount and use it to approximate an anonymous mapping. The MAP_HUGETLB flag is a modifier to MAP_ANONYMOUS and will not work without both flags being preset. A new flag is necessary because there is no other way to hook into huge pages without creating a file on a hugetlbfs mount which wouldn't be MAP_ANONYMOUS. To userspace, this mapping will behave just like an anonymous mapping because the file is not accessible outside of the kernel. This patch set is meant to simplify the programming model, presently there is a large chunk of boiler plate code, contained in libhugetlbfs, required to create private, hugepage backed mappings. This patch set would allow use of hugepages without linking to libhugetlbfs or having hugetblfs mounted. Unification of the VM code would provide these same benefits, but it has been resisted each time that it has been suggested for several reasons: it would break PAGE_SIZE assumptions across the kernel, it makes page-table abstractions really expensive, and it does not provide any benefit on architectures that do not support huge pages, incurring fast path penalties without providing any benefit on these architectures. Eric B Munson (3): hugetlbfs: Allow the creation of files suitable for MAP_PRIVATE on the vfs internal mount Add MAP_HUGETLB for mmaping pseudo-anonymous huge page regions Add MAP_HUGETLB example Documentation/vm/00-INDEX | 2 + Documentation/vm/hugetlbpage.txt | 14 ++++--- Documentation/vm/map_hugetlb.c | 77 +++++++++++++++++++++++++++++++++++++ fs/hugetlbfs/inode.c | 21 ++++++++-- include/asm-generic/mman-common.h | 1 + include/linux/hugetlb.h | 19 ++++++++- ipc/shm.c | 2 +- mm/mmap.c | 19 +++++++++ 8 files changed, 142 insertions(+), 13 deletions(-) create mode 100644 Documentation/vm/map_hugetlb.c -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric B Munson Subject: [PATCH 2/3] Add MAP_HUGETLB for mmaping pseudo-anonymous huge page regions Date: Wed, 26 Aug 2009 11:44:52 +0100 Message-ID: <1721a3e8bdf8f311d2388951ec65a24d37b513b1.1251282769.git.ebmunson@us.ibm.com> References: <1c66a9e98a73d61c611e5cf09b276e954965046e.1251282769.git.ebmunson@us.ibm.com> Return-path: In-Reply-To: <1c66a9e98a73d61c611e5cf09b276e954965046e.1251282769.git.ebmunson@us.ibm.com> In-Reply-To: References: Sender: owner-linux-mm@kvack.org To: linux-kernel@vger.kernel.org, linux-mm@kvack.org, akpm@linux-foundation.org Cc: linux-man@vger.kernel.org, mtk.manpages@gmail.com, randy.dunlap@oracle.com, Eric B Munson List-Id: linux-man@vger.kernel.org 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 --- 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 */ diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h index 38bb552..b0bc0fd 100644 --- a/include/linux/hugetlb.h +++ b/include/linux/hugetlb.h @@ -110,12 +110,19 @@ static inline void hugetlb_report_meminfo(struct seq_file *m) #endif /* !CONFIG_HUGETLB_PAGE */ +#define HUGETLB_ANON_FILE "anon_hugepage" + enum { /* * The file will be used as an shm file so shmfs accounting rules * apply */ HUGETLB_SHMFS_INODE = 1, + /* + * The file is being created on the internal vfs mount and shmfs + * accounting rules do not apply + */ + HUGETLB_ANONHUGE_INODE = 2, }; #ifdef CONFIG_HUGETLBFS diff --git a/mm/mmap.c b/mm/mmap.c index 8101de4..9ca4f26 100644 --- a/mm/mmap.c +++ b/mm/mmap.c @@ -29,6 +29,7 @@ #include #include #include +#include #include #include @@ -951,6 +952,24 @@ unsigned long do_mmap_pgoff(struct file *file, unsigned long addr, if (mm->map_count > sysctl_max_map_count) return -ENOMEM; + if (flags & MAP_HUGETLB) { + struct user_struct *user = NULL; + if (file) + return -EINVAL; + + /* + * VM_NORESERVE is used because the reservations will be + * taken when vm_ops->mmap() is called + * A dummy user value is used because we are not locking + * memory so no accounting is necessary + */ + len = ALIGN(len, huge_page_size(&default_hstate)); + file = hugetlb_file_setup(HUGETLB_ANON_FILE, len, VM_NORESERVE, + &user, HUGETLB_ANONHUGE_INODE); + if (IS_ERR(file)) + return PTR_ERR(file); + } + /* Obtain the address to map to. we verify (or select) it and ensure * that it represents a valid section of the address space. */ -- 1.6.3.2 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric B Munson Subject: [PATCH 1/3] hugetlbfs: Allow the creation of files suitable for MAP_PRIVATE on the vfs internal mount Date: Wed, 26 Aug 2009 11:44:51 +0100 Message-ID: <1c66a9e98a73d61c611e5cf09b276e954965046e.1251282769.git.ebmunson@us.ibm.com> References: Return-path: In-Reply-To: In-Reply-To: References: Sender: owner-linux-mm@kvack.org To: linux-kernel@vger.kernel.org, linux-mm@kvack.org, akpm@linux-foundation.org Cc: linux-man@vger.kernel.org, mtk.manpages@gmail.com, randy.dunlap@oracle.com, Eric B Munson List-Id: linux-man@vger.kernel.org There are two means of creating mappings backed by huge pages: 1. mmap() a file created on hugetlbfs 2. Use shm which creates a file on an internal mount which essentially maps it MAP_SHARED The internal mount is only used for shared mappings but there is very little that stops it being used for private mappings. This patch extends hugetlbfs_file_setup() to deal with the creation of files that will be mapped MAP_PRIVATE on the internal hugetlbfs mount. This extended API is used in a subsequent patch to implement the MAP_HUGETLB mmap() flag. Signed-off-by: Eric Munson --- fs/hugetlbfs/inode.c | 21 +++++++++++++++++---- include/linux/hugetlb.h | 12 ++++++++++-- ipc/shm.c | 2 +- 3 files changed, 28 insertions(+), 7 deletions(-) diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c index cb88dac..5584d55 100644 --- a/fs/hugetlbfs/inode.c +++ b/fs/hugetlbfs/inode.c @@ -506,6 +506,13 @@ static struct inode *hugetlbfs_get_inode(struct super_block *sb, uid_t uid, inode->i_atime = inode->i_mtime = inode->i_ctime = CURRENT_TIME; INIT_LIST_HEAD(&inode->i_mapping->private_list); info = HUGETLBFS_I(inode); + /* + * The policy is initialized here even if we are creating a + * private inode because initialization simply creates an + * an empty rb tree and calls spin_lock_init(), later when we + * call mpol_free_shared_policy() it will just return because + * the rb tree will still be empty. + */ mpol_shared_policy_init(&info->policy, NULL); switch (mode & S_IFMT) { default: @@ -930,13 +937,19 @@ static struct file_system_type hugetlbfs_fs_type = { static struct vfsmount *hugetlbfs_vfsmount; -static int can_do_hugetlb_shm(void) +static int can_do_hugetlb_shm(int creat_flags) { - return capable(CAP_IPC_LOCK) || in_group_p(sysctl_hugetlb_shm_group); + if (creat_flags != HUGETLB_SHMFS_INODE) + return 0; + if (capable(CAP_IPC_LOCK)) + return 1; + if (in_group_p(sysctl_hugetlb_shm_group)) + return 1; + return 0; } struct file *hugetlb_file_setup(const char *name, size_t size, int acctflag, - struct user_struct **user) + struct user_struct **user, int creat_flags) { int error = -ENOMEM; struct file *file; @@ -948,7 +961,7 @@ struct file *hugetlb_file_setup(const char *name, size_t size, int acctflag, if (!hugetlbfs_vfsmount) return ERR_PTR(-ENOENT); - if (!can_do_hugetlb_shm()) { + if (!can_do_hugetlb_shm(creat_flags)) { *user = current_user(); if (user_shm_lock(size, *user)) { WARN_ONCE(1, diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h index 5cbc620..38bb552 100644 --- a/include/linux/hugetlb.h +++ b/include/linux/hugetlb.h @@ -110,6 +110,14 @@ static inline void hugetlb_report_meminfo(struct seq_file *m) #endif /* !CONFIG_HUGETLB_PAGE */ +enum { + /* + * The file will be used as an shm file so shmfs accounting rules + * apply + */ + HUGETLB_SHMFS_INODE = 1, +}; + #ifdef CONFIG_HUGETLBFS struct hugetlbfs_config { uid_t uid; @@ -148,7 +156,7 @@ static inline struct hugetlbfs_sb_info *HUGETLBFS_SB(struct super_block *sb) extern const struct file_operations hugetlbfs_file_operations; extern struct vm_operations_struct hugetlb_vm_ops; struct file *hugetlb_file_setup(const char *name, size_t size, int acct, - struct user_struct **user); + struct user_struct **user, int creat_flags); int hugetlb_get_quota(struct address_space *mapping, long delta); void hugetlb_put_quota(struct address_space *mapping, long delta); @@ -170,7 +178,7 @@ static inline void set_file_hugepages(struct file *file) #define is_file_hugepages(file) 0 #define set_file_hugepages(file) BUG() -#define hugetlb_file_setup(name,size,acct,user) ERR_PTR(-ENOSYS) +#define hugetlb_file_setup(name,size,acct,user,creat) ERR_PTR(-ENOSYS) #endif /* !CONFIG_HUGETLBFS */ diff --git a/ipc/shm.c b/ipc/shm.c index 1bc4701..5ba4962 100644 --- a/ipc/shm.c +++ b/ipc/shm.c @@ -370,7 +370,7 @@ static int newseg(struct ipc_namespace *ns, struct ipc_params *params) if (shmflg & SHM_NORESERVE) acctflag = VM_NORESERVE; file = hugetlb_file_setup(name, size, acctflag, - &shp->mlock_user); + &shp->mlock_user, HUGETLB_SHMFS_INODE); } else { /* * Do not allow no accounting for OVERCOMMIT_NEVER, even -- 1.6.3.2 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric B Munson Subject: [PATCH 2/3] Add MAP_HUGETLB for mmaping pseudo-anonymous huge page regions Date: Tue, 25 Aug 2009 12:14:53 +0100 Message-ID: <8504342f7be19e416ef769d1edd24b8549f8dc39.1251197514.git.ebmunson@us.ibm.com> References: <25614b0d0581e2d49e1024dc1671b282f193e139.1251197514.git.ebmunson@us.ibm.com> Return-path: In-Reply-To: <25614b0d0581e2d49e1024dc1671b282f193e139.1251197514.git.ebmunson@us.ibm.com> In-Reply-To: References: Sender: owner-linux-mm@kvack.org To: linux-kernel@vger.kernel.org, linux-mm@kvack.org, akpm@linux-foundation.org Cc: linux-man@vger.kernel.org, mtk.manpages@gmail.com, randy.dunlap@oracle.com, Eric B Munson List-Id: linux-man@vger.kernel.org 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 --- 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 */ diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h index 38bb552..b0bc0fd 100644 --- a/include/linux/hugetlb.h +++ b/include/linux/hugetlb.h @@ -110,12 +110,19 @@ static inline void hugetlb_report_meminfo(struct seq_file *m) #endif /* !CONFIG_HUGETLB_PAGE */ +#define HUGETLB_ANON_FILE "anon_hugepage" + enum { /* * The file will be used as an shm file so shmfs accounting rules * apply */ HUGETLB_SHMFS_INODE = 1, + /* + * The file is being created on the internal vfs mount and shmfs + * accounting rules do not apply + */ + HUGETLB_ANONHUGE_INODE = 2, }; #ifdef CONFIG_HUGETLBFS diff --git a/mm/mmap.c b/mm/mmap.c index 8101de4..9ca4f26 100644 --- a/mm/mmap.c +++ b/mm/mmap.c @@ -29,6 +29,7 @@ #include #include #include +#include #include #include @@ -951,6 +952,24 @@ unsigned long do_mmap_pgoff(struct file *file, unsigned long addr, if (mm->map_count > sysctl_max_map_count) return -ENOMEM; + if (flags & MAP_HUGETLB) { + struct user_struct *user = NULL; + if (file) + return -EINVAL; + + /* + * VM_NORESERVE is used because the reservations will be + * taken when vm_ops->mmap() is called + * A dummy user value is used because we are not locking + * memory so no accounting is necessary + */ + len = ALIGN(len, huge_page_size(&default_hstate)); + file = hugetlb_file_setup(HUGETLB_ANON_FILE, len, VM_NORESERVE, + &user, HUGETLB_ANONHUGE_INODE); + if (IS_ERR(file)) + return PTR_ERR(file); + } + /* Obtain the address to map to. we verify (or select) it and ensure * that it represents a valid section of the address space. */ -- 1.6.3.2 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric B Munson Subject: [PATCH 3/3] Add MAP_HUGETLB example Date: Wed, 26 Aug 2009 11:44:53 +0100 Message-ID: <745880949456dd59ee098722614dc329081100ee.1251282769.git.ebmunson@us.ibm.com> References: <1c66a9e98a73d61c611e5cf09b276e954965046e.1251282769.git.ebmunson@us.ibm.com> <1721a3e8bdf8f311d2388951ec65a24d37b513b1.1251282769.git.ebmunson@us.ibm.com> Return-path: In-Reply-To: <1721a3e8bdf8f311d2388951ec65a24d37b513b1.1251282769.git.ebmunson@us.ibm.com> In-Reply-To: References: Sender: owner-linux-mm@kvack.org To: linux-kernel@vger.kernel.org, linux-mm@kvack.org, akpm@linux-foundation.org Cc: linux-man@vger.kernel.org, mtk.manpages@gmail.com, randy.dunlap@oracle.com, Eric B Munson List-Id: linux-man@vger.kernel.org This patch adds an example of how to use the MAP_HUGETLB flag to the vm documentation directory and a reference to the example in hugetlbpage.txt. Signed-off-by: Eric B Munson Acked-by: David Rientjes --- Documentation/vm/00-INDEX | 2 + Documentation/vm/hugetlbpage.txt | 14 ++++--- Documentation/vm/map_hugetlb.c | 77 ++++++++++++++++++++++++++++++++++++++ 3 files changed, 87 insertions(+), 6 deletions(-) create mode 100644 Documentation/vm/map_hugetlb.c diff --git a/Documentation/vm/00-INDEX b/Documentation/vm/00-INDEX index 2f77ced..aabd973 100644 --- a/Documentation/vm/00-INDEX +++ b/Documentation/vm/00-INDEX @@ -20,3 +20,5 @@ slabinfo.c - source code for a tool to get reports about slabs. slub.txt - a short users guide for SLUB. +map_hugetlb.c + - an example program that uses the MAP_HUGETLB mmap flag. diff --git a/Documentation/vm/hugetlbpage.txt b/Documentation/vm/hugetlbpage.txt index ea8714f..6a8feab 100644 --- a/Documentation/vm/hugetlbpage.txt +++ b/Documentation/vm/hugetlbpage.txt @@ -146,12 +146,14 @@ Regular chown, chgrp, and chmod commands (with right permissions) could be used to change the file attributes on hugetlbfs. Also, it is important to note that no such mount command is required if the -applications are going to use only shmat/shmget system calls. Users who -wish to use hugetlb page via shared memory segment should be a member of -a supplementary group and system admin needs to configure that gid into -/proc/sys/vm/hugetlb_shm_group. It is possible for same or different -applications to use any combination of mmaps and shm* calls, though the -mount of filesystem will be required for using mmap calls. +applications are going to use only shmat/shmget system calls or mmap with +MAP_HUGETLB. Users who wish to use hugetlb page via shared memory segment +should be a member of a supplementary group and system admin needs to +configure that gid into /proc/sys/vm/hugetlb_shm_group. It is possible for +same or different applications to use any combination of mmaps and shm* +calls, though the mount of filesystem will be required for using mmap calls +without MAP_HUGETLB. For an example of how to use mmap with MAP_HUGETLB see +map_hugetlb.c. ******************************************************************* diff --git a/Documentation/vm/map_hugetlb.c b/Documentation/vm/map_hugetlb.c new file mode 100644 index 0000000..e2bdae3 --- /dev/null +++ b/Documentation/vm/map_hugetlb.c @@ -0,0 +1,77 @@ +/* + * Example of using hugepage memory in a user application using the mmap + * system call with MAP_HUGETLB flag. Before running this program make + * sure the administrator has allocated enough default sized huge pages + * to cover the 256 MB allocation. + * + * For ia64 architecture, Linux kernel reserves Region number 4 for hugepages. + * That means the addresses starting with 0x800000... will need to be + * specified. Specifying a fixed address is not required on ppc64, i386 + * or x86_64. + */ +#include +#include +#include +#include +#include + +#define LENGTH (256UL*1024*1024) +#define PROTECTION (PROT_READ | PROT_WRITE) + +#ifndef MAP_HUGETLB +#define MAP_HUGETLB 0x40 +#endif + +/* Only ia64 requires this */ +#ifdef __ia64__ +#define ADDR (void *)(0x8000000000000000UL) +#define FLAGS (MAP_PRIVATE | MAP_ANONYMOUS | MAP_HUGETLB | MAP_FIXED) +#else +#define ADDR (void *)(0x0UL) +#define FLAGS (MAP_PRIVATE | MAP_ANONYMOUS | MAP_HUGETLB) +#endif + +void check_bytes(char *addr) +{ + printf("First hex is %x\n", *((unsigned int *)addr)); +} + +void write_bytes(char *addr) +{ + unsigned long i; + + for (i = 0; i < LENGTH; i++) + *(addr + i) = (char)i; +} + +void read_bytes(char *addr) +{ + unsigned long i; + + check_bytes(addr); + for (i = 0; i < LENGTH; i++) + if (*(addr + i) != (char)i) { + printf("Mismatch at %lu\n", i); + break; + } +} + +int main(void) +{ + void *addr; + + addr = mmap(ADDR, LENGTH, PROTECTION, FLAGS, 0, 0); + if (addr == MAP_FAILED) { + perror("mmap"); + exit(1); + } + + printf("Returned address is %p\n", addr); + check_bytes(addr); + write_bytes(addr); + read_bytes(addr); + + munmap(addr, LENGTH); + + return 0; +} -- 1.6.3.2 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mel Gorman Subject: Re: [PATCH 1/3] hugetlbfs: Allow the creation of files suitable for MAP_PRIVATE on the vfs internal mount Date: Thu, 27 Aug 2009 15:18:34 +0100 Message-ID: <20090827141834.GF21183@csn.ul.ie> References: <1c66a9e98a73d61c611e5cf09b276e954965046e.1251282769.git.ebmunson@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Return-path: Content-Disposition: inline In-Reply-To: <1c66a9e98a73d61c611e5cf09b276e954965046e.1251282769.git.ebmunson-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> Sender: linux-man-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Eric B Munson Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org, akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org, linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, randy.dunlap-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org List-Id: linux-man@vger.kernel.org On Wed, Aug 26, 2009 at 11:44:51AM +0100, Eric B Munson wrote: > There are two means of creating mappings backed by huge pages: > > 1. mmap() a file created on hugetlbfs > 2. Use shm which creates a file on an internal mount which essentially > maps it MAP_SHARED > > The internal mount is only used for shared mappings but there is very > little that stops it being used for private mappings. This patch extends > hugetlbfs_file_setup() to deal with the creation of files that will be > mapped MAP_PRIVATE on the internal hugetlbfs mount. This extended API is > used in a subsequent patch to implement the MAP_HUGETLB mmap() flag. > Hi Eric, I ran these patches through a series of small tests and I have just one concern with the changes made to can_do_hugetlb_shm(). If that returns false because of MAP_HUGETLB, we then proceed to call user_shm_lock(). I think your intention might have been something like the following patch on top of yours? For what it's worth, once this was applied, I didn't spot any other problems, run-time or otherwise. ===== hugetlbfs: Do not call user_shm_lock() for MAP_HUGETLB The patch hugetlbfs-allow-the-creation-of-files-suitable-for-map_private-on-the-vfs-internal-mount.patch alters can_do_hugetlb_shm() to check if a file is being created for shared memory or mmap(). If this returns false, we then unconditionally call user_shm_lock() triggering a warning. This block should never be entered for MAP_HUGETLB. This patch partially reverts the problem and fixes the check. This patch should be considered a fix to hugetlbfs-allow-the-creation-of-files-suitable-for-map_private-on-the-vfs-internal-mount.patch. Signed-off-by: Mel Gorman --- fs/hugetlbfs/inode.c | 12 +++--------- 1 file changed, 3 insertions(+), 9 deletions(-) diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c index 49d2bf9..c944cc1 100644 --- a/fs/hugetlbfs/inode.c +++ b/fs/hugetlbfs/inode.c @@ -910,15 +910,9 @@ static struct file_system_type hugetlbfs_fs_type = { static struct vfsmount *hugetlbfs_vfsmount; -static int can_do_hugetlb_shm(int creat_flags) +static int can_do_hugetlb_shm(void) { - if (creat_flags != HUGETLB_SHMFS_INODE) - return 0; - if (capable(CAP_IPC_LOCK)) - return 1; - if (in_group_p(sysctl_hugetlb_shm_group)) - return 1; - return 0; + return capable(CAP_IPC_LOCK) || in_group_p(sysctl_hugetlb_shm_group); } struct file *hugetlb_file_setup(const char *name, size_t size, int acctflag, @@ -934,7 +928,7 @@ struct file *hugetlb_file_setup(const char *name, size_t size, int acctflag, if (!hugetlbfs_vfsmount) return ERR_PTR(-ENOENT); - if (!can_do_hugetlb_shm(creat_flags)) { + if (creat_flags == HUGETLB_SHMFS_INODE && !can_do_hugetlb_shm()) { *user = current_user(); if (user_shm_lock(size, *user)) { WARN_ONCE(1, -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric B Munson Subject: Re: [PATCH 1/3] hugetlbfs: Allow the creation of files suitable for MAP_PRIVATE on the vfs internal mount Date: Thu, 27 Aug 2009 16:11:08 +0100 Message-ID: <20090827151108.GC6323@us.ibm.com> References: <1c66a9e98a73d61c611e5cf09b276e954965046e.1251282769.git.ebmunson@us.ibm.com> <20090827141834.GF21183@csn.ul.ie> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="H8ygTp4AXg6deix2" Return-path: Content-Disposition: inline In-Reply-To: <20090827141834.GF21183@csn.ul.ie> Sender: owner-linux-mm@kvack.org To: Mel Gorman Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, akpm@linux-foundation.org, linux-man@vger.kernel.org, mtk.manpages@gmail.com, randy.dunlap@oracle.com List-Id: linux-man@vger.kernel.org --H8ygTp4AXg6deix2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, 27 Aug 2009, Mel Gorman wrote: > On Wed, Aug 26, 2009 at 11:44:51AM +0100, Eric B Munson wrote: > > There are two means of creating mappings backed by huge pages: > >=20 > > 1. mmap() a file created on hugetlbfs > > 2. Use shm which creates a file on an internal mount which esse= ntially > > maps it MAP_SHARED > >=20 > > The internal mount is only used for shared mappings but there is very > > little that stops it being used for private mappings. This patch extends > > hugetlbfs_file_setup() to deal with the creation of files that will be > > mapped MAP_PRIVATE on the internal hugetlbfs mount. This extended API is > > used in a subsequent patch to implement the MAP_HUGETLB mmap() flag. > >=20 >=20 > Hi Eric, >=20 > I ran these patches through a series of small tests and I have just one > concern with the changes made to can_do_hugetlb_shm(). If that returns fa= lse > because of MAP_HUGETLB, we then proceed to call user_shm_lock(). I think = your > intention might have been something like the following patch on top of yo= urs? >=20 > For what it's worth, once this was applied, I didn't spot any other > problems, run-time or otherwise. >=20 I am seeing the same thing, terminal says segfault with no memory, dmesg complains about SHM. Your patch fixes the issue. Thanks. > =3D=3D=3D=3D=3D > hugetlbfs: Do not call user_shm_lock() for MAP_HUGETLB >=20 > The patch > hugetlbfs-allow-the-creation-of-files-suitable-for-map_private-on-the-vfs= -internal-mount.patch > alters can_do_hugetlb_shm() to check if a file is being created for shared > memory or mmap(). If this returns false, we then unconditionally call > user_shm_lock() triggering a warning. This block should never be entered > for MAP_HUGETLB. This patch partially reverts the problem and fixes the c= heck. >=20 > This patch should be considered a fix to > hugetlbfs-allow-the-creation-of-files-suitable-for-map_private-on-the-vfs= -internal-mount.patch. >=20 > Signed-off-by: Mel Gorman > ---=20 > fs/hugetlbfs/inode.c | 12 +++--------- > 1 file changed, 3 insertions(+), 9 deletions(-) >=20 > diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c > index 49d2bf9..c944cc1 100644 > --- a/fs/hugetlbfs/inode.c > +++ b/fs/hugetlbfs/inode.c > @@ -910,15 +910,9 @@ static struct file_system_type hugetlbfs_fs_type =3D= { >=20 > static struct vfsmount *hugetlbfs_vfsmount; >=20 > -static int can_do_hugetlb_shm(int creat_flags) > +static int can_do_hugetlb_shm(void) > { > - if (creat_flags !=3D HUGETLB_SHMFS_INODE) > - return 0; > - if (capable(CAP_IPC_LOCK)) > - return 1; > - if (in_group_p(sysctl_hugetlb_shm_group)) > - return 1; > - return 0; > + return capable(CAP_IPC_LOCK) || in_group_p(sysctl_hugetlb_shm_group); > } >=20 > struct file *hugetlb_file_setup(const char *name, size_t size, int acctf= lag, > @@ -934,7 +928,7 @@ struct file *hugetlb_file_setup(const char *name, siz= e_t size, int acctflag, > if (!hugetlbfs_vfsmount) > return ERR_PTR(-ENOENT); >=20 > - if (!can_do_hugetlb_shm(creat_flags)) { > + if (creat_flags =3D=3D HUGETLB_SHMFS_INODE && !can_do_hugetlb_shm()) { > *user =3D current_user(); > if (user_shm_lock(size, *user)) { > WARN_ONCE(1, >=20 >=20 --=20 Eric B Munson IBM Linux Technology Center ebmunson@us.ibm.com --H8ygTp4AXg6deix2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkqWogwACgkQsnv9E83jkzpa4QCgjsXwbpOD5X6x+8RcC66yZ0jb HGQAnR7qpYpfzfOQO9jadJXoRAkvktQt =Qf8/ -----END PGP SIGNATURE----- --H8ygTp4AXg6deix2-- -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hugh Dickins Subject: Re: [PATCH 2/3] Add MAP_HUGETLB for mmaping pseudo-anonymous huge page regions Date: Mon, 31 Aug 2009 20:49:38 +0100 (BST) Message-ID: References: <1c66a9e98a73d61c611e5cf09b276e954965046e.1251282769.git.ebmunson@us.ibm.com> <1721a3e8bdf8f311d2388951ec65a24d37b513b1.1251282769.git.ebmunson@us.ibm.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-path: In-Reply-To: <1721a3e8bdf8f311d2388951ec65a24d37b513b1.1251282769.git.ebmunson@us.ibm.com> Sender: owner-linux-mm@kvack.org To: Eric B Munson Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, akpm@linux-foundation.org, linux-man@vger.kernel.org, mtk.manpages@gmail.com, randy.dunlap@oracle.com List-Id: linux-man@vger.kernel.org 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 > --- > 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 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 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric B Munson Subject: Re: [PATCH 2/3] Add MAP_HUGETLB for mmaping pseudo-anonymous huge page regions Date: Tue, 1 Sep 2009 10:46:35 +0100 Message-ID: <20090901094635.GA7995@us.ibm.com> References: <1c66a9e98a73d61c611e5cf09b276e954965046e.1251282769.git.ebmunson@us.ibm.com> <1721a3e8bdf8f311d2388951ec65a24d37b513b1.1251282769.git.ebmunson@us.ibm.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vkogqOf2sHV7VnPd" Return-path: Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org To: Hugh Dickins Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, akpm@linux-foundation.org, linux-man@vger.kernel.org, mtk.manpages@gmail.com, randy.dunlap@oracle.com List-Id: linux-man@vger.kernel.org --vkogqOf2sHV7VnPd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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. > >=20 > > Signed-off-by: Eric B Munson > > --- > > include/asm-generic/mman-common.h | 1 + > > include/linux/hugetlb.h | 7 +++++++ > > mm/mmap.c | 19 +++++++++++++++++++ > > 3 files changed, 27 insertions(+), 0 deletions(-) > >=20 > > diff --git a/include/asm-generic/mman-common.h b/include/asm-generic/mm= an-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 */ > > =20 > > #define MS_ASYNC 1 /* sync memory asynchronously */ > > #define MS_INVALIDATE 2 /* invalidate the caches */ >=20 > 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: >=20 > 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 CR: 24000484 XER: 00000000 > TASK =3D c000000029fa94a0[1321] 'console-kit-dae' THREAD: c0000000275d400= 0 CPU: 3 > GPR00: c0000000001f3034 c0000000275d7be0 c00000000071a908 000000000000003= 2=20 > GPR04: 0000000000000000 ffffffffffffffff ffffffffffffffff 000000000000000= 0=20 > GPR08: c0000000297dc1d0 c0000000275d4000 d00008008247fa08 000000000000000= 0=20 > GPR12: 0000000024000442 c00000000074ba00 000000000fedb9a4 000000001049cd1= 8=20 > GPR16: 00000000100365d0 00000000104a9100 000000000fefc350 00000000104a909= 8=20 > GPR20: 00000000104a9160 000000000fefc238 0000000000000000 000000000020000= 0=20 > GPR24: 0000000000000000 0000000001000000 c0000000275d7d20 000000000100000= 0=20 > GPR28: c00000000058c738 ffffffffffffffb5 c0000000006a93d0 c00000000079140= 0=20 > NIP [c0000000001f3038] .hugetlb_file_setup+0xd0/0x254 > LR [c0000000001f3034] .hugetlb_file_setup+0xcc/0x254 > Call Trace: > [c0000000275d7be0] [c0000000001f3034] .hugetlb_file_setup+0xcc/0x254 (unr= eliable) > [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= =20 > 40fe0030 e87e80b0 4823ff09 60000000 <0fe00000> e93e8018 38000001 90090014= =20 >=20 > 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. >=20 > 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. >=20 > Hugh >=20 This problem is the same that Mel Gorman reported (and fixed) in response t= o patch 1 of this series. I have forwarded the patch that addresses this problem o= n, 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() r= eturned 0 forcing a call to user_shm_lock() which is responisble for the warning ab= out SHM_HUGETLB and mlock ulimits. The fix is to check if the file is to be us= ed for SHM_HUGETLB and if not, skip the calls to can_do_hugetlb_shm() and user_shm_lock(). --=20 Eric B Munson IBM Linux Technology Center ebmunson@us.ibm.com --vkogqOf2sHV7VnPd Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkqc7XsACgkQsnv9E83jkzpiPwCdEkAH/N91E/5prikUSq78Z/EG M2UAoOsh4+B7oWtVBGYgiLmZoLkxcLaf =GM+W -----END PGP SIGNATURE----- --vkogqOf2sHV7VnPd-- -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hugh Dickins Subject: Re: [PATCH 2/3] Add MAP_HUGETLB for mmaping pseudo-anonymous huge page regions Date: Tue, 1 Sep 2009 11:41:41 +0100 (BST) Message-ID: References: <1c66a9e98a73d61c611e5cf09b276e954965046e.1251282769.git.ebmunson@us.ibm.com> <1721a3e8bdf8f311d2388951ec65a24d37b513b1.1251282769.git.ebmunson@us.ibm.com> <20090901094635.GA7995@us.ibm.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-path: In-Reply-To: <20090901094635.GA7995-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> Sender: linux-man-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Eric B Munson Cc: Mel Gorman , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org, akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org, linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, randy.dunlap-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org List-Id: linux-man@vger.kernel.org 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 > > > --- > > > 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 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 -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric B Munson Subject: Re: [PATCH 2/3] Add MAP_HUGETLB for mmaping pseudo-anonymous huge page regions Date: Tue, 1 Sep 2009 14:08:01 +0100 Message-ID: <20090901130801.GB7995@us.ibm.com> References: <1c66a9e98a73d61c611e5cf09b276e954965046e.1251282769.git.ebmunson@us.ibm.com> <1721a3e8bdf8f311d2388951ec65a24d37b513b1.1251282769.git.ebmunson@us.ibm.com> <20090901094635.GA7995@us.ibm.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lEGEL1/lMxI0MVQ2" Return-path: Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org To: Hugh Dickins Cc: Mel Gorman , linux-kernel@vger.kernel.org, linux-mm@kvack.org, akpm@linux-foundation.org, linux-man@vger.kernel.org, mtk.manpages@gmail.com, randy.dunlap@oracle.com List-Id: linux-man@vger.kernel.org --lEGEL1/lMxI0MVQ2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, 01 Sep 2009, Hugh Dickins wrote: snip >=20 > Sorry, no, I disagree. >=20 > 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). >=20 > 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. >=20 > 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. >=20 > Hugh >=20 Would it be okay to keep the define in include/asm-generic/mman.h if a value that is known free across all architectures is used? 0x080000 is not used by any arch and, AFAICT would work just as well. --=20 Eric B Munson IBM Linux Technology Center ebmunson@us.ibm.com --lEGEL1/lMxI0MVQ2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkqdHLEACgkQsnv9E83jkzr89ACdECI9i/3KubokFNiLAPhLViqC i4MAoM1nvr8YwK+B5DCiggN1AvbMge4z =MUAy -----END PGP SIGNATURE----- --lEGEL1/lMxI0MVQ2-- -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hugh Dickins Subject: Re: [PATCH 2/3] Add MAP_HUGETLB for mmaping pseudo-anonymous huge page regions Date: Tue, 1 Sep 2009 14:34:09 +0100 (BST) Message-ID: References: <1c66a9e98a73d61c611e5cf09b276e954965046e.1251282769.git.ebmunson@us.ibm.com> <1721a3e8bdf8f311d2388951ec65a24d37b513b1.1251282769.git.ebmunson@us.ibm.com> <20090901094635.GA7995@us.ibm.com> <20090901130801.GB7995@us.ibm.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-path: In-Reply-To: <20090901130801.GB7995-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> Sender: linux-man-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Eric B Munson Cc: Arnd Bergman , Mel Gorman , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org, akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org, linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Michael Kerrisk , randy.dunlap-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org List-Id: linux-man@vger.kernel.org On Tue, 1 Sep 2009, Eric B Munson wrote: > On Tue, 01 Sep 2009, Hugh Dickins wrote: > > > > 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. > > Would it be okay to keep the define in include/asm-generic/mman.h > if a value that is known free across all architectures is used? > 0x080000 is not used by any arch and, AFAICT would work just as well. That's a very sensible suggestion, but departs from how we have assigned new numbers up until now: so include/asm-generic/mman-common.h isn't actually where we'd expect to find a Linux-specific MAP_ define. I'd say, yes, do that for now, so as not to hit this conflict while testing in mmotm. But whether it should stay that way, or later the arch/*/include/asm/mman.h's be updated as I'd imagined, I don't know. Arnd, Michael, do you have any views on this? Thanks, Hugh -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arnd Bergmann Subject: Re: [PATCH 2/3] Add MAP_HUGETLB for mmaping pseudo-anonymous huge page regions Date: Wed, 2 Sep 2009 10:34:40 +0200 Message-ID: <200909021034.40827.arnd@arndb.de> References: <20090901130801.GB7995@us.ibm.com> Mime-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: linux-man-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Hugh Dickins Cc: Eric B Munson , Mel Gorman , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org, akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org, linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Michael Kerrisk , randy.dunlap-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org List-Id: linux-man@vger.kernel.org On Tuesday 01 September 2009, Hugh Dickins wrote: > On Tue, 1 Sep 2009, Eric B Munson wrote: > > On Tue, 01 Sep 2009, Hugh Dickins wrote: > > > > > > 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. > > > > Would it be okay to keep the define in include/asm-generic/mman.h > > if a value that is known free across all architectures is used? > > 0x080000 is not used by any arch and, AFAICT would work just as well. > > That's a very sensible suggestion, but departs from how we have > assigned new numbers up until now: so include/asm-generic/mman-common.h > isn't actually where we'd expect to find a Linux-specific MAP_ define. > > I'd say, yes, do that for now, so as not to hit this conflict while > testing in mmotm. But whether it should stay that way, or later the > arch/*/include/asm/mman.h's be updated as I'd imagined, I don't know. > > Arnd, Michael, do you have any views on this? The minimal procedure would be to add it to mman-common.h, plus the asm/mman.h files for xtensa, mips, parisc and alpha, which all use a version that is compatible to a Unix variant, but that would be confusing the next person that needs to add a flag. I'd use the number 0x40000 for all architectures except alpha, because that makes the most sense for asm-generic/mman.h. Alpha is weird anyway here, so we don't need to avoid conflicts with it. With a few exceptions (sparc, powerpc), I think we should change all architectures to use asm-generic/mman.h instead of mman-common.h in the long run. If you touch those anyway, one option would be to do it in one step. Arnd <>< -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric B Munson Subject: [PATCH] MAP_HUGETLB value collision fix Date: Wed, 2 Sep 2009 13:15:36 +0100 Message-ID: <1251893736-12452-1-git-send-email-ebmunson@us.ibm.com> References: Return-path: In-Reply-To: References: <1c66a9e98a73d61c611e5cf09b276e954965046e.1251282769.git.ebmunson@us.ibm.com> <1721a3e8bdf8f311d2388951ec65a24d37b513b1.1251282769.git.ebmunson@us.ibm.com> Sender: owner-linux-mm@kvack.org To: akpm@linux-foundation.org Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-man@vger.kernel.org, mtk.manpages@gmail.com, randy.dunlap@oracle.com, hugh.dickins@tiscali.co.uk, Eric B Munson List-Id: linux-man@vger.kernel.org The patch hugetlb-add-map_hugetlb-for-mmaping-pseudo-anonymous-huge-page-regions.patch used the value 0x40 for MAP_HUGETLB which is the same value used for various other flags on some architectures. This collision causes unexpected use of huge pages in the best case and mmap to fail with ENOMEM or ENOSYS in the worst. This patch changes the value for MAP_HUGETLB to a value that is not currently used on any arch. This patch should be considered a fix to hugetlb-add-map_hugetlb-for-mmaping-pseudo-anonymous-huge-page-regions.patch. Reported-by: Hugh Dickins Signed-off-by: Eric B Munson --- include/asm-generic/mman-common.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/asm-generic/mman-common.h b/include/asm-generic/mman-common.h index 12f5982..e6adb68 100644 --- a/include/asm-generic/mman-common.h +++ b/include/asm-generic/mman-common.h @@ -19,7 +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 MAP_HUGETLB 0x080000 /* create a huge page mapping */ #define MS_ASYNC 1 /* sync memory asynchronously */ #define MS_INVALIDATE 2 /* invalidate the caches */ -- 1.6.3.2 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric B Munson Subject: [PATCH] MAP_HUGETLB value collision fix Date: Wed, 9 Sep 2009 10:16:51 +0100 Message-ID: <1252487811-9205-1-git-send-email-ebmunson@us.ibm.com> References: <1c66a9e98a73d61c611e5cf09b276e954965046e.1251282769.git.ebmunson@us.ibm.com> <1721a3e8bdf8f311d2388951ec65a24d37b513b1.1251282769.git.ebmunson@us.ibm.com> Return-path: Sender: owner-linux-mm@kvack.org To: akpm@linux-foundation.org Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-man@vger.kernel.org, mtk.manpages@gmail.com, randy.dunlap@oracle.com, hugh.dickins@tiscali.co.uk, Eric B Munson List-Id: linux-man@vger.kernel.org The patch hugetlb-add-map_hugetlb-for-mmaping-pseudo-anonymous-huge-page-regions.patch used the value 0x40 for MAP_HUGETLB which is the same value used for various other flags on some architectures. This collision causes unexpected use of huge pages in the best case and mmap to fail with ENOMEM or ENOSYS in the worst. This patch changes the value for MAP_HUGETLB to a value that is not currently used on any arch. This patch should be considered a fix to hugetlb-add-map_hugetlb-for-mmaping-pseudo-anonymous-huge-page-regions.patch. Reported-by: Hugh Dickins Signed-off-by: Eric B Munson --- include/asm-generic/mman-common.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/asm-generic/mman-common.h b/include/asm-generic/mman-common.h index 12f5982..e6adb68 100644 --- a/include/asm-generic/mman-common.h +++ b/include/asm-generic/mman-common.h @@ -19,7 +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 MAP_HUGETLB 0x080000 /* create a huge page mapping */ #define MS_ASYNC 1 /* sync memory asynchronously */ #define MS_INVALIDATE 2 /* invalidate the caches */ -- 1.6.3.2 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric B Munson Subject: [PATCH] Fix for hugetlb-add-map_hugetlb-for-mmaping-pseudo-anonymous-huge-page-regions.patch in -mm Date: Tue, 15 Sep 2009 11:46:53 +0100 Message-ID: <1253011613-6429-1-git-send-email-ebmunson@us.ibm.com> References: <1252487811-9205-1-git-send-email-ebmunson@us.ibm.com> Return-path: In-Reply-To: <1252487811-9205-1-git-send-email-ebmunson@us.ibm.com> References: <1c66a9e98a73d61c611e5cf09b276e954965046e.1251282769.git.ebmunson@us.ibm.com> <1721a3e8bdf8f311d2388951ec65a24d37b513b1.1251282769.git.ebmunson@us.ibm.com> Sender: owner-linux-mm@kvack.org To: akpm@linux-foundation.org Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-man@vger.kernel.org, mtk.manpages@gmail.com, randy.dunlap@oracle.com, hugh.dickins@tiscali.co.uk, Eric B Munson List-Id: linux-man@vger.kernel.org Resending because this seems to have fallen between the cracks. The patch hugetlb-add-map_hugetlb-for-mmaping-pseudo-anonymous-huge-page-regions.patch used the value 0x40 for MAP_HUGETLB which is the same value used for various other flags on some architectures. This collision causes unexpected use of huge pages in the best case and mmap to fail with ENOMEM or ENOSYS in the worst. This patch changes the value for MAP_HUGETLB to a value that is not currently used on any arch. This patch should be considered a fix to hugetlb-add-map_hugetlb-for-mmaping-pseudo-anonymous-huge-page-regions.patch. Reported-by: Hugh Dickins Signed-off-by: Eric B Munson --- include/asm-generic/mman-common.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/asm-generic/mman-common.h b/include/asm-generic/mman-common.h index 12f5982..e6adb68 100644 --- a/include/asm-generic/mman-common.h +++ b/include/asm-generic/mman-common.h @@ -19,7 +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 MAP_HUGETLB 0x080000 /* create a huge page mapping */ #define MS_ASYNC 1 /* sync memory asynchronously */ #define MS_INVALIDATE 2 /* invalidate the caches */ -- 1.6.3.2 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hugh Dickins Subject: Re: [PATCH] Fix for hugetlb-add-map_hugetlb-for-mmaping-pseudo-anonymous-huge-page-regions.patch in -mm Date: Tue, 15 Sep 2009 21:53:12 +0100 (BST) Message-ID: References: <1252487811-9205-1-git-send-email-ebmunson@us.ibm.com> <1253011613-6429-1-git-send-email-ebmunson@us.ibm.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-path: In-Reply-To: <1253011613-6429-1-git-send-email-ebmunson@us.ibm.com> Sender: owner-linux-mm@kvack.org To: Eric B Munson Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-man@vger.kernel.org, mtk.manpages@gmail.com, randy.dunlap@oracle.com, Arnd Bergman List-Id: linux-man@vger.kernel.org On Tue, 15 Sep 2009, Eric B Munson wrote: > Resending because this seems to have fallen between the cracks. Yes, indeed. I think it isn't quite what Arnd was suggesting, but I agree with you that we might as well go for 0x080000 (so that even Alpha can be just a cut-and-paste job from asm-generic), and right now it's more important to finalize the number than what file it appears in. Acked-by: Hugh Dickins > > The patch > hugetlb-add-map_hugetlb-for-mmaping-pseudo-anonymous-huge-page-regions.patch > used the value 0x40 for MAP_HUGETLB which is the same value used for > various other flags on some architectures. This collision causes > unexpected use of huge pages in the best case and mmap to fail with > ENOMEM or ENOSYS in the worst. This patch changes the value for > MAP_HUGETLB to a value that is not currently used on any arch. > > This patch should be considered a fix to > hugetlb-add-map_hugetlb-for-mmaping-pseudo-anonymous-huge-page-regions.patch. > > Reported-by: Hugh Dickins > Signed-off-by: Eric B Munson > --- > include/asm-generic/mman-common.h | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/include/asm-generic/mman-common.h b/include/asm-generic/mman-common.h > index 12f5982..e6adb68 100644 > --- a/include/asm-generic/mman-common.h > +++ b/include/asm-generic/mman-common.h > @@ -19,7 +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 MAP_HUGETLB 0x080000 /* create a huge page mapping */ > > #define MS_ASYNC 1 /* sync memory asynchronously */ > #define MS_INVALIDATE 2 /* invalidate the caches */ > -- > 1.6.3.2 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Morton Subject: Re: [PATCH 2/3] Add MAP_HUGETLB for mmaping pseudo-anonymous huge page regions Date: Thu, 17 Sep 2009 15:44:04 -0700 Message-ID: <20090917154404.e1d3694e.akpm@linux-foundation.org> References: <25614b0d0581e2d49e1024dc1671b282f193e139.1251197514.git.ebmunson@us.ibm.com> <8504342f7be19e416ef769d1edd24b8549f8dc39.1251197514.git.ebmunson@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <8504342f7be19e416ef769d1edd24b8549f8dc39.1251197514.git.ebmunson@us.ibm.com> Sender: owner-linux-mm@kvack.org Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-man@vger.kernel.org, mtk.manpages@gmail.com, randy.dunlap@oracle.com, ebmunson@us.ibm.com, Richard Henderson , Ivan Kokshaysky List-Id: linux-man@vger.kernel.org On Tue, 25 Aug 2009 12:14:53 +0100 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 > --- > include/asm-generic/mman-common.h | 1 + > include/linux/hugetlb.h | 7 +++++++ > mm/mmap.c | 19 +++++++++++++++++++ alpha fix: From: Andrew Morton mm/mmap.c: In function 'do_mmap_pgoff': mm/mmap.c:953: error: 'MAP_HUGETLB' undeclared (first use in this function) mm/mmap.c:953: error: (Each undeclared identifier is reported only once mm/mmap.c:953: error: for each function it appears in.) Cc: Adam Litke Cc: David Gibson Cc: David Rientjes Cc: Eric B Munson Cc: Hugh Dickins Cc: Lee Schermerhorn Cc: Mel Gorman Cc: Nick Piggin Cc: Ivan Kokshaysky Cc: Richard Henderson Signed-off-by: Andrew Morton --- arch/alpha/include/asm/mman.h | 1 + 1 file changed, 1 insertion(+) diff -puN arch/alpha/include/asm/mman.h~hugetlb-add-map_hugetlb-for-mmaping-pseudo-anonymous-huge-page-regions-alpha-fix arch/alpha/include/asm/mman.h --- a/arch/alpha/include/asm/mman.h~hugetlb-add-map_hugetlb-for-mmaping-pseudo-anonymous-huge-page-regions-alpha-fix +++ a/arch/alpha/include/asm/mman.h @@ -28,6 +28,7 @@ #define MAP_NORESERVE 0x10000 /* don't check for reservations */ #define MAP_POPULATE 0x20000 /* populate (prefault) pagetables */ #define MAP_NONBLOCK 0x40000 /* do not block on IO */ +#define MAP_HUGETLB 0x80000 /* create a huge page mapping */ #define MS_ASYNC 1 /* sync memory asynchronously */ #define MS_SYNC 2 /* synchronous memory sync */ _ -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Morton Subject: Re: [PATCH 2/3] Add MAP_HUGETLB for mmaping pseudo-anonymous huge page regions Date: Thu, 17 Sep 2009 17:46:16 -0700 Message-ID: <20090917174616.f64123fb.akpm@linux-foundation.org> References: <25614b0d0581e2d49e1024dc1671b282f193e139.1251197514.git.ebmunson@us.ibm.com> <8504342f7be19e416ef769d1edd24b8549f8dc39.1251197514.git.ebmunson@us.ibm.com> <20090917154404.e1d3694e.akpm@linux-foundation.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20090917154404.e1d3694e.akpm@linux-foundation.org> Sender: owner-linux-mm@kvack.org To: ebmunson@us.ibm.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-man@vger.kernel.org, mtk.manpages@gmail.com, randy.dunlap@oracle.com, rth@twiddle.net, ink@ju List-Id: linux-man@vger.kernel.org On Thu, 17 Sep 2009 15:44:04 -0700 Andrew Morton wrote: > mm/mmap.c: In function 'do_mmap_pgoff': > mm/mmap.c:953: error: 'MAP_HUGETLB' undeclared (first use in this function) mips breaks as well. I don't know how many other architectures broke. I disabled the patches. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 From: Randy Dunlap Subject: Re: [PATCH] Fix for hugetlb-add-map_hugetlb-for-mmaping-pseudo-anonymous-huge-page-regions.patch in -mm Date: Mon, 8 Feb 2010 14:56:05 -0800 Message-ID: <20100208145605.5eea30b5.randy.dunlap@oracle.com> References: <1252487811-9205-1-git-send-email-ebmunson@us.ibm.com> <1253011613-6429-1-git-send-email-ebmunson@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: owner-linux-mm@kvack.org To: Hugh Dickins Cc: Eric B Munson , akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-man@vger.kernel.org, mtk.manpages@gmail.com, Arnd Bergman List-Id: linux-man@vger.kernel.org On Tue, 15 Sep 2009 21:53:12 +0100 (BST) Hugh Dickins wrote: > On Tue, 15 Sep 2009, Eric B Munson wrote: > > Resending because this seems to have fallen between the cracks. > > Yes, indeed. I think it isn't quite what Arnd was suggesting, but I > agree with you that we might as well go for 0x080000 (so that even Alpha > can be just a cut-and-paste job from asm-generic), and right now it's > more important to finalize the number than what file it appears in. > > Acked-by: Hugh Dickins so what happened with this patch ?? > > > > The patch > > hugetlb-add-map_hugetlb-for-mmaping-pseudo-anonymous-huge-page-regions.patch > > used the value 0x40 for MAP_HUGETLB which is the same value used for > > various other flags on some architectures. This collision causes > > unexpected use of huge pages in the best case and mmap to fail with > > ENOMEM or ENOSYS in the worst. This patch changes the value for > > MAP_HUGETLB to a value that is not currently used on any arch. > > > > This patch should be considered a fix to > > hugetlb-add-map_hugetlb-for-mmaping-pseudo-anonymous-huge-page-regions.patch. > > > > Reported-by: Hugh Dickins > > Signed-off-by: Eric B Munson > > --- > > include/asm-generic/mman-common.h | 2 +- > > 1 files changed, 1 insertions(+), 1 deletions(-) > > > > diff --git a/include/asm-generic/mman-common.h b/include/asm-generic/mman-common.h > > index 12f5982..e6adb68 100644 > > --- a/include/asm-generic/mman-common.h > > +++ b/include/asm-generic/mman-common.h > > @@ -19,7 +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 MAP_HUGETLB 0x080000 /* create a huge page mapping */ > > > > #define MS_ASYNC 1 /* sync memory asynchronously */ > > #define MS_INVALIDATE 2 /* invalidate the caches */ > > -- --- ~Randy -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arnd Bergmann Subject: Re: [PATCH] Fix for hugetlb-add-map_hugetlb-for-mmaping-pseudo-anonymous-huge-page-regions.patch in -mm Date: Tue, 9 Feb 2010 16:01:27 +0100 Message-ID: <201002091601.28463.arnd@arndb.de> References: <1252487811-9205-1-git-send-email-ebmunson@us.ibm.com> <20100208145605.5eea30b5.randy.dunlap@oracle.com> Mime-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20100208145605.5eea30b5.randy.dunlap@oracle.com> Sender: owner-linux-mm@kvack.org To: Randy Dunlap Cc: Hugh Dickins , Eric B Munson , akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-man@vger.kernel.org, mtk.manpages@gmail.com List-Id: linux-man@vger.kernel.org On Monday 08 February 2010, Randy Dunlap wrote: > On Tue, 15 Sep 2009 21:53:12 +0100 (BST) Hugh Dickins wrote: > > > On Tue, 15 Sep 2009, Eric B Munson wrote: > > > Resending because this seems to have fallen between the cracks. > > > > Yes, indeed. I think it isn't quite what Arnd was suggesting, but I > > agree with you that we might as well go for 0x080000 (so that even Alpha > > can be just a cut-and-paste job from asm-generic), and right now it's > > more important to finalize the number than what file it appears in. > > > > Acked-by: Hugh Dickins > > so what happened with this patch ?? In a later revision, we agreed to put the definition into asm-generic/mman.h, where it was merged in 2.6.32. Arnd -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751977AbZH0OSd (ORCPT ); Thu, 27 Aug 2009 10:18:33 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751409AbZH0OSc (ORCPT ); Thu, 27 Aug 2009 10:18:32 -0400 Received: from gir.skynet.ie ([193.1.99.77]:40876 "EHLO gir.skynet.ie" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751248AbZH0OSb (ORCPT ); Thu, 27 Aug 2009 10:18:31 -0400 Date: Thu, 27 Aug 2009 15:18:34 +0100 From: Mel Gorman To: Eric B Munson Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, akpm@linux-foundation.org, linux-man@vger.kernel.org, mtk.manpages@gmail.com, randy.dunlap@oracle.com Subject: Re: [PATCH 1/3] hugetlbfs: Allow the creation of files suitable for MAP_PRIVATE on the vfs internal mount Message-ID: <20090827141834.GF21183@csn.ul.ie> References: <1c66a9e98a73d61c611e5cf09b276e954965046e.1251282769.git.ebmunson@us.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <1c66a9e98a73d61c611e5cf09b276e954965046e.1251282769.git.ebmunson@us.ibm.com> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Aug 26, 2009 at 11:44:51AM +0100, Eric B Munson wrote: > There are two means of creating mappings backed by huge pages: > > 1. mmap() a file created on hugetlbfs > 2. Use shm which creates a file on an internal mount which essentially > maps it MAP_SHARED > > The internal mount is only used for shared mappings but there is very > little that stops it being used for private mappings. This patch extends > hugetlbfs_file_setup() to deal with the creation of files that will be > mapped MAP_PRIVATE on the internal hugetlbfs mount. This extended API is > used in a subsequent patch to implement the MAP_HUGETLB mmap() flag. > Hi Eric, I ran these patches through a series of small tests and I have just one concern with the changes made to can_do_hugetlb_shm(). If that returns false because of MAP_HUGETLB, we then proceed to call user_shm_lock(). I think your intention might have been something like the following patch on top of yours? For what it's worth, once this was applied, I didn't spot any other problems, run-time or otherwise. ===== hugetlbfs: Do not call user_shm_lock() for MAP_HUGETLB The patch hugetlbfs-allow-the-creation-of-files-suitable-for-map_private-on-the-vfs-internal-mount.patch alters can_do_hugetlb_shm() to check if a file is being created for shared memory or mmap(). If this returns false, we then unconditionally call user_shm_lock() triggering a warning. This block should never be entered for MAP_HUGETLB. This patch partially reverts the problem and fixes the check. This patch should be considered a fix to hugetlbfs-allow-the-creation-of-files-suitable-for-map_private-on-the-vfs-internal-mount.patch. Signed-off-by: Mel Gorman --- fs/hugetlbfs/inode.c | 12 +++--------- 1 file changed, 3 insertions(+), 9 deletions(-) diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c index 49d2bf9..c944cc1 100644 --- a/fs/hugetlbfs/inode.c +++ b/fs/hugetlbfs/inode.c @@ -910,15 +910,9 @@ static struct file_system_type hugetlbfs_fs_type = { static struct vfsmount *hugetlbfs_vfsmount; -static int can_do_hugetlb_shm(int creat_flags) +static int can_do_hugetlb_shm(void) { - if (creat_flags != HUGETLB_SHMFS_INODE) - return 0; - if (capable(CAP_IPC_LOCK)) - return 1; - if (in_group_p(sysctl_hugetlb_shm_group)) - return 1; - return 0; + return capable(CAP_IPC_LOCK) || in_group_p(sysctl_hugetlb_shm_group); } struct file *hugetlb_file_setup(const char *name, size_t size, int acctflag, @@ -934,7 +928,7 @@ struct file *hugetlb_file_setup(const char *name, size_t size, int acctflag, if (!hugetlbfs_vfsmount) return ERR_PTR(-ENOENT); - if (!can_do_hugetlb_shm(creat_flags)) { + if (creat_flags == HUGETLB_SHMFS_INODE && !can_do_hugetlb_shm()) { *user = current_user(); if (user_shm_lock(size, *user)) { WARN_ONCE(1, From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754357AbZHaTuQ (ORCPT ); Mon, 31 Aug 2009 15:50:16 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752480AbZHaTuP (ORCPT ); Mon, 31 Aug 2009 15:50:15 -0400 Received: from mk-filter-2-a-1.mail.uk.tiscali.com ([212.74.100.53]:56212 "EHLO mk-filter-2-a-1.mail.uk.tiscali.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751510AbZHaTuO (ORCPT ); Mon, 31 Aug 2009 15:50:14 -0400 X-Trace: 255106400/mk-filter-2.mail.uk.tiscali.com/B2C/$b2c-THROTTLED-DYNAMIC/b2c-CUSTOMER-DYNAMIC-IP/79.69.118.155/None/hugh.dickins@tiscali.co.uk X-SBRS: None X-RemoteIP: 79.69.118.155 X-IP-MAIL-FROM: hugh.dickins@tiscali.co.uk X-SMTP-AUTH: X-MUA: X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAAvGm0pPRXab/2dsb2JhbACBU9gchBoFgVU X-IronPort-AV: E=Sophos;i="4.44,307,1249254000"; d="scan'208";a="255106400" Date: Mon, 31 Aug 2009 20:49:38 +0100 (BST) From: Hugh Dickins X-X-Sender: hugh@sister.anvils To: Eric B Munson cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, akpm@linux-foundation.org, linux-man@vger.kernel.org, mtk.manpages@gmail.com, randy.dunlap@oracle.com Subject: Re: [PATCH 2/3] Add MAP_HUGETLB for mmaping pseudo-anonymous huge page regions In-Reply-To: <1721a3e8bdf8f311d2388951ec65a24d37b513b1.1251282769.git.ebmunson@us.ibm.com> Message-ID: References: <1c66a9e98a73d61c611e5cf09b276e954965046e.1251282769.git.ebmunson@us.ibm.com> <1721a3e8bdf8f311d2388951ec65a24d37b513b1.1251282769.git.ebmunson@us.ibm.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 > --- > 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 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753796AbZIAKmR (ORCPT ); Tue, 1 Sep 2009 06:42:17 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753569AbZIAKmQ (ORCPT ); Tue, 1 Sep 2009 06:42:16 -0400 Received: from mk-filter-4-a-1.mail.uk.tiscali.com ([212.74.100.55]:19217 "EHLO mk-filter-4-a-1.mail.uk.tiscali.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753431AbZIAKmP (ORCPT ); Tue, 1 Sep 2009 06:42:15 -0400 X-Trace: 251799832/mk-filter-4.mail.uk.tiscali.com/B2C/$b2c-THROTTLED-DYNAMIC/b2c-CUSTOMER-DYNAMIC-IP/79.69.89.98/None/hugh.dickins@tiscali.co.uk X-SBRS: None X-RemoteIP: 79.69.89.98 X-IP-MAIL-FROM: hugh.dickins@tiscali.co.uk X-SMTP-AUTH: X-MUA: X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAKOWnEpPRVli/2dsb2JhbACBU9lYhBoFgVU X-IronPort-AV: E=Sophos;i="4.44,311,1249254000"; d="scan'208";a="251799832" Date: Tue, 1 Sep 2009 11:41:41 +0100 (BST) From: Hugh Dickins X-X-Sender: hugh@sister.anvils To: Eric B Munson cc: Mel Gorman , linux-kernel@vger.kernel.org, linux-mm@kvack.org, akpm@linux-foundation.org, linux-man@vger.kernel.org, mtk.manpages@gmail.com, randy.dunlap@oracle.com Subject: Re: [PATCH 2/3] Add MAP_HUGETLB for mmaping pseudo-anonymous huge page regions In-Reply-To: <20090901094635.GA7995@us.ibm.com> Message-ID: References: <1c66a9e98a73d61c611e5cf09b276e954965046e.1251282769.git.ebmunson@us.ibm.com> <1721a3e8bdf8f311d2388951ec65a24d37b513b1.1251282769.git.ebmunson@us.ibm.com> <20090901094635.GA7995@us.ibm.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 > > > --- > > > 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 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754781AbZIANer (ORCPT ); Tue, 1 Sep 2009 09:34:47 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754702AbZIANer (ORCPT ); Tue, 1 Sep 2009 09:34:47 -0400 Received: from mk-filter-2-a-1.mail.uk.tiscali.com ([212.74.100.53]:49609 "EHLO mk-filter-2-a-1.mail.uk.tiscali.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754531AbZIANeq (ORCPT ); Tue, 1 Sep 2009 09:34:46 -0400 X-Trace: 255454216/mk-filter-2.mail.uk.tiscali.com/B2C/$b2c-THROTTLED-DYNAMIC/b2c-CUSTOMER-DYNAMIC-IP/80.41.116.211/None/hugh.dickins@tiscali.co.uk X-SBRS: None X-RemoteIP: 80.41.116.211 X-IP-MAIL-FROM: hugh.dickins@tiscali.co.uk X-SMTP-AUTH: X-MUA: X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArcEAKe/nEpQKXTT/2dsb2JhbACBU9pyhBsF X-IronPort-AV: E=Sophos;i="4.44,312,1249254000"; d="scan'208";a="255454216" Date: Tue, 1 Sep 2009 14:34:09 +0100 (BST) From: Hugh Dickins X-X-Sender: hugh@sister.anvils To: Eric B Munson cc: Arnd Bergman , Mel Gorman , linux-kernel@vger.kernel.org, linux-mm@kvack.org, akpm@linux-foundation.org, linux-man@vger.kernel.org, Michael Kerrisk , randy.dunlap@oracle.com Subject: Re: [PATCH 2/3] Add MAP_HUGETLB for mmaping pseudo-anonymous huge page regions In-Reply-To: <20090901130801.GB7995@us.ibm.com> Message-ID: References: <1c66a9e98a73d61c611e5cf09b276e954965046e.1251282769.git.ebmunson@us.ibm.com> <1721a3e8bdf8f311d2388951ec65a24d37b513b1.1251282769.git.ebmunson@us.ibm.com> <20090901094635.GA7995@us.ibm.com> <20090901130801.GB7995@us.ibm.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 1 Sep 2009, Eric B Munson wrote: > On Tue, 01 Sep 2009, Hugh Dickins wrote: > > > > 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. > > Would it be okay to keep the define in include/asm-generic/mman.h > if a value that is known free across all architectures is used? > 0x080000 is not used by any arch and, AFAICT would work just as well. That's a very sensible suggestion, but departs from how we have assigned new numbers up until now: so include/asm-generic/mman-common.h isn't actually where we'd expect to find a Linux-specific MAP_ define. I'd say, yes, do that for now, so as not to hit this conflict while testing in mmotm. But whether it should stay that way, or later the arch/*/include/asm/mman.h's be updated as I'd imagined, I don't know. Arnd, Michael, do you have any views on this? Thanks, Hugh From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754943AbZIBIeu (ORCPT ); Wed, 2 Sep 2009 04:34:50 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753119AbZIBIeu (ORCPT ); Wed, 2 Sep 2009 04:34:50 -0400 Received: from moutng.kundenserver.de ([212.227.126.186]:52490 "EHLO moutng.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752864AbZIBIet (ORCPT ); Wed, 2 Sep 2009 04:34:49 -0400 From: Arnd Bergmann To: Hugh Dickins Subject: Re: [PATCH 2/3] Add MAP_HUGETLB for mmaping pseudo-anonymous huge page regions Date: Wed, 2 Sep 2009 10:34:40 +0200 User-Agent: KMail/1.12.0 (Linux/2.6.31-6-generic; KDE/4.3.0; x86_64; ; ) Cc: Eric B Munson , Mel Gorman , linux-kernel@vger.kernel.org, linux-mm@kvack.org, akpm@linux-foundation.org, linux-man@vger.kernel.org, Michael Kerrisk , randy.dunlap@oracle.com References: <20090901130801.GB7995@us.ibm.com> In-Reply-To: X-Face: I@=L^?./?$U,EK.)V[4*>`zSqm0>65YtkOe>TFD'!aw?7OVv#~5xd\s,[~w]-J!)|%=]> =?utf-8?q?+=0A=09=7EohchhkRGW=3F=7C6=5FqTmkd=5Ft=3FLZC=23Q-=60=2E=60Y=2Ea=5E?= =?utf-8?q?3zb?=) =?utf-8?q?+U-JVN=5DWT=25cw=23=5BYo0=267C=26bL12wWGlZi=0A=09=7EJ=3B=5Cwg?= =?utf-8?q?=3B3zRnz?=,J"CT_)=\H'1/{?SR7GDu?WIopm.HaBG=QYj"NZD_[zrM\Gip^U MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200909021034.40827.arnd@arndb.de> X-Provags-ID: V01U2FsdGVkX19blNigrqrns4iVO+skcwvsf/GDyHvlYG9fekc DqIDUCi9foCH70ijm4GgMv+YtG8/uvP0SzIlM0hNVOCvH6bpue r52OqM2POel8UFOk1aNXw== Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tuesday 01 September 2009, Hugh Dickins wrote: > On Tue, 1 Sep 2009, Eric B Munson wrote: > > On Tue, 01 Sep 2009, Hugh Dickins wrote: > > > > > > 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. > > > > Would it be okay to keep the define in include/asm-generic/mman.h > > if a value that is known free across all architectures is used? > > 0x080000 is not used by any arch and, AFAICT would work just as well. > > That's a very sensible suggestion, but departs from how we have > assigned new numbers up until now: so include/asm-generic/mman-common.h > isn't actually where we'd expect to find a Linux-specific MAP_ define. > > I'd say, yes, do that for now, so as not to hit this conflict while > testing in mmotm. But whether it should stay that way, or later the > arch/*/include/asm/mman.h's be updated as I'd imagined, I don't know. > > Arnd, Michael, do you have any views on this? The minimal procedure would be to add it to mman-common.h, plus the asm/mman.h files for xtensa, mips, parisc and alpha, which all use a version that is compatible to a Unix variant, but that would be confusing the next person that needs to add a flag. I'd use the number 0x40000 for all architectures except alpha, because that makes the most sense for asm-generic/mman.h. Alpha is weird anyway here, so we don't need to avoid conflicts with it. With a few exceptions (sparc, powerpc), I think we should change all architectures to use asm-generic/mman.h instead of mman-common.h in the long run. If you touch those anyway, one option would be to do it in one step. Arnd <>< From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758646AbZIOUyA (ORCPT ); Tue, 15 Sep 2009 16:54:00 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1758531AbZIOUx5 (ORCPT ); Tue, 15 Sep 2009 16:53:57 -0400 Received: from mk-filter-3-a-1.mail.uk.tiscali.com ([212.74.100.54]:48965 "EHLO mk-filter-3-a-1.mail.uk.tiscali.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758517AbZIOUx4 (ORCPT ); Tue, 15 Sep 2009 16:53:56 -0400 X-Trace: 259131786/mk-filter-3.mail.uk.tiscali.com/B2C/$b2c-THROTTLED-DYNAMIC/b2c-CUSTOMER-DYNAMIC-IP/79.69.84.74/None/hugh.dickins@tiscali.co.uk X-SBRS: None X-RemoteIP: 79.69.84.74 X-IP-MAIL-FROM: hugh.dickins@tiscali.co.uk X-SMTP-AUTH: X-MUA: X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlgFAFqbr0pPRVRK/2dsb2JhbACBU95khBcF X-IronPort-AV: E=Sophos;i="4.44,391,1249254000"; d="scan'208";a="259131786" Date: Tue, 15 Sep 2009 21:53:12 +0100 (BST) From: Hugh Dickins X-X-Sender: hugh@sister.anvils To: Eric B Munson cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-man@vger.kernel.org, mtk.manpages@gmail.com, randy.dunlap@oracle.com, Arnd Bergman Subject: Re: [PATCH] Fix for hugetlb-add-map_hugetlb-for-mmaping-pseudo-anonymous-huge-page-regions.patch in -mm In-Reply-To: <1253011613-6429-1-git-send-email-ebmunson@us.ibm.com> Message-ID: References: <1252487811-9205-1-git-send-email-ebmunson@us.ibm.com> <1253011613-6429-1-git-send-email-ebmunson@us.ibm.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 15 Sep 2009, Eric B Munson wrote: > Resending because this seems to have fallen between the cracks. Yes, indeed. I think it isn't quite what Arnd was suggesting, but I agree with you that we might as well go for 0x080000 (so that even Alpha can be just a cut-and-paste job from asm-generic), and right now it's more important to finalize the number than what file it appears in. Acked-by: Hugh Dickins > > The patch > hugetlb-add-map_hugetlb-for-mmaping-pseudo-anonymous-huge-page-regions.patch > used the value 0x40 for MAP_HUGETLB which is the same value used for > various other flags on some architectures. This collision causes > unexpected use of huge pages in the best case and mmap to fail with > ENOMEM or ENOSYS in the worst. This patch changes the value for > MAP_HUGETLB to a value that is not currently used on any arch. > > This patch should be considered a fix to > hugetlb-add-map_hugetlb-for-mmaping-pseudo-anonymous-huge-page-regions.patch. > > Reported-by: Hugh Dickins > Signed-off-by: Eric B Munson > --- > include/asm-generic/mman-common.h | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/include/asm-generic/mman-common.h b/include/asm-generic/mman-common.h > index 12f5982..e6adb68 100644 > --- a/include/asm-generic/mman-common.h > +++ b/include/asm-generic/mman-common.h > @@ -19,7 +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 MAP_HUGETLB 0x080000 /* create a huge page mapping */ > > #define MS_ASYNC 1 /* sync memory asynchronously */ > #define MS_INVALIDATE 2 /* invalidate the caches */ > -- > 1.6.3.2 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753532AbZIQWot (ORCPT ); Thu, 17 Sep 2009 18:44:49 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753398AbZIQWor (ORCPT ); Thu, 17 Sep 2009 18:44:47 -0400 Received: from smtp1.linux-foundation.org ([140.211.169.13]:52143 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753361AbZIQWol (ORCPT ); Thu, 17 Sep 2009 18:44:41 -0400 Date: Thu, 17 Sep 2009 15:44:04 -0700 From: Andrew Morton To: Eric B Munson Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-man@vger.kernel.org, mtk.manpages@gmail.com, randy.dunlap@oracle.com, ebmunson@us.ibm.com, Richard Henderson , Ivan Kokshaysky Subject: Re: [PATCH 2/3] Add MAP_HUGETLB for mmaping pseudo-anonymous huge page regions Message-Id: <20090917154404.e1d3694e.akpm@linux-foundation.org> In-Reply-To: <8504342f7be19e416ef769d1edd24b8549f8dc39.1251197514.git.ebmunson@us.ibm.com> References: <25614b0d0581e2d49e1024dc1671b282f193e139.1251197514.git.ebmunson@us.ibm.com> <8504342f7be19e416ef769d1edd24b8549f8dc39.1251197514.git.ebmunson@us.ibm.com> X-Mailer: Sylpheed version 2.2.4 (GTK+ 2.8.20; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 25 Aug 2009 12:14:53 +0100 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 > --- > include/asm-generic/mman-common.h | 1 + > include/linux/hugetlb.h | 7 +++++++ > mm/mmap.c | 19 +++++++++++++++++++ alpha fix: From: Andrew Morton mm/mmap.c: In function 'do_mmap_pgoff': mm/mmap.c:953: error: 'MAP_HUGETLB' undeclared (first use in this function) mm/mmap.c:953: error: (Each undeclared identifier is reported only once mm/mmap.c:953: error: for each function it appears in.) Cc: Adam Litke Cc: David Gibson Cc: David Rientjes Cc: Eric B Munson Cc: Hugh Dickins Cc: Lee Schermerhorn Cc: Mel Gorman Cc: Nick Piggin Cc: Ivan Kokshaysky Cc: Richard Henderson Signed-off-by: Andrew Morton --- arch/alpha/include/asm/mman.h | 1 + 1 file changed, 1 insertion(+) diff -puN arch/alpha/include/asm/mman.h~hugetlb-add-map_hugetlb-for-mmaping-pseudo-anonymous-huge-page-regions-alpha-fix arch/alpha/include/asm/mman.h --- a/arch/alpha/include/asm/mman.h~hugetlb-add-map_hugetlb-for-mmaping-pseudo-anonymous-huge-page-regions-alpha-fix +++ a/arch/alpha/include/asm/mman.h @@ -28,6 +28,7 @@ #define MAP_NORESERVE 0x10000 /* don't check for reservations */ #define MAP_POPULATE 0x20000 /* populate (prefault) pagetables */ #define MAP_NONBLOCK 0x40000 /* do not block on IO */ +#define MAP_HUGETLB 0x80000 /* create a huge page mapping */ #define MS_ASYNC 1 /* sync memory asynchronously */ #define MS_SYNC 2 /* synchronous memory sync */ _ From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753445AbZIRAq1 (ORCPT ); Thu, 17 Sep 2009 20:46:27 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752633AbZIRAq0 (ORCPT ); Thu, 17 Sep 2009 20:46:26 -0400 Received: from smtp1.linux-foundation.org ([140.211.169.13]:41114 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752521AbZIRAq0 (ORCPT ); Thu, 17 Sep 2009 20:46:26 -0400 Date: Thu, 17 Sep 2009 17:46:16 -0700 From: Andrew Morton To: ebmunson@us.ibm.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-man@vger.kernel.org, mtk.manpages@gmail.com, randy.dunlap@oracle.com, rth@twiddle.net, ink@jurassic.park.msu.ru Subject: Re: [PATCH 2/3] Add MAP_HUGETLB for mmaping pseudo-anonymous huge page regions Message-Id: <20090917174616.f64123fb.akpm@linux-foundation.org> In-Reply-To: <20090917154404.e1d3694e.akpm@linux-foundation.org> References: <25614b0d0581e2d49e1024dc1671b282f193e139.1251197514.git.ebmunson@us.ibm.com> <8504342f7be19e416ef769d1edd24b8549f8dc39.1251197514.git.ebmunson@us.ibm.com> <20090917154404.e1d3694e.akpm@linux-foundation.org> X-Mailer: Sylpheed version 2.2.4 (GTK+ 2.8.20; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 17 Sep 2009 15:44:04 -0700 Andrew Morton wrote: > mm/mmap.c: In function 'do_mmap_pgoff': > mm/mmap.c:953: error: 'MAP_HUGETLB' undeclared (first use in this function) mips breaks as well. I don't know how many other architectures broke. I disabled the patches. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752954Ab0BHW4l (ORCPT ); Mon, 8 Feb 2010 17:56:41 -0500 Received: from rcsinet11.oracle.com ([148.87.113.123]:47006 "EHLO rcsinet11.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752395Ab0BHW4k (ORCPT ); Mon, 8 Feb 2010 17:56:40 -0500 Date: Mon, 8 Feb 2010 14:56:05 -0800 From: Randy Dunlap To: Hugh Dickins Cc: Eric B Munson , akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-man@vger.kernel.org, mtk.manpages@gmail.com, Arnd Bergman Subject: Re: [PATCH] Fix for hugetlb-add-map_hugetlb-for-mmaping-pseudo-anonymous-huge-page-regions.patch in -mm Message-Id: <20100208145605.5eea30b5.randy.dunlap@oracle.com> In-Reply-To: References: <1252487811-9205-1-git-send-email-ebmunson@us.ibm.com> <1253011613-6429-1-git-send-email-ebmunson@us.ibm.com> Organization: Oracle Linux Eng. X-Mailer: Sylpheed 2.6.0 (GTK+ 2.16.6; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4B709697.0238:SCFMA4539814,ss=1,fgs=0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 15 Sep 2009 21:53:12 +0100 (BST) Hugh Dickins wrote: > On Tue, 15 Sep 2009, Eric B Munson wrote: > > Resending because this seems to have fallen between the cracks. > > Yes, indeed. I think it isn't quite what Arnd was suggesting, but I > agree with you that we might as well go for 0x080000 (so that even Alpha > can be just a cut-and-paste job from asm-generic), and right now it's > more important to finalize the number than what file it appears in. > > Acked-by: Hugh Dickins so what happened with this patch ?? > > > > The patch > > hugetlb-add-map_hugetlb-for-mmaping-pseudo-anonymous-huge-page-regions.patch > > used the value 0x40 for MAP_HUGETLB which is the same value used for > > various other flags on some architectures. This collision causes > > unexpected use of huge pages in the best case and mmap to fail with > > ENOMEM or ENOSYS in the worst. This patch changes the value for > > MAP_HUGETLB to a value that is not currently used on any arch. > > > > This patch should be considered a fix to > > hugetlb-add-map_hugetlb-for-mmaping-pseudo-anonymous-huge-page-regions.patch. > > > > Reported-by: Hugh Dickins > > Signed-off-by: Eric B Munson > > --- > > include/asm-generic/mman-common.h | 2 +- > > 1 files changed, 1 insertions(+), 1 deletions(-) > > > > diff --git a/include/asm-generic/mman-common.h b/include/asm-generic/mman-common.h > > index 12f5982..e6adb68 100644 > > --- a/include/asm-generic/mman-common.h > > +++ b/include/asm-generic/mman-common.h > > @@ -19,7 +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 MAP_HUGETLB 0x080000 /* create a huge page mapping */ > > > > #define MS_ASYNC 1 /* sync memory asynchronously */ > > #define MS_INVALIDATE 2 /* invalidate the caches */ > > -- --- ~Randy From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754591Ab0BIPC1 (ORCPT ); Tue, 9 Feb 2010 10:02:27 -0500 Received: from moutng.kundenserver.de ([212.227.17.8]:58194 "EHLO moutng.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754515Ab0BIPCY (ORCPT ); Tue, 9 Feb 2010 10:02:24 -0500 From: Arnd Bergmann To: Randy Dunlap Subject: Re: [PATCH] Fix for hugetlb-add-map_hugetlb-for-mmaping-pseudo-anonymous-huge-page-regions.patch in -mm Date: Tue, 9 Feb 2010 16:01:27 +0100 User-Agent: KMail/1.12.2 (Linux/2.6.31-14-generic; KDE/4.3.2; x86_64; ; ) Cc: Hugh Dickins , Eric B Munson , akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-man@vger.kernel.org, mtk.manpages@gmail.com References: <1252487811-9205-1-git-send-email-ebmunson@us.ibm.com> <20100208145605.5eea30b5.randy.dunlap@oracle.com> In-Reply-To: <20100208145605.5eea30b5.randy.dunlap@oracle.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201002091601.28463.arnd@arndb.de> X-Provags-ID: V01U2FsdGVkX1/p0EsINOjgemqeGA+vWEcrx8r3LE4PLzH7g0u sh6/ygI2dQN9YcOwYZ6Ep/wF/URLwbu3M0Y8IBb9I5vXVSxGP3 RcjnFPbFuhxjgyWOCjuKQ== Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Monday 08 February 2010, Randy Dunlap wrote: > On Tue, 15 Sep 2009 21:53:12 +0100 (BST) Hugh Dickins wrote: > > > On Tue, 15 Sep 2009, Eric B Munson wrote: > > > Resending because this seems to have fallen between the cracks. > > > > Yes, indeed. I think it isn't quite what Arnd was suggesting, but I > > agree with you that we might as well go for 0x080000 (so that even Alpha > > can be just a cut-and-paste job from asm-generic), and right now it's > > more important to finalize the number than what file it appears in. > > > > Acked-by: Hugh Dickins > > so what happened with this patch ?? In a later revision, we agreed to put the definition into asm-generic/mman.h, where it was merged in 2.6.32. Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail172.messagelabs.com (mail172.messagelabs.com [216.82.254.3]) by kanga.kvack.org (Postfix) with ESMTP id 795D76B004F for ; Thu, 27 Aug 2009 10:18:33 -0400 (EDT) Date: Thu, 27 Aug 2009 15:18:34 +0100 From: Mel Gorman Subject: Re: [PATCH 1/3] hugetlbfs: Allow the creation of files suitable for MAP_PRIVATE on the vfs internal mount Message-ID: <20090827141834.GF21183@csn.ul.ie> References: <1c66a9e98a73d61c611e5cf09b276e954965046e.1251282769.git.ebmunson@us.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <1c66a9e98a73d61c611e5cf09b276e954965046e.1251282769.git.ebmunson@us.ibm.com> Sender: owner-linux-mm@kvack.org To: Eric B Munson Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, akpm@linux-foundation.org, linux-man@vger.kernel.org, mtk.manpages@gmail.com, randy.dunlap@oracle.com List-ID: On Wed, Aug 26, 2009 at 11:44:51AM +0100, Eric B Munson wrote: > There are two means of creating mappings backed by huge pages: > > 1. mmap() a file created on hugetlbfs > 2. Use shm which creates a file on an internal mount which essentially > maps it MAP_SHARED > > The internal mount is only used for shared mappings but there is very > little that stops it being used for private mappings. This patch extends > hugetlbfs_file_setup() to deal with the creation of files that will be > mapped MAP_PRIVATE on the internal hugetlbfs mount. This extended API is > used in a subsequent patch to implement the MAP_HUGETLB mmap() flag. > Hi Eric, I ran these patches through a series of small tests and I have just one concern with the changes made to can_do_hugetlb_shm(). If that returns false because of MAP_HUGETLB, we then proceed to call user_shm_lock(). I think your intention might have been something like the following patch on top of yours? For what it's worth, once this was applied, I didn't spot any other problems, run-time or otherwise. ===== hugetlbfs: Do not call user_shm_lock() for MAP_HUGETLB The patch hugetlbfs-allow-the-creation-of-files-suitable-for-map_private-on-the-vfs-internal-mount.patch alters can_do_hugetlb_shm() to check if a file is being created for shared memory or mmap(). If this returns false, we then unconditionally call user_shm_lock() triggering a warning. This block should never be entered for MAP_HUGETLB. This patch partially reverts the problem and fixes the check. This patch should be considered a fix to hugetlbfs-allow-the-creation-of-files-suitable-for-map_private-on-the-vfs-internal-mount.patch. Signed-off-by: Mel Gorman --- fs/hugetlbfs/inode.c | 12 +++--------- 1 file changed, 3 insertions(+), 9 deletions(-) diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c index 49d2bf9..c944cc1 100644 --- a/fs/hugetlbfs/inode.c +++ b/fs/hugetlbfs/inode.c @@ -910,15 +910,9 @@ static struct file_system_type hugetlbfs_fs_type = { static struct vfsmount *hugetlbfs_vfsmount; -static int can_do_hugetlb_shm(int creat_flags) +static int can_do_hugetlb_shm(void) { - if (creat_flags != HUGETLB_SHMFS_INODE) - return 0; - if (capable(CAP_IPC_LOCK)) - return 1; - if (in_group_p(sysctl_hugetlb_shm_group)) - return 1; - return 0; + return capable(CAP_IPC_LOCK) || in_group_p(sysctl_hugetlb_shm_group); } struct file *hugetlb_file_setup(const char *name, size_t size, int acctflag, @@ -934,7 +928,7 @@ struct file *hugetlb_file_setup(const char *name, size_t size, int acctflag, if (!hugetlbfs_vfsmount) return ERR_PTR(-ENOENT); - if (!can_do_hugetlb_shm(creat_flags)) { + if (creat_flags == HUGETLB_SHMFS_INODE && !can_do_hugetlb_shm()) { *user = current_user(); if (user_shm_lock(size, *user)) { WARN_ONCE(1, -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail191.messagelabs.com (mail191.messagelabs.com [216.82.242.19]) by kanga.kvack.org (Postfix) with SMTP id DDC126B004D for ; Tue, 1 Sep 2009 06:42:13 -0400 (EDT) Date: Tue, 1 Sep 2009 11:41:41 +0100 (BST) From: Hugh Dickins Subject: Re: [PATCH 2/3] Add MAP_HUGETLB for mmaping pseudo-anonymous huge page regions In-Reply-To: <20090901094635.GA7995@us.ibm.com> Message-ID: References: <1c66a9e98a73d61c611e5cf09b276e954965046e.1251282769.git.ebmunson@us.ibm.com> <1721a3e8bdf8f311d2388951ec65a24d37b513b1.1251282769.git.ebmunson@us.ibm.com> <20090901094635.GA7995@us.ibm.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org To: Eric B Munson Cc: Mel Gorman , linux-kernel@vger.kernel.org, linux-mm@kvack.org, akpm@linux-foundation.org, linux-man@vger.kernel.org, mtk.manpages@gmail.com, randy.dunlap@oracle.com List-ID: 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 > > > --- > > > 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 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 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail144.messagelabs.com (mail144.messagelabs.com [216.82.254.51]) by kanga.kvack.org (Postfix) with SMTP id D197B6B004F for ; Tue, 1 Sep 2009 09:34:46 -0400 (EDT) Date: Tue, 1 Sep 2009 14:34:09 +0100 (BST) From: Hugh Dickins Subject: Re: [PATCH 2/3] Add MAP_HUGETLB for mmaping pseudo-anonymous huge page regions In-Reply-To: <20090901130801.GB7995@us.ibm.com> Message-ID: References: <1c66a9e98a73d61c611e5cf09b276e954965046e.1251282769.git.ebmunson@us.ibm.com> <1721a3e8bdf8f311d2388951ec65a24d37b513b1.1251282769.git.ebmunson@us.ibm.com> <20090901094635.GA7995@us.ibm.com> <20090901130801.GB7995@us.ibm.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org To: Eric B Munson Cc: Arnd Bergman , Mel Gorman , linux-kernel@vger.kernel.org, linux-mm@kvack.org, akpm@linux-foundation.org, linux-man@vger.kernel.org, Michael Kerrisk , randy.dunlap@oracle.com List-ID: On Tue, 1 Sep 2009, Eric B Munson wrote: > On Tue, 01 Sep 2009, Hugh Dickins wrote: > > > > 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. > > Would it be okay to keep the define in include/asm-generic/mman.h > if a value that is known free across all architectures is used? > 0x080000 is not used by any arch and, AFAICT would work just as well. That's a very sensible suggestion, but departs from how we have assigned new numbers up until now: so include/asm-generic/mman-common.h isn't actually where we'd expect to find a Linux-specific MAP_ define. I'd say, yes, do that for now, so as not to hit this conflict while testing in mmotm. But whether it should stay that way, or later the arch/*/include/asm/mman.h's be updated as I'd imagined, I don't know. Arnd, Michael, do you have any views on this? Thanks, Hugh -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail143.messagelabs.com (mail143.messagelabs.com [216.82.254.35]) by kanga.kvack.org (Postfix) with SMTP id BD1A26B005A for ; Wed, 2 Sep 2009 04:34:56 -0400 (EDT) From: Arnd Bergmann Subject: Re: [PATCH 2/3] Add MAP_HUGETLB for mmaping pseudo-anonymous huge page regions Date: Wed, 2 Sep 2009 10:34:40 +0200 References: <20090901130801.GB7995@us.ibm.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200909021034.40827.arnd@arndb.de> Sender: owner-linux-mm@kvack.org To: Hugh Dickins Cc: Eric B Munson , Mel Gorman , linux-kernel@vger.kernel.org, linux-mm@kvack.org, akpm@linux-foundation.org, linux-man@vger.kernel.org, Michael Kerrisk , randy.dunlap@oracle.com List-ID: On Tuesday 01 September 2009, Hugh Dickins wrote: > On Tue, 1 Sep 2009, Eric B Munson wrote: > > On Tue, 01 Sep 2009, Hugh Dickins wrote: > > > > > > 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. > > > > Would it be okay to keep the define in include/asm-generic/mman.h > > if a value that is known free across all architectures is used? > > 0x080000 is not used by any arch and, AFAICT would work just as well. > > That's a very sensible suggestion, but departs from how we have > assigned new numbers up until now: so include/asm-generic/mman-common.h > isn't actually where we'd expect to find a Linux-specific MAP_ define. > > I'd say, yes, do that for now, so as not to hit this conflict while > testing in mmotm. But whether it should stay that way, or later the > arch/*/include/asm/mman.h's be updated as I'd imagined, I don't know. > > Arnd, Michael, do you have any views on this? The minimal procedure would be to add it to mman-common.h, plus the asm/mman.h files for xtensa, mips, parisc and alpha, which all use a version that is compatible to a Unix variant, but that would be confusing the next person that needs to add a flag. I'd use the number 0x40000 for all architectures except alpha, because that makes the most sense for asm-generic/mman.h. Alpha is weird anyway here, so we don't need to avoid conflicts with it. With a few exceptions (sparc, powerpc), I think we should change all architectures to use asm-generic/mman.h instead of mman-common.h in the long run. If you touch those anyway, one option would be to do it in one step. Arnd <>< -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail138.messagelabs.com (mail138.messagelabs.com [216.82.249.35]) by kanga.kvack.org (Postfix) with ESMTP id 153A46B008A for ; Thu, 17 Sep 2009 18:44:36 -0400 (EDT) Date: Thu, 17 Sep 2009 15:44:04 -0700 From: Andrew Morton Subject: Re: [PATCH 2/3] Add MAP_HUGETLB for mmaping pseudo-anonymous huge page regions Message-Id: <20090917154404.e1d3694e.akpm@linux-foundation.org> In-Reply-To: <8504342f7be19e416ef769d1edd24b8549f8dc39.1251197514.git.ebmunson@us.ibm.com> References: <25614b0d0581e2d49e1024dc1671b282f193e139.1251197514.git.ebmunson@us.ibm.com> <8504342f7be19e416ef769d1edd24b8549f8dc39.1251197514.git.ebmunson@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org To: Eric B Munson Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-man@vger.kernel.org, mtk.manpages@gmail.com, randy.dunlap@oracle.com, Richard Henderson , Ivan Kokshaysky List-ID: On Tue, 25 Aug 2009 12:14:53 +0100 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 > --- > include/asm-generic/mman-common.h | 1 + > include/linux/hugetlb.h | 7 +++++++ > mm/mmap.c | 19 +++++++++++++++++++ alpha fix: From: Andrew Morton mm/mmap.c: In function 'do_mmap_pgoff': mm/mmap.c:953: error: 'MAP_HUGETLB' undeclared (first use in this function) mm/mmap.c:953: error: (Each undeclared identifier is reported only once mm/mmap.c:953: error: for each function it appears in.) Cc: Adam Litke Cc: David Gibson Cc: David Rientjes Cc: Eric B Munson Cc: Hugh Dickins Cc: Lee Schermerhorn Cc: Mel Gorman Cc: Nick Piggin Cc: Ivan Kokshaysky Cc: Richard Henderson Signed-off-by: Andrew Morton --- arch/alpha/include/asm/mman.h | 1 + 1 file changed, 1 insertion(+) diff -puN arch/alpha/include/asm/mman.h~hugetlb-add-map_hugetlb-for-mmaping-pseudo-anonymous-huge-page-regions-alpha-fix arch/alpha/include/asm/mman.h --- a/arch/alpha/include/asm/mman.h~hugetlb-add-map_hugetlb-for-mmaping-pseudo-anonymous-huge-page-regions-alpha-fix +++ a/arch/alpha/include/asm/mman.h @@ -28,6 +28,7 @@ #define MAP_NORESERVE 0x10000 /* don't check for reservations */ #define MAP_POPULATE 0x20000 /* populate (prefault) pagetables */ #define MAP_NONBLOCK 0x40000 /* do not block on IO */ +#define MAP_HUGETLB 0x80000 /* create a huge page mapping */ #define MS_ASYNC 1 /* sync memory asynchronously */ #define MS_SYNC 2 /* synchronous memory sync */ _ -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail202.messagelabs.com (mail202.messagelabs.com [216.82.254.227]) by kanga.kvack.org (Postfix) with ESMTP id 1E1FF6B005D for ; Thu, 17 Sep 2009 20:46:19 -0400 (EDT) Date: Thu, 17 Sep 2009 17:46:16 -0700 From: Andrew Morton Subject: Re: [PATCH 2/3] Add MAP_HUGETLB for mmaping pseudo-anonymous huge page regions Message-Id: <20090917174616.f64123fb.akpm@linux-foundation.org> In-Reply-To: <20090917154404.e1d3694e.akpm@linux-foundation.org> References: <25614b0d0581e2d49e1024dc1671b282f193e139.1251197514.git.ebmunson@us.ibm.com> <8504342f7be19e416ef769d1edd24b8549f8dc39.1251197514.git.ebmunson@us.ibm.com> <20090917154404.e1d3694e.akpm@linux-foundation.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org To: ebmunson@us.ibm.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-man@vger.kernel.org, mtk.manpages@gmail.com, randy.dunlap@oracle.com, rth@twiddle.net, ink@jurassic.park.msu.ru List-ID: On Thu, 17 Sep 2009 15:44:04 -0700 Andrew Morton wrote: > mm/mmap.c: In function 'do_mmap_pgoff': > mm/mmap.c:953: error: 'MAP_HUGETLB' undeclared (first use in this function) mips breaks as well. I don't know how many other architectures broke. I disabled the patches. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org