Re: [PATCH] hugetlbfs: always use address space in inode for resv_map pointer

From: Mike Kravetz
Date: Wed May 08 2019 - 16:17:40 EST

On 5/8/19 12:10 AM, yuyufen wrote:
> On 2019/4/20 4:44, Mike Kravetz wrote:
>> Continuing discussion about commit 58b6e5e8f1ad ("hugetlbfs: fix memory
>> leak for resv_map") brought up the issue that inode->i_mapping may not
>> point to the address space embedded within the inode at inode eviction
>> time. The hugetlbfs truncate routine handles this by explicitly using
>> inode->i_data. However, code cleaning up the resv_map will still use
>> the address space pointed to by inode->i_mapping. Luckily, private_data
>> is NULL for address spaces in all such cases today but, there is no
>> guarantee this will continue.
>> Change all hugetlbfs code getting a resv_map pointer to explicitly get
>> it from the address space embedded within the inode. In addition, add
>> more comments in the code to indicate why this is being done.
>> Reported-by: Yufen Yu <yuyufen@xxxxxxxxxx>
>> Signed-off-by: Mike Kravetz <mike.kravetz@xxxxxxxxxx>
> Dose this patch have been applied?

Andrew has pulled it into his tree. However, I do not believe there has
been an ACK or Review, so am not sure of the exact status.

> I think it is better to add fixes label, like:
> Fixes: 58b6e5e8f1ad ("hugetlbfs: fix memory leak for resv_map")
> Since the commit 58b6e5e8f1a has been merged to stable, this patch also be needed.

It must have been the AI that decided 58b6e5e8f1a needed to go to stable.
Even though this technically does not fix 58b6e5e8f1a, I'm OK with adding
the Fixes: to force this to go to the same stable trees.

Mike Kravetz