On 4/15/19 4:59 PM, Naoya Horiguchi wrote: > On Mon, Apr 15, 2019 at 10:11:39AM -0700, Mike Kravetz wrote: >> Let me do a little more research. I think this can all be cleaned up by >> making hugetlbfs always operate on the address space embedded in the inode. >> If nothing else, a change or explanation should be added as to why most code >> operates on inode->mapping and one place operates on &inode->i_data. > > Sounds nice, thank you. > > (Just for sharing point, not intending to block the fix ...) > My remaining concern is that this problem might not be hugetlbfs specific, > because what triggers the issue seems to be the usage of inode->i_mapping. > bd_acquire() are callable from any filesystem, so I'm wondering whether we > have something to generally prevent this kind of issue? I have gone through most of the filesystems and have not found any others where this may be an issue. From what I have seen, it is fairly common in filesystem evict_inode routines to explicitly use &inode->i_data to get at the address space passed to the truncate routine. As mentioned, even hugetlbfs does this in remove_inode_hugepages() which was previously part of the evict_inode routine. In tmpfs, the evict_inode routuine cleverly checks the address space ops to determine if the address space is associated with tmpfs. If not, it does not call the truncate routine. One of things different for hugetlbfs is that the resv_map structure hangs off the address space within the inode. Yufen Yu's approach was to move the resv_map pointer into the hugetlbfs inode extenstion hugetlbfs_inode_info. With that change, we could make the hugetlbfs evict_inode routine look more like the tmpfs routine. I do not really like the idea of increasing the size of hugetlbfs inodes as we already have a place to store the pointer. In addition, the reserv_map is used with the mappings within the address space so one could argue that it makes sense for them to be together. -- Mike Kravetz
