* Re: [PATCH] mm: fix apply_to_existing_page_range() [not found] <20250409094043.1629234-1-kirill.shutemov@linux.intel.com> @ 2025-04-09 9:52 ` David Hildenbrand 2025-04-09 10:23 ` Kirill A. Shutemov 0 siblings, 1 reply; 4+ messages in thread From: David Hildenbrand @ 2025-04-09 9:52 UTC (permalink / raw) To: Kirill A. Shutemov, Andrew Morton Cc: Vlastimil Babka, linux-mm, linux-kernel, Daniel Axtens On 09.04.25 11:40, Kirill A. Shutemov wrote: > In the case of apply_to_existing_page_range(), apply_to_pte_range() is > reached with 'create' set to false. When !create, the loop over the PTE > page table is broken. > > apply_to_pte_range() will only move to the next PTE entry if 'create' is > true or if the current entry is not pte_none(). > > This means that the user of apply_to_existing_page_range() will not have > 'fn' called for any entries after the first pte_none() in the PTE page > table. > > Fix the loop logic in apply_to_pte_range(). > > Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> > Fixes: be1db4753ee6 ("mm/memory.c: add apply_to_existing_page_range() helper") > Cc: Daniel Axtens <dja@axtens.net> > --- > mm/memory.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/mm/memory.c b/mm/memory.c > index fb7b8dc75167..2094564f4dfb 100644 > --- a/mm/memory.c > +++ b/mm/memory.c > @@ -2907,11 +2907,11 @@ static int apply_to_pte_range(struct mm_struct *mm, pmd_t *pmd, > if (fn) { > do { > if (create || !pte_none(ptep_get(pte))) { > - err = fn(pte++, addr, data); > + err = fn(pte, addr, data); > if (err) > break; > } > - } while (addr += PAGE_SIZE, addr != end); > + } while (pte++, addr += PAGE_SIZE, addr != end); > } > *mask |= PGTBL_PTE_MODIFIED; > LGTM. just curious, did you run into any actual issues that are worth describing? It should affect apply_to_existing_page_range() users where create==false. There are not many, and likely most PTEs in the range they are passing are all non-none. Acked-by: David Hildenbrand <david@redhat.com> -- Cheers, David / dhildenb ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] mm: fix apply_to_existing_page_range() 2025-04-09 9:52 ` [PATCH] mm: fix apply_to_existing_page_range() David Hildenbrand @ 2025-04-09 10:23 ` Kirill A. Shutemov 2025-04-09 10:26 ` David Hildenbrand 0 siblings, 1 reply; 4+ messages in thread From: Kirill A. Shutemov @ 2025-04-09 10:23 UTC (permalink / raw) To: David Hildenbrand Cc: Kirill A. Shutemov, Andrew Morton, Vlastimil Babka, linux-mm, linux-kernel, Daniel Axtens On Wed, Apr 09, 2025 at 11:52:43AM +0200, David Hildenbrand wrote: > On 09.04.25 11:40, Kirill A. Shutemov wrote: > > In the case of apply_to_existing_page_range(), apply_to_pte_range() is > > reached with 'create' set to false. When !create, the loop over the PTE > > page table is broken. > > > > apply_to_pte_range() will only move to the next PTE entry if 'create' is > > true or if the current entry is not pte_none(). > > > > This means that the user of apply_to_existing_page_range() will not have > > 'fn' called for any entries after the first pte_none() in the PTE page > > table. > > > > Fix the loop logic in apply_to_pte_range(). > > > > Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> > > Fixes: be1db4753ee6 ("mm/memory.c: add apply_to_existing_page_range() helper") > > Cc: Daniel Axtens <dja@axtens.net> > > --- > > mm/memory.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/mm/memory.c b/mm/memory.c > > index fb7b8dc75167..2094564f4dfb 100644 > > --- a/mm/memory.c > > +++ b/mm/memory.c > > @@ -2907,11 +2907,11 @@ static int apply_to_pte_range(struct mm_struct *mm, pmd_t *pmd, > > if (fn) { > > do { > > if (create || !pte_none(ptep_get(pte))) { > > - err = fn(pte++, addr, data); > > + err = fn(pte, addr, data); > > if (err) > > break; > > } > > - } while (addr += PAGE_SIZE, addr != end); > > + } while (pte++, addr += PAGE_SIZE, addr != end); > > } > > *mask |= PGTBL_PTE_MODIFIED; > > LGTM. just curious, did you run into any actual issues that are worth > describing? I stepped on it in my non-upstream code debugging. I am not sure how it affects existing users. > It should affect apply_to_existing_page_range() users where create==false. > There are not many, and likely most PTEs in the range they are passing are > all non-none. Or we just silently leak memory :P > Acked-by: David Hildenbrand <david@redhat.com> Thanks! -- Kiryl Shutsemau / Kirill A. Shutemov ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] mm: fix apply_to_existing_page_range() 2025-04-09 10:23 ` Kirill A. Shutemov @ 2025-04-09 10:26 ` David Hildenbrand 2025-04-09 10:41 ` Kirill A. Shutemov 0 siblings, 1 reply; 4+ messages in thread From: David Hildenbrand @ 2025-04-09 10:26 UTC (permalink / raw) To: Kirill A. Shutemov Cc: Kirill A. Shutemov, Andrew Morton, Vlastimil Babka, linux-mm, linux-kernel, Daniel Axtens On 09.04.25 12:23, Kirill A. Shutemov wrote: > On Wed, Apr 09, 2025 at 11:52:43AM +0200, David Hildenbrand wrote: >> On 09.04.25 11:40, Kirill A. Shutemov wrote: >>> In the case of apply_to_existing_page_range(), apply_to_pte_range() is >>> reached with 'create' set to false. When !create, the loop over the PTE >>> page table is broken. >>> >>> apply_to_pte_range() will only move to the next PTE entry if 'create' is >>> true or if the current entry is not pte_none(). >>> >>> This means that the user of apply_to_existing_page_range() will not have >>> 'fn' called for any entries after the first pte_none() in the PTE page >>> table. >>> >>> Fix the loop logic in apply_to_pte_range(). >>> >>> Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> >>> Fixes: be1db4753ee6 ("mm/memory.c: add apply_to_existing_page_range() helper") >>> Cc: Daniel Axtens <dja@axtens.net> >>> --- >>> mm/memory.c | 4 ++-- >>> 1 file changed, 2 insertions(+), 2 deletions(-) >>> >>> diff --git a/mm/memory.c b/mm/memory.c >>> index fb7b8dc75167..2094564f4dfb 100644 >>> --- a/mm/memory.c >>> +++ b/mm/memory.c >>> @@ -2907,11 +2907,11 @@ static int apply_to_pte_range(struct mm_struct *mm, pmd_t *pmd, >>> if (fn) { >>> do { >>> if (create || !pte_none(ptep_get(pte))) { >>> - err = fn(pte++, addr, data); >>> + err = fn(pte, addr, data); >>> if (err) >>> break; >>> } >>> - } while (addr += PAGE_SIZE, addr != end); >>> + } while (pte++, addr += PAGE_SIZE, addr != end); >>> } >>> *mask |= PGTBL_PTE_MODIFIED; >> >> LGTM. just curious, did you run into any actual issues that are worth >> describing? > > I stepped on it in my non-upstream code debugging. I am not sure how it > affects existing users. > >> It should affect apply_to_existing_page_range() users where create==false. >> There are not many, and likely most PTEs in the range they are passing are >> all non-none. > > Or we just silently leak memory :P That's exactly what I am trying to figure out: is there something upstream that could actually run into this such that we should CC stable? -- Cheers, David / dhildenb ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] mm: fix apply_to_existing_page_range() 2025-04-09 10:26 ` David Hildenbrand @ 2025-04-09 10:41 ` Kirill A. Shutemov 0 siblings, 0 replies; 4+ messages in thread From: Kirill A. Shutemov @ 2025-04-09 10:41 UTC (permalink / raw) To: David Hildenbrand Cc: Kirill A. Shutemov, Andrew Morton, Vlastimil Babka, linux-mm, linux-kernel, Daniel Axtens On Wed, Apr 09, 2025 at 12:26:09PM +0200, David Hildenbrand wrote: > > > It should affect apply_to_existing_page_range() users where create==false. > > > There are not many, and likely most PTEs in the range they are passing are > > > all non-none. > > > > Or we just silently leak memory :P > > That's exactly what I am trying to figure out: is there something upstream > that could actually run into this such that we should CC stable? From a quick glance, I don't see any of them to have a problem, but the fix is trivial enough for stable@ even without a known buggy user. -- Kiryl Shutsemau / Kirill A. Shutemov ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2025-04-09 10:41 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <20250409094043.1629234-1-kirill.shutemov@linux.intel.com>
2025-04-09 9:52 ` [PATCH] mm: fix apply_to_existing_page_range() David Hildenbrand
2025-04-09 10:23 ` Kirill A. Shutemov
2025-04-09 10:26 ` David Hildenbrand
2025-04-09 10:41 ` Kirill A. Shutemov
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox