Messages in this thread | | | Subject | Re: [PATCH 2/4] mm/hugeltb: simplify the return code of __vma_reservation_common() | From | Mike Kravetz <> | Date | Tue, 6 Apr 2021 17:53:59 -0700 |
| |
On 4/2/21 2:32 AM, Miaohe Lin wrote: > It's guaranteed that the vma is associated with a resv_map, i.e. either > VM_MAYSHARE or HPAGE_RESV_OWNER, when the code reaches here or we would > have returned via !resv check above. So ret must be less than 0 in the > 'else' case. Simplify the return code to make this clear.
I believe we still neeed that ternary operator in the return statement. Why?
There are two basic types of mappings to be concerned with: shared and private. For private mappings, a task can 'own' the mapping as indicated by HPAGE_RESV_OWNER. Or, it may not own the mapping. The most common way to create a non-owner private mapping is to have a task with a private mapping fork. The parent process will have HPAGE_RESV_OWNER set, the child process will not. The idea is that since the child has a COW copy of the mapping it should not consume reservations made by the parent. Only the parent (HPAGE_RESV_OWNER) is allowed to consume the reservations. Hope that makens sense?
> > Signed-off-by: Miaohe Lin <linmiaohe@huawei.com> > --- > mm/hugetlb.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/mm/hugetlb.c b/mm/hugetlb.c > index a03a50b7c410..b7864abded3d 100644 > --- a/mm/hugetlb.c > +++ b/mm/hugetlb.c > @@ -2183,7 +2183,7 @@ static long __vma_reservation_common(struct hstate *h, > return 1; > } > else
This else also handles the case !HPAGE_RESV_OWNER. In this case, we never want to indicate reservations are available. The ternary makes sure a positive value is never returned.
-- Mike Kravetz
> - return ret < 0 ? ret : 0; > + return ret; > } > > static long vma_needs_reservation(struct hstate *h, >
| |