summaryrefslogtreecommitdiffstats
path: root/arch/m68k
diff options
context:
space:
mode:
authorMike Kravetz <mike.kravetz@oracle.com>2019-05-14 02:22:55 +0200
committerLinus Torvalds <torvalds@linux-foundation.org>2019-05-14 18:47:50 +0200
commitf27a5136f70a8c90e8b30a983b6f54540742f849 (patch)
treed8c614cbaa67b50e754c37ff250e9d9722293772 /arch/m68k
parentmm/z3fold.c: support page migration (diff)
downloadlinux-f27a5136f70a8c90e8b30a983b6f54540742f849.tar.xz
linux-f27a5136f70a8c90e8b30a983b6f54540742f849.zip
hugetlbfs: always use address space in inode for resv_map pointer
Continuing discussion about 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. Link: http://lkml.kernel.org/r/20190419204435.16984-1-mike.kravetz@oracle.com Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com> Reported-by: Yufen Yu <yuyufen@huawei.com> Cc: Michal Hocko <mhocko@kernel.org> Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> Cc: "Kirill A . Shutemov" <kirill.shutemov@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'arch/m68k')
0 files changed, 0 insertions, 0 deletions