Re: [PATCH v1 1/4] mm: convert FPB_IGNORE_* into FPB_HONOR_*

From: David Hildenbrand
Date: Fri Jun 27 2025 - 12:35:00 EST


On 27.06.25 18:28, Lorenzo Stoakes wrote:
On Fri, Jun 27, 2025 at 01:55:07PM +0200, David Hildenbrand wrote:
Honoring these PTE bits is the exception, so let's invert the meaning.

With this change, most callers don't have to pass any flags.

No functional change intended.

Signed-off-by: David Hildenbrand <david@xxxxxxxxxx>

This is a nice change, it removes a lot of code I really didn't enjoy
looking at for introducing these flags all over the place.

But a nit on the naming below, I'm not a fan of 'honor' here :)

---
mm/internal.h | 16 ++++++++--------
mm/madvise.c | 3 +--
mm/memory.c | 11 +++++------
mm/mempolicy.c | 4 +---
mm/mlock.c | 3 +--
mm/mremap.c | 3 +--
mm/rmap.c | 3 +--
7 files changed, 18 insertions(+), 25 deletions(-)

diff --git a/mm/internal.h b/mm/internal.h
index e84217e27778d..9690c75063881 100644
--- a/mm/internal.h
+++ b/mm/internal.h
@@ -202,17 +202,17 @@ static inline void vma_close(struct vm_area_struct *vma)
/* Flags for folio_pte_batch(). */
typedef int __bitwise fpb_t;

-/* Compare PTEs after pte_mkclean(), ignoring the dirty bit. */
-#define FPB_IGNORE_DIRTY ((__force fpb_t)BIT(0))
+/* Compare PTEs honoring the dirty bit. */
+#define FPB_HONOR_DIRTY ((__force fpb_t)BIT(0))

Hm not to be petty but... :)

I'm not sure I find 'honor' very clear here. Ignore is very clear, 'honor' (God
the British English in me wants to say honour here but stipp :P) doesn't
necessarily tell you what is going to happen.

Perhaps PROPAGATE? or OBEY?

RESPECT? :)

--
Cheers,

David / dhildenb