RE: [PATCH] hugetlb_no_page might break hugetlb quota

["Zhang, Yanmin" <yanmin_zhang@linux.intel.com>]

On Mon, 2006-03-06 at 16:15, Chen, Kenneth W wrote:
> Zhang, Yanmin wrote on Sunday, March 05, 2006 10:22 PM
> > In function hugetlb_no_page, backout path always calls hugetlb_put_quota.
> > It's incorrect when find_lock_page gets the page or the new page is added
> > into page cache.
> 
> While I acknowledge the bug, this patch is not complete.  It makes file
> system quota consistent with respect to page cache state. But such quota
> (more severely, the page cache state) is still buggy, for example under
> ftruncate case: if one ftrucate hugetlb file and then tries to fault a
> page outside ftruncate area, a new hugetlb page is allocated and then
> added into page cache along with file system quota; and at the end
> returning VM_FAULT_SIGBUS.  In this case, kernel traps an unreachable
> page until possibly next mmap that extends it.  That need to be fixed.
I have another patch to fix it. The second patch is to delete checking
(!(vma->vm_flags & VM_WRITE) && len > inode->i_size) in function
hugetlbfs_file_mmap, and add a checking in hugetlb_no_page,
to implement a capability for application to mmap
an zero-length huge page area. It's useful for process to protect one area.
As a side effect, the second patch also fixes the problem you said.


> Which means we will be adding back conditional call to
> hugetlb_put_quota(mapping) in the backout path.
> 
> 
> > In addition, if the vma->vm_flags doesn't include VM_SHARED, the quota
> > shouldn't be decreased.
> 
> Why? Private hugetlb page should be charged against the quota.  Or is
> there a better reason not to do so?
I checked tmpfs and other fs. Most of them don't charge private
page against the quota.