From: Yufen Yu <yuyufen@huawei.com>
To: <mike.kravetz@oracle.com>, <linux-mm@kvack.org>
Subject: [PATCH v2] hugetlbfs: fix memory leak for resv_map
Date: Wed, 6 Mar 2019 14:10:07 +0800 [thread overview]
Message-ID: <20190306061007.61645-1-yuyufen@huawei.com> (raw)
When .mknod create a block device file in hugetlbfs, it will
allocate an inode, and kmalloc a 'struct resv_map' in resv_map_alloc().
For now, inode->i_mapping->private_data is used to point the resv_map.
However, when open the device, bd_acquire() will set i_mapping as
bd_inode->imapping, result in resv_map memory leak.
We fix it by waiting until a call to hugetlb_reserve_pages() to allocate
the inode specific resv_map. We could then remove the resv_map allocation
at inode creation time.
Programs to reproduce:
mount -t hugetlbfs nodev hugetlbfs
mknod hugetlbfs/dev b 0 0
exec 30<> hugetlbfs/dev
umount hugetlbfs/
Signed-off-by: Yufen Yu <yuyufen@huawei.com>
---
fs/hugetlbfs/inode.c | 10 ++--------
mm/hugetlb.c | 6 ++++++
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
index a7fa037b876b..eb87cfb80eb9 100644
--- a/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@ -741,11 +741,6 @@ static struct inode *hugetlbfs_get_inode(struct super_block *sb,
umode_t mode, dev_t dev)
{
struct inode *inode;
- struct resv_map *resv_map;
-
- resv_map = resv_map_alloc();
- if (!resv_map)
- return NULL;
inode = new_inode(sb);
if (inode) {
@@ -757,7 +752,7 @@ static struct inode *hugetlbfs_get_inode(struct super_block *sb,
&hugetlbfs_i_mmap_rwsem_key);
inode->i_mapping->a_ops = &hugetlbfs_aops;
inode->i_atime = inode->i_mtime = inode->i_ctime = current_time(inode);
- inode->i_mapping->private_data = resv_map;
+ inode->i_mapping->private_data = NULL;
info->seals = F_SEAL_SEAL;
switch (mode & S_IFMT) {
default:
@@ -780,8 +775,7 @@ static struct inode *hugetlbfs_get_inode(struct super_block *sb,
break;
}
lockdep_annotate_inode_mutex_key(inode);
- } else
- kref_put(&resv_map->refs, resv_map_release);
+ }
return inode;
}
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 8dfdffc34a99..088fd1239d49 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -4462,6 +4462,12 @@ int hugetlb_reserve_pages(struct inode *inode,
*/
if (!vma || vma->vm_flags & VM_MAYSHARE) {
resv_map = inode_resv_map(inode);
+ if (!resv_map) {
+ resv_map = resv_map_alloc();
+ if (!resv_map)
+ return -ENOMEM;
+ inode->i_mapping->private_data = resv_map;
+ }
chg = region_chg(resv_map, from, to);
--
2.16.2.dirty
next reply other threads:[~2019-03-06 6:06 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-06 6:10 Yufen Yu [this message]
2019-03-06 23:52 ` Mike Kravetz
2019-03-07 23:50 ` Mike Kravetz
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=20190306061007.61645-1-yuyufen@huawei.com \
--to=yuyufen@huawei.com \
--cc=linux-mm@kvack.org \
--cc=mike.kravetz@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