On 01/25/23 09:24, Michal Hocko wrote:
> On Tue 24-01-23 12:56:24, Mike Kravetz wrote:
> > At first thought this seems bad. However, I believe this has been the
> > behavior since hugetlb PMD sharing was introduced in 2006 and I am
> > unaware of any reported issues. I did a audit of code looking at
> > mapcount. In addition to the above issue with smaps, there appears
> > to be an issue with 'migrate_pages' where shared pages could be migrated
> > without appropriate privilege.
> >
> > /* With MPOL_MF_MOVE, we migrate only unshared hugepage. */
> > if (flags & (MPOL_MF_MOVE_ALL) ||
> > (flags & MPOL_MF_MOVE && page_mapcount(page) == 1)) {
> > if (isolate_hugetlb(page, qp->pagelist) &&
> > (flags & MPOL_MF_STRICT))
> > /*
> > * Failed to isolate page but allow migrating pages
> > * which have been queued.
> > */
> > ret = 1;
> > }
>
> Could you elaborate what is problematic about that? The whole pmd
> sharing is a cooperative thing. So if some of the processes decides to
> migrate the page then why that should be a problem for others sharing
> that page via page table? Am I missing something obvious?
Nothing obvious. It is just that the semantics seem to be that you can
only move shared pages if you have CAP_SYS_NICE. Certainly cooperation
is implied for shared PMDs, but I would guess that most applications are
not even aware they are sharing PMDs.
Consider a group of processes sharing a hugetlb mapping. If the mapping
is PUD_SIZE - huge_page_size, there is no sharing of PMDs and a process
without CAP_SYS_NICE can not migrate the shared pages. However, if nothing
else changes and the mapping size is PUD_SIZE (and appropriately aligned)
the PMDs are shared. Should we allow a process to migrate shared pages
without CAP_SYS_NICE in this case?
--
Mike Kravetz
