Re: [patch] hugetlb strict commit accounting - v3

Andrew Morton
2006-03-10T04:46:53Z

"'David Gibson'" <david@gibson.dropbear.id.au> wrote:
>
> On Thu, Mar 09, 2006 at 07:14:58PM -0800, Chen, Kenneth W wrote:
> > hugetlb strict commit accounting for shared mapping - v3
> >
> > The a region reservation list is implementation as a linked list
> > hanging off address_space i_data->private_list. It turns out that
> > clear_inode() was also looking at inode->i_data->private_list and
> > if not empty, it think inode has dirty buffers and start clearing.
> > Except it won't go very far before oops-ing. That could happen if
> > a reservation is made but no actual faulting. hugetlbfs_delete_inode
> > and hugetlbfs_forget_inode doesn't call truncate_hugepages if there
> > are no actual page in the page cache, leading to clear_inode to do
> > bad thing. Change that to always call truncate_hugepages even if
> > there are no pages in page cache and to let the unreserve code to
> > clear out the reservation linked list.
>
> Hrm.. overloading the private_list in this manner sounds fragile.
> Maybe we should move the list into the hugetlbfs specific inode data.

private_list and private_lock are available for use by the subsystem which
owns this mapping's address_space_operations. ie: hugetlbfs.

It's been this way for several years but afaik this is the first time
that's actually been taken advantage of.