Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Low] mm: build warning from casting bool to void * --
commit 564510db2f224719d4bea8f1947aae5cc75d3394 Author: Lorenzo Stoakes (ARM) <[email protected]> mm/mlock: eliminate weird VMA_IO_BIT abuse and simplify This commit eliminates the use of VMA_IO_BIT in mlock/munlock operations by threading a boolean through the page table walk. It updates VMA lock flag checks and removes the unnecessary allow_mlock_munlock() wrapper. > diff --git a/mm/mlock.c b/mm/mlock.c > --- a/mm/mlock.c > +++ b/mm/mlock.c [ ... ] > @@ -428,31 +417,29 @@ static void mlock_vma_pages_range(struct vm_area_struct > *vma, > .pmd_entry = mlock_pte_range, > .walk_lock = PGWALK_WRLOCK_VERIFY, > }; > + const bool lock = vma_flags_test(new_vma_flags, VMA_LOCKED_BIT); > + vma_flags_t walk_flags = *new_vma_flags; > > /* > - * There is a slight chance that concurrent page migration, > - * or page reclaim finding a page of this now-VMA_LOCKED_BIT vma, > - * will call mlock_vma_folio() and raise page's mlock_count: > - * double counting, leaving the page unevictable indefinitely. > - * Communicate this danger to mlock_vma_folio() with VMA_IO_BIT, > - * which is a VMA_SPECIAL_FLAGS flag not allowed on VMA_LOCKED_BIT vmas. > - * mmap_lock is held in write mode here, so this weird > - * combination should not be visible to other mmap_lock users; > - * but WRITE_ONCE so rmap walkers must see VMA_IO_BIT if VMA_LOCKED_BIT. > + * LOCKONFAULT without LOCKED never otherwise occurs: it marks a walk in > + * progress so that rmap-side callers, which test VMA_LOCKED_BIT, do not > + * count folios, while try_to_unmap_one(), which tests VMA_LOCKED_MASK, > + * still refuses to unmap them. > */ > - if (vma_flags_test(new_vma_flags, VMA_LOCKED_BIT)) > - vma_flags_set(new_vma_flags, VMA_IO_BIT); > + if (lock) { > + vma_flags_clear(&walk_flags, VMA_LOCKED_BIT); > + vma_flags_set(&walk_flags, VMA_LOCKONFAULT_BIT); > + } > + > vma_start_write(vma); > - vma_flags_reset_once(vma, new_vma_flags); > + vma_flags_reset_once(vma, &walk_flags); > > lru_add_drain(); > - walk_page_range_vma(vma, start, end, &mlock_walk_ops, NULL); > + walk_page_range_vma(vma, start, end, &mlock_walk_ops, (void *)lock); [Severity: Low] Does casting a boolean directly to a pointer trigger a -Wint-to-pointer-cast compiler warning on 64-bit architectures? While functionally correct since the pointer evaluates to true/false correctly when assigned back to a bool in mlock_pte_range(), this compiler warning can break kernel builds when CONFIG_WERROR is enabled due to casting a 1-byte bool to an 8-byte void pointer. Casting it via an unsigned long first, such as (void *)(unsigned long)lock, might avoid this warning. > lru_add_drain(); > > - if (vma_flags_test(new_vma_flags, VMA_IO_BIT)) { > - vma_flags_clear(new_vma_flags, VMA_IO_BIT); > + if (lock) > vma_flags_reset_once(vma, new_vma_flags); > - } > } -- Sashiko AI review ยท https://sashiko.dev/#/patchset/20260917-b4-mmap-prepare-vma-flag-sanify-v3-0-4583d8a23...@kernel.org?part=24
