Re: [PATCH v9 02/10] mm: Non-pmd-mappable, large folios for folio_add_new_anon_rmap()

Jiri Olsa
2024-01-24T11:19:15Z

On Wed, Jan 24, 2024 at 12:15:52PM +0100, Sven Schnelle wrote:
> Ryan Roberts <ryan.roberts@arm.com> writes:
>
> > On 14/01/2024 20:55, Jiri Olsa wrote:
> >> On Sun, Jan 14, 2024 at 06:33:56PM +0100, David Hildenbrand wrote:
> >>> On 13.01.24 23:42, Jiri Olsa wrote:
> >>>> On Thu, Dec 07, 2023 at 04:12:03PM +0000, Ryan Roberts wrote:
> >>>>> In preparation for supporting anonymous multi-size THP, improve
> >>>>> folio_add_new_anon_rmap() to allow a non-pmd-mappable, large folio to be
> >>>>> passed to it. In this case, all contained pages are accounted using the
> >>>>> order-0 folio (or base page) scheme.
> >>>>>
> >>>>> Reviewed-by: Yu Zhao <yuzhao@google.com>
> >>>>> Reviewed-by: Yin Fengwei <fengwei.yin@intel.com>
> >>>>> Reviewed-by: David Hildenbrand <david@redhat.com>
> >>>>> Reviewed-by: Barry Song <v-songbaohua@oppo.com>
> >>>>> Tested-by: Kefeng Wang <wangkefeng.wang@huawei.com>
> >>>>> Tested-by: John Hubbard <jhubbard@nvidia.com>
> >>>>> Signed-off-by: Ryan Roberts <ryan.roberts@arm.com>
> >>>>> ---
> >>>>> mm/rmap.c | 28 ++++++++++++++++++++--------
> >>>>> 1 file changed, 20 insertions(+), 8 deletions(-)
> >>>>>
> >>>>> diff --git a/mm/rmap.c b/mm/rmap.c
> >>>>> index 2a1e45e6419f..846fc79f3ca9 100644
> >>>>> --- a/mm/rmap.c
> >>>>> +++ b/mm/rmap.c
> >>>>> @@ -1335,32 +1335,44 @@ void page_add_anon_rmap(struct page *page, struct vm_area_struct *vma,
> >>>>> * This means the inc-and-test can be bypassed.
> >>>>> * The folio does not have to be locked.
> >>>>> *
> >>>>> - * If the folio is large, it is accounted as a THP. As the folio
> >>>>> + * If the folio is pmd-mappable, it is accounted as a THP. As the folio
> >>>>> * is new, it's assumed to be mapped exclusively by a single process.
> >>>>> */
> >>>>> void folio_add_new_anon_rmap(struct folio *folio, struct vm_area_struct *vma,
> >>>>> unsigned long address)
> >>>>> {
> >>>>> - int nr;
> >>>>> + int nr = folio_nr_pages(folio);
> >>>>> - VM_BUG_ON_VMA(address < vma->vm_start || address >= vma->vm_end, vma);
> >>>>> + VM_BUG_ON_VMA(address < vma->vm_start ||
> >>>>> + address + (nr << PAGE_SHIFT) > vma->vm_end, vma);
> >>>>
> >>>> hi,
> >>>> I'm hitting this bug (console output below) with adding uprobe
> >>>> on simple program like:
> >>>>
> >>>> $ cat up.c
> >>>> int main(void)
> >>>> {
> >>>> return 0;
> >>>> }
> >>>>
> >>>> # bpftrace -e 'uprobe:/home/jolsa/up:_start {}'
> >>>>
> >>>> $ ./up
> >>>>
> >>>> it's on top of current linus tree master:
> >>>> 052d534373b7 Merge tag 'exfat-for-6.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/linkinjeon/exfat
> >>>>
> >>>> before this patch it seems to work, I can send my .config if needed
> >
> > Thanks for the bug report!
>
> I just hit the same bug in our CI, but can't find the fix in -next. Is
> this in the queue somewhere?

we hit it as well, but I can see the fix in linux-next/master

4c137bc28064 uprobes: use pagesize-aligned virtual address when replacing pages

jirka