Re: [PATCH v2] hugetlbfs: fix memory leak for resv_map

[Mike Kravetz <mike.kravetz@oracle.com>]

On 3/5/19 10:10 PM, Yufen Yu wrote:
> 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>

Thank you.  That is the approach I had in mind.

Unfortunately, this patch causes several regressions in the libhugetlbfs
test suite.  I have not debugged to determine exact cause.  

I was unsure about one thing with this approach.  We set
inode->i_mapping->private_data while holding the inode lock, so there
should be no problem there.  However, we access inode_resv_map() in the
page fault path without the inode lock.  The page fault path should get
NULL or a resv_map.  I just wonder if there may be some races where the
fault path may still be seeing NULL.

I can do more debug, but it will take a couple days as I am busy with
other things right now.
-- 
Mike Kravetz