From: Ankur Arora <ankur.a.arora@oracle.com>
To: "David Hildenbrand (Red Hat)" <david@kernel.org>
Cc: Ankur Arora <ankur.a.arora@oracle.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org, x86@kernel.org,
akpm@linux-foundation.org, bp@alien8.de,
dave.hansen@linux.intel.com, hpa@zytor.com, mingo@redhat.com,
mjguzik@gmail.com, luto@kernel.org, peterz@infradead.org,
tglx@linutronix.de, willy@infradead.org, raghavendra.kt@amd.com,
chleroy@kernel.org, ioworker0@gmail.com, lizhe.67@bytedance.com,
boris.ostrovsky@oracle.com, konrad.wilk@oracle.com,
kernel test robot <lkp@intel.com>
Subject: Re: [PATCH] mm: folio_zero_user: open code range computation in folio_zero_user()
Date: Tue, 27 Jan 2026 15:42:42 -0800 [thread overview]
Message-ID: <87pl6uei6l.fsf@oracle.com> (raw)
In-Reply-To: <b7549e2a-e5e3-4052-92d9-1e7361b52b78@kernel.org>
David Hildenbrand (Red Hat) <david@kernel.org> writes:
> On 1/26/26 19:32, Ankur Arora wrote:
>> riscv64-gcc-linux-gnu (v8.5) reports a compile time assert in:
>> r[2] = DEFINE_RANGE(clamp_t(s64, fault_idx - radius, pg.start, pg.end),
>> clamp_t(s64, fault_idx + radius, pg.start, pg.end));
>> where it decides that pg.start > pg.end in:
>> clamp_t(s64, fault_idx + radius, pg.start, pg.end));
>> where pg comes from:
>> const struct range pg = DEFINE_RANGE(0, folio_nr_pages(folio) - 1);
>> That does not seem like it could be true. Even for pg.start == pg.end,
>> we would need folio_test_large() to evaluate to false at compile time:
>> static inline unsigned long folio_nr_pages(const struct folio *folio)
>> {
>> if (!folio_test_large(folio))
>> return 1;
>> return folio_large_nr_pages(folio);
>> }
>> Workaround by open coding the range computation. Also, simplify the type
>> declarations for the relevant variables.
>> Reported-by: kernel test robot <lkp@intel.com>
>> Closes: https://lore.kernel.org/oe-kbuild-all/202601240453.QCjgGdJa-lkp@intel.com/
>> Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com>
>> ---
>> Hi Andrew
>> I'm not certain about linux-next rebasing protocol, but I'm guessing
>> this patch will be squashed in patch-8 ("mm: folio_zero_user: cache
>> neighbouring pages").
>> The commit message doesn't contain anything needing preserving if it is.
>> Thanks
>> Ankur
>> mm/memory.c | 23 +++++++++++------------
>> 1 file changed, 11 insertions(+), 12 deletions(-)
>> diff --git a/mm/memory.c b/mm/memory.c
>> index ce933ee4a3dd..e49340f51fa9 100644
>> --- a/mm/memory.c
>> +++ b/mm/memory.c
>> @@ -7282,30 +7282,29 @@ static void clear_contig_highpages(struct page *page, unsigned long addr,
>> void folio_zero_user(struct folio *folio, unsigned long addr_hint)
>> {
>> const unsigned long base_addr = ALIGN_DOWN(addr_hint, folio_size(folio));
>> - const long fault_idx = (addr_hint - base_addr) / PAGE_SIZE;
>> const struct range pg = DEFINE_RANGE(0, folio_nr_pages(folio) - 1);
>> - const int radius = FOLIO_ZERO_LOCALITY_RADIUS;
>> + const long fault_idx = (addr_hint - base_addr) / PAGE_SIZE;
>> + const long radius = FOLIO_ZERO_LOCALITY_RADIUS;
>> struct range r[3];
>> int i;
>> /*
>> - * Faulting page and its immediate neighbourhood. Will be cleared at the
>> - * end to keep its cachelines hot.
>> + * Faulting page and its immediate neighbourhood. Cleared at the end to
>> + * keep its cachelines hot.
>> */
>
> Why are there rather unrelated changes in this patch? Like this comment change,
> or the movement of "fualt_idx" declaration above?
Yeah, that was a mistake.
--
ankur
next prev parent reply other threads:[~2026-01-27 23:43 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-07 7:20 [PATCH v11 0/8] mm: folio_zero_user: clear page ranges Ankur Arora
2026-01-07 7:20 ` [PATCH v11 1/8] treewide: provide a generic clear_user_page() variant Ankur Arora
2026-01-07 7:20 ` [PATCH v11 2/8] mm: introduce clear_pages() and clear_user_pages() Ankur Arora
2026-01-07 22:06 ` David Hildenbrand (Red Hat)
2026-01-07 7:20 ` [PATCH v11 3/8] highmem: introduce clear_user_highpages() Ankur Arora
2026-01-07 22:08 ` David Hildenbrand (Red Hat)
2026-01-08 6:10 ` Ankur Arora
2026-01-07 7:20 ` [PATCH v11 4/8] x86/mm: Simplify clear_page_* Ankur Arora
2026-01-07 7:20 ` [PATCH v11 5/8] x86/clear_page: Introduce clear_pages() Ankur Arora
2026-01-07 7:20 ` [PATCH v11 6/8] mm: folio_zero_user: clear pages sequentially Ankur Arora
2026-01-07 22:10 ` David Hildenbrand (Red Hat)
2026-01-07 7:20 ` [PATCH v11 7/8] mm: folio_zero_user: clear page ranges Ankur Arora
2026-01-07 22:16 ` David Hildenbrand (Red Hat)
2026-01-08 0:44 ` Ankur Arora
2026-01-08 0:43 ` [PATCH] mm: folio_zero_user: (fixup) cache neighbouring pages Ankur Arora
2026-01-08 0:53 ` Ankur Arora
2026-01-08 6:04 ` [PATCH] mm: folio_zero_user: (fixup) cache page ranges Ankur Arora
2026-01-07 7:20 ` [PATCH v11 8/8] mm: folio_zero_user: cache neighbouring pages Ankur Arora
2026-01-07 22:18 ` David Hildenbrand (Red Hat)
2026-01-26 18:32 ` [PATCH] mm: folio_zero_user: open code range computation in folio_zero_user() Ankur Arora
2026-01-26 19:05 ` Andrew Morton
2026-01-27 10:29 ` David Hildenbrand (Red Hat)
2026-01-27 23:42 ` Ankur Arora [this message]
2026-01-28 11:05 ` David Hildenbrand (Red Hat)
2026-01-28 18:59 ` [PATCH v2] " Ankur Arora
2026-02-04 21:01 ` David Hildenbrand (arm)
2026-02-04 22:31 ` Andrew Morton
2026-02-05 5:48 ` Ankur Arora
2026-02-05 12:36 ` David Hildenbrand (Arm)
2026-02-06 5:42 ` Ankur Arora
2026-02-06 8:57 ` David Hildenbrand (Arm)
2026-02-06 22:38 ` [PATCH v3] " Ankur Arora
2026-02-07 10:10 ` David Hildenbrand (Arm)
2026-02-09 1:09 ` Ankur Arora
2026-01-07 18:09 ` [PATCH v11 0/8] mm: folio_zero_user: clear page ranges Andrew Morton
2026-01-08 6:21 ` Ankur Arora
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87pl6uei6l.fsf@oracle.com \
--to=ankur.a.arora@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=boris.ostrovsky@oracle.com \
--cc=bp@alien8.de \
--cc=chleroy@kernel.org \
--cc=dave.hansen@linux.intel.com \
--cc=david@kernel.org \
--cc=hpa@zytor.com \
--cc=ioworker0@gmail.com \
--cc=konrad.wilk@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lizhe.67@bytedance.com \
--cc=lkp@intel.com \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=mjguzik@gmail.com \
--cc=peterz@infradead.org \
--cc=raghavendra.kt@amd.com \
--cc=tglx@linutronix.de \
--cc=willy@infradead.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.