On 09/14/22 15:18, Mike Kravetz wrote: > With the new hugetlb vma lock in place, it can also be used to handle > page fault races with file truncation. The lock is taken at the > beginning of the code fault path in read mode. During truncation, it > is taken in write mode for each vma which has the file mapped. The > file's size (i_size) is modified before taking the vma lock to unmap. > > How are races handled? > > The page fault code checks i_size early in processing after taking the > vma lock. If the fault is beyond i_size, the fault is aborted. If the > fault is not beyond i_size the fault will continue and a new page will > be added to the file. It could be that truncation code modifies i_size > after the check in fault code. That is OK, as truncation code will soon > remove the page. The truncation code will wait until the fault is > finished, as it must obtain the vma lock in write mode. > > This patch cleans up/removes late checks in the fault paths that try to > back out pages racing with truncation. As noted above, we just let the > truncation code remove the pages. > > Signed-off-by: Mike Kravetz <mike.kravetz@xxxxxxxxxx> > --- > fs/hugetlbfs/inode.c | 31 ++++++++++++------------------- > mm/hugetlb.c | 27 ++++++--------------------- > 2 files changed, 18 insertions(+), 40 deletions(-) This patch introduced a compiler warning addressed here, https://lore.kernel.org/linux-mm/Yyj7HsJWfHDoU24U@monkey/ -- Mike Kravetz
