Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Low] Casting `bool` to `void *` causes a compiler warning/error (-Wint-to-pointer-cast). --
commit 5ca9abe89befb83b06ebb688a6a1ab1fe25a4e0e 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 during mlock/munlock operations which was previously used to prevent double-counting during migration. Instead, it threads a boolean through the page table walk and temporarily sets VMA_LOCKONFAULT_BIT without VMA_LOCKED_BIT to indicate a locking walk in progress. It also simplifies checking for VMA_LOCKED_BIT across various folio locking paths. > diff --git a/mm/mlock.c b/mm/mlock.c > index 39215a3eab1fb..4235a1518fc9e 100644 > --- a/mm/mlock.c > +++ b/mm/mlock.c [ ... ] > @@ -428,31 +417,29 @@ static void mlock_vma_pages_range(struct vm_area_struct > *vma, [ ... ] > 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 this direct cast from a boolean to a void pointer cause a compiler warning? Since a boolean is typically 1 byte and a void pointer is 8 bytes on 64-bit systems, casting directly might trigger a -Wint-to-pointer-cast warning. When building with -Werror enabled, this can result in a build failure. Would it be safer to cast it through unsigned long first, like (void *)(unsigned long)lock? > lru_add_drain(); > -- Sashiko AI review ยท https://sashiko.dev/#/patchset/20260914-b4-mmap-prepare-vma-flag-sanify-v2-0-7d9781ed5...@kernel.org?part=24
