Messages in this thread | | | From | "Aneesh Kumar K.V" <> | Subject | Re: [PATCH 03/18] mm, hugetlb: unify region structure handling | Date | Tue, 30 Jul 2013 22:57:37 +0530 |
| |
Joonsoo Kim <iamjoonsoo.kim@lge.com> writes:
> Currently, to track a reserved and allocated region, we use two different > ways for MAP_SHARED and MAP_PRIVATE. For MAP_SHARED, we use > address_mapping's private_list and, for MAP_PRIVATE, we use a resv_map. > Now, we are preparing to change a coarse grained lock which protect > a region structure to fine grained lock, and this difference hinder it. > So, before changing it, unify region structure handling. > > Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@lge.com> > > diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c > index a3f868a..a1ae3ada 100644 > --- a/fs/hugetlbfs/inode.c > +++ b/fs/hugetlbfs/inode.c > @@ -366,7 +366,12 @@ static void truncate_hugepages(struct inode *inode, loff_t lstart) > > static void hugetlbfs_evict_inode(struct inode *inode) > { > + struct resv_map *resv_map; > + > truncate_hugepages(inode, 0); > + resv_map = (struct resv_map *)inode->i_mapping->private_data; > + if (resv_map)
can resv_map == NULL ?
> + kref_put(&resv_map->refs, resv_map_release);
Also the kref_put is confusing. For shared mapping we don't have ref count incremented right ? So may be you can directly call resv_map_release or add a comment around explaining this more ?
> clear_inode(inode); > } > > @@ -468,6 +473,11 @@ static struct inode *hugetlbfs_get_inode(struct super_block *sb, > umode_t mode, dev_t dev) > { > struct inode *inode; > + struct resv_map *resv_map; > + > + resv_map = resv_map_alloc(); > + if (!resv_map) > + return NULL;
-aneesh
| |