Re: [akpm-mm:mm-new] BUILD SUCCESS WITH UNVERIFIED WARNING 0c39e2f552f5e16be695cec3a1c77d6a6bf086bb

On Fri, Jul 31, 2026 at 10:05:47AM -0700, Andrew Morton wrote:
> On Fri, 31 Jul 2026 22:31:38 +0800 kernel test robot <[email protected]> wrote:
> 
> > tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-new
> > branch HEAD: 0c39e2f552f5e16be695cec3a1c77d6a6bf086bb  mm/swap, PM: hibernate: atomically replace hibernation pin
> > 
> > Unverified Warning (likely false positive, kindly check if interested):
> > 
> >     https://lore.kernel.org/oe-kbuild/[email protected]
> > 
> >     mm/hmm.c:673 hmm_do_fault() error: we previously assumed 'hmm_vma_walk->locked' could be null (see line 654)
> 
> Thanks, due to "mm/hmm: add hmm_range_fault_unlocked_timeout() for mmap
> lock-drop support".  I think we've looked at this previously.
> 
> +	if (hmm_vma_walk->locked)
> +		fault_flags |= FAULT_FLAG_ALLOW_RETRY | FAULT_FLAG_KILLABLE;
> 
> ...
> 
> +			*hmm_vma_walk->locked = false;
> 
> Stanislav, can you please take a look?

It's the same concern as before: this path can be triggered only by a buggy fault
handler.

The logic in hmm_range_fault_unlocked_timeout() mimics the same login in
GUP's fixup_user_fault().

A quote from one of my previous emails:

"Fault handlers are not supposed to return VM_FAULT_RETRY or
VM_FAULT_COMPLETED with the mmap lock dropped unless
FAULT_FLAG_ALLOW_RETRY allows that, so the NULL locked state is not
expected to be dereferenced"

Thanks,
Stanisav