[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <8e8058b7-9912-40c5-9bf8-571fee4d62a6@redhat.com>
Date: Thu, 26 Jun 2025 10:14:35 +0200
From: David Hildenbrand <david@...hat.com>
To: Matthew Wilcox <willy@...radead.org>,
"Vishal Moola (Oracle)" <vishal.moola@...il.com>
Cc: linux-mm@...ck.org, linux-kernel@...r.kernel.org,
Jordan Rome <linux@...danrome.com>, Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [RFC PATCH 1/3] mm/memory.c: convert __copy_remote_vm_str() to
folios
On 26.06.25 05:02, Matthew Wilcox wrote:
> On Wed, Jun 25, 2025 at 07:00:22PM +0100, Matthew Wilcox wrote:
>>> + folio_offset = offset_in_folio(folio, addr);
>>
>> Umm. Not sure this is safe. A folio might be mapped misaligned, so
>> 'addr' might not give you the right offset within the folio. I think
>> you might need to use addr - (vma->vm_pgoff << PAGE_SHIFT). But I'd
>> defer to others here ... particularly when it comes to anonymous folios.
>
> Sorry, this calculation is obviously wrong. It should be something like
> the calculation in linear_page_index(), only without throwing away the
> bottom PAGE_SHIFT bits. But that's for file VMAs only, and I'm not sure
> what should be done for anon vmas. Possibly there is no way?
In __folio_set_anon(), we set
folio->index = linear_page_index(vma, address);
and in __page_check_anon_rmap, we check
VM_BUG_ON_PAGE(page_pgoff(folio, page) != linear_page_index(vma, address),
So given the VMA, addr, folio, we should be able to figure out the offset
into the folio.
... but I didn't have my second coffee yet.
--
Cheers,
David / dhildenb
Powered by blists - more mailing lists