From: Mel Gorman <mel@csn.ul.ie>
To: Eric B Munson <ebmunson@us.ibm.com>
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
Date: Thu, 27 Aug 2009 15:18:34 +0100 [thread overview]
Message-ID: <20090827141834.GF21183@csn.ul.ie> (raw)
In-Reply-To: <1c66a9e98a73d61c611e5cf09b276e954965046e.1251282769.git.ebmunson@us.ibm.com>
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 <mel@csn.ul.ie>
---
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,
next parent reply other threads:[~2009-08-27 14:18 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <cover.1251282769.git.ebmunson@us.ibm.com>
[not found] ` <1c66a9e98a73d61c611e5cf09b276e954965046e.1251282769.git.ebmunson@us.ibm.com>
2009-08-27 14:18 ` Mel Gorman [this message]
[not found] ` <1721a3e8bdf8f311d2388951ec65a24d37b513b1.1251282769.git.ebmunson@us.ibm.com>
2009-08-31 19:49 ` [PATCH 2/3] Add MAP_HUGETLB for mmaping pseudo-anonymous huge page regions Hugh Dickins
[not found] ` <20090901094635.GA7995@us.ibm.com>
2009-09-01 10:41 ` Hugh Dickins
[not found] ` <20090901130801.GB7995@us.ibm.com>
2009-09-01 13:34 ` Hugh Dickins
2009-09-02 8:34 ` Arnd Bergmann
[not found] <cover.1251197514.git.ebmunson@us.ibm.com>
[not found] ` <25614b0d0581e2d49e1024dc1671b282f193e139.1251197514.git.ebmunson@us.ibm.com>
2009-08-26 19:34 ` [PATCH 1/3] hugetlbfs: Allow the creation of files suitable for MAP_PRIVATE on the vfs internal mount David Rientjes
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090827141834.GF21183@csn.ul.ie \
--to=mel@csn.ul.ie \
--cc=akpm@linux-foundation.org \
--cc=ebmunson@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-man@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mtk.manpages@gmail.com \
--cc=randy.dunlap@oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox