Re: [PATCH 3/4] mm/hugeltb: fix potential wrong gbl_reserve value for hugetlb_acct_memory()

From: Miaohe Lin
Date: Wed Apr 07 2021 - 03:24:45 EST


Hi:
On 2021/4/7 10:49, Mike Kravetz wrote:
> On 4/2/21 2:32 AM, Miaohe Lin wrote:
>> The resv_map could be NULL since this routine can be called in the evict
>> inode path for all hugetlbfs inodes. So we could have chg = 0 and this
>> would result in a negative value when chg - freed. This is unexpected for
>> hugepage_subpool_put_pages() and hugetlb_acct_memory().
>
> I am not sure if this is possible.
>
> It is true that resv_map could be NULL. However, I believe resv map
> can only be NULL for inodes that are not regular or link inodes. This
> is the inode creation code in hugetlbfs_get_inode().
>
> /*
> * Reserve maps are only needed for inodes that can have associated
> * page allocations.
> */
> if (S_ISREG(mode) || S_ISLNK(mode)) {
> resv_map = resv_map_alloc();
> if (!resv_map)
> return NULL;
> }
>

Agree.

> If resv_map is NULL, then no hugetlb pages can be allocated/associated
> with the file. As a result, remove_inode_hugepages will never find any
> huge pages associated with the inode and the passed value 'freed' will
> always be zero.
>

But I am confused now. AFAICS, remove_inode_hugepages() searches the address_space of
the inode to remove the hugepages while does not care if inode has associated resv_map.
How does it prevent hugetlb pages from being allocated/associated with the file if
resv_map is NULL? Could you please explain this more?

Many thanks.

> Does that sound correct?
>