Re: [PATCH] mm,madvise,hugetlb: fix unexpected data loss with MADV_DONTNEED on hugetlbfs

[Rik van Riel]

On Fri, 2022-10-21 at 13:48 -0700, Mike Kravetz wrote:
> On 10/21/22 15:45, Rik van Riel wrote:
> > A common use case for hugetlbfs is for the application to create
> > memory pools backed by huge pages, which then get handed over to
> > some malloc library (eg. jemalloc) for further management.
> > 
> > That malloc library may be doing MADV_DONTNEED calls on memory
> > that is no longer needed, expecting those calls to happen on
> > PAGE_SIZE boundaries.
> > 
> 
> Thanks Rik.  I tend to agree with this direction as it is 'breaking'
> current code.  David and I discussed this in this thread,
> https://lore.kernel.org/linux-mm/356a4b9a-1f56-ae06-b211-bd32fc93ecda@xxxxxxxxxx/
> 
> One thing to note is that there was not any documentation saying
> madvise would happen on page boundaries.  The system call takes a
> length and rounds up to page size.  However, the man page explicitly
> said it operates on a byte range.  Certainly mm people and others
> know we only operate on pages.  But, that is not what was documented.
> 
> When the change was made to add hugetlb support, the decision was
> made
> to round up the range to hugetlb page boundaries in hugetlb vmas. 
> This
> was to be consistent with how madvise operated on base pages.  At the
> same time, madvise documentation was updated say it operates on page
> boundaries as well as the behavior for hugetlb mappings.  If moving
> forward with this change we will need to update the man page.

I'll send in a patch for the man page after the patch gets
merged. I'll change the text to clarify that the system
may round up the specified length to PAGE_SIZE granularity,
which is a quantity programs can get through (IIRC) getconf.

Andrew, I split out the bit of the patch for stable.

-- 
All Rights Reversed.

Attachment: signature.asc
Description: This is a digitally signed message part