linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Alistair Popple <apopple@nvidia.com>
To: sooraj <sooraj20636@gmail.com>
Cc: linux-mm@kvack.org
Subject: Re: [PATCH] mm/hmm: Prevent infinite loop in hmm_range_fault during EBUSY retries
Date: Tue, 28 Jan 2025 12:16:22 +1100	[thread overview]
Message-ID: <syxlylxq555s5rnguhjdoyip52j2zi5cxtfigebkdkhjbgtmqf@ea5bsjsopifw> (raw)
In-Reply-To: <20250128063422.7604-1-sooraj20636@gmail.com>

On Tue, Jan 28, 2025 at 01:34:22AM -0500, sooraj wrote:
> When hmm_vma_walk_test() skips a VMA (e.g., unsupported VM_IO/PFNMAP range),
> it must update hmm_vma_walk->last to the end of the skipped VMA. Failing to
> do so causes hmm_range_fault() to restart from the same address during
> -EBUSY retries, reprocessing the skipped VMA indefinitely. This results in
> an infinite loop if the VMA remains non-processable.
> 
> Update hmm_vma_walk->last to the VMA's end address in hmm_vma_walk_test()
> when skipping the range. This ensures subsequent iterations resume correctly
> after the skipped VMA, preventing infinite retry loops.

I might be missing something here but I don't understand how this causes an
infinite loop. If we skip the VMA (ie. hmm_vma_walk_test() returns 1) and
hmm_range_fault() subsequently returns -EBUSY it's true that we will reprocess
the same non-processable VMA. But a non-processable VMA won't return -EBUSY and
therefore won't cause an infinite loop in hmm_range_fault() - it will just fill
out the pfns (which is redundant) and continue on to the next VMA.

So it seems this just prevents ueslessly filling out pfns again rather than an
infinite loop. What have I missed?

 - Alistair

> Signed-off-by: sooraj <sooraj20636@gmail.com>
> ---
>  mm/hmm.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/mm/hmm.c b/mm/hmm.c
> index 7e0229ae4a5a..29e3678fede5 100644
> --- a/mm/hmm.c
> +++ b/mm/hmm.c
> @@ -547,6 +547,8 @@ static int hmm_vma_walk_test(unsigned long start, unsigned long end,
>  
>  	hmm_pfns_fill(start, end, range, HMM_PFN_ERROR);
>  
> +	/* Update last to the end of the skipped VMA to prevent reprocessing */
> +	hmm_vma_walk->last = end;
>  	/* Skip this vma and continue processing the next vma. */
>  	return 1;
>  }
> -- 
> 2.45.2
> 
> 


  parent reply	other threads:[~2025-01-28  1:16 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-28  6:34 sooraj
2025-01-28  1:00 ` Andrew Morton
2025-01-28  1:16 ` Alistair Popple [this message]
2025-01-28 18:04 ` Jason Gunthorpe

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=syxlylxq555s5rnguhjdoyip52j2zi5cxtfigebkdkhjbgtmqf@ea5bsjsopifw \
    --to=apopple@nvidia.com \
    --cc=linux-mm@kvack.org \
    --cc=sooraj20636@gmail.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox