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@xxxxxxxxxx> 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
