Re: [patch] hugetlb strict commit accounting - v3

Andrew Morton
2006-03-10T05:39:57Z

"'David Gibson'" <david@gibson.dropbear.id.au> wrote:
>
> On Thu, Mar 09, 2006 at 08:46:53PM -0800, Andrew Morton wrote:
> > "'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.
>
> If that's so, why is clear_inode messing with it?
>

Oh. It's being bad.