[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <867bd9d6-1d00-0d9d-368a-8224cb40a505@joelfernandes.org>
Date: Tue, 20 Jun 2023 17:21:10 -0400
From: Joel Fernandes <joel@...lfernandes.org>
To: Lorenzo Stoakes <lstoakes@...il.com>
Cc: linux-kernel@...r.kernel.org,
Linus Torvalds <torvalds@...ux-foundation.org>,
linux-kselftest@...r.kernel.org, linux-mm@...ck.org,
Shuah Khan <shuah@...nel.org>,
Vlastimil Babka <vbabka@...e.cz>,
Michal Hocko <mhocko@...e.com>,
Kirill A Shutemov <kirill@...temov.name>,
"Liam R. Howlett" <liam.howlett@...cle.com>,
"Paul E. McKenney" <paulmck@...nel.org>,
Suren Baghdasaryan <surenb@...gle.com>,
Kalesh Singh <kaleshsingh@...gle.com>,
Lokesh Gidra <lokeshgidra@...gle.com>,
Vineeth Pillai <vineeth@...byteword.org>
Subject: Re: [PATCH v4 1/7] mm/mremap: Optimize the start addresses in
move_page_tables()
On 6/20/23 17:16, Joel Fernandes wrote:
>
> Considering our discussion above that hugetlb mremap addresses should always
> starts at a PMD boundary, maybe I can just add a warning to the if() like so to
> detect any potential?
>
> if (is_vm_hugetlb_page(vma)) {
> WARN_ON_ONCE(old_addr - old_end != len);
Oops, I meant WARN_ON_ONCE(old_end - old_addr != len);
to make sure we did not mess up hugetlb mremaps.
thanks,
- Joel
Powered by blists - more mailing lists