linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@ziepe.ca>
To: Christoph Hellwig <hch@lst.de>
Cc: Jerome Glisse <jglisse@redhat.com>,
	Ralph Campbell <rcampbell@nvidia.com>,
	linux-mm@kvack.org
Subject: Re: [PATCH 5/5] mm: merge hmm_vma_do_fault into into hmm_vma_walk_hole_
Date: Mon, 16 Mar 2020 13:41:10 -0300	[thread overview]
Message-ID: <20200316164110.GA27591@ziepe.ca> (raw)
In-Reply-To: <20200316135310.899364-6-hch@lst.de>

On Mon, Mar 16, 2020 at 02:53:10PM +0100, Christoph Hellwig wrote:
> There is no good reason for this split, as it just obsfucates the flow.
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>
>  mm/hmm.c | 49 ++++++++++++++++---------------------------------
>  1 file changed, 16 insertions(+), 33 deletions(-)
> 
> diff --git a/mm/hmm.c b/mm/hmm.c
> index 707edba850de..180e398170b0 100644
> +++ b/mm/hmm.c
> @@ -33,32 +33,6 @@ struct hmm_vma_walk {
>  	unsigned int		flags;
>  };
>  
> -static int hmm_vma_do_fault(struct mm_walk *walk, unsigned long addr,
> -			    bool write_fault, uint64_t *pfn)
> -{
> -	unsigned int flags = FAULT_FLAG_REMOTE;
> -	struct hmm_vma_walk *hmm_vma_walk = walk->private;
> -	struct hmm_range *range = hmm_vma_walk->range;
> -	struct vm_area_struct *vma = walk->vma;
> -	vm_fault_t ret;
> -
> -	if (!vma)
> -		goto err;
> -
> -	if (write_fault)
> -		flags |= FAULT_FLAG_WRITE;
> -
> -	ret = handle_mm_fault(vma, addr, flags);
> -	if (ret & VM_FAULT_ERROR)
> -		goto err;
> -
> -	return -EBUSY;
> -
> -err:
> -	*pfn = range->values[HMM_PFN_ERROR];
> -	return -EFAULT;
> -}
> -
>  static int hmm_pfns_fill(unsigned long addr, unsigned long end,
>  		struct hmm_range *range, enum hmm_pfn_value_e value)
>  {
> @@ -90,25 +64,34 @@ static int hmm_vma_fault(unsigned long addr, unsigned long end,
>  {
>  	struct hmm_vma_walk *hmm_vma_walk = walk->private;
>  	struct hmm_range *range = hmm_vma_walk->range;
> +	struct vm_area_struct *vma = walk->vma;
>  	uint64_t *pfns = range->pfns;
>  	unsigned long i = (addr - range->start) >> PAGE_SHIFT;
> +	unsigned int fault_flags = FAULT_FLAG_REMOTE;
>  
>  	WARN_ON_ONCE(!fault && !write_fault);
>  	hmm_vma_walk->last = addr;
>  
> -	if (write_fault && walk->vma && !(walk->vma->vm_flags & VM_WRITE))
> -		return -EPERM;
> +	if (!vma)
> +		goto out_error;
> +
> +	if (write_fault) {
> +		if (!(vma->vm_flags & VM_WRITE))
> +			return -EPERM;
> +		fault_flags |= FAULT_FLAG_WRITE;
> +	}
>  
>  	for (; addr < end; addr += PAGE_SIZE, i++) {
> -		int ret;
> -
> +		if (handle_mm_fault(vma, addr, fault_flags) & VM_FAULT_ERROR)
> +			goto out_error;
>  		pfns[i] = range->values[HMM_PFN_NONE];
> -		ret = hmm_vma_do_fault(walk, addr, write_fault, &pfns[i]);
> -		if (ret != -EBUSY)
> -			return ret;
>  	}

Yes, this is much better

>  	return -EBUSY;
> +
> +out_error:
> +	pfns[i] = range->values[HMM_PFN_ERROR];
> +	return -EFAULT;

I've also got a patch deleting these confusing HMM_PFN_ERRORs. They
are not applied consistently and no caller would scan the output for
ERROR on some failures. For instance the above doesn't set it on EPERM.

So this can just be 'return -EFAULT' instead of 'goto out_error'

I can fold that in if you agree:

Reviewed-by: Jason Gunthorpe <jgg@mellanox.com>

Jason


  reply	other threads:[~2020-03-16 16:41 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-16 13:53 misc hmm cleanups Christoph Hellwig
2020-03-16 13:53 ` [PATCH 1/5] mm: don't provide a stub for hmm_range_fault Christoph Hellwig
2020-03-16 14:37   ` Zi Yan
2020-03-16 16:45   ` Jason Gunthorpe
2020-03-16 13:53 ` [PATCH 2/5] mm: remove the unused HMM_FAULT_ALLOW_RETRY flag Christoph Hellwig
2020-03-16 16:44   ` Jason Gunthorpe
2020-03-16 13:53 ` [PATCH 3/5] mm: simplify hmm_vma_walk_hugetlb_entry Christoph Hellwig
2020-03-16 16:43   ` Jason Gunthorpe
2020-03-16 13:53 ` [PATCH 4/5] mm: don't handle the non-fault case in hmm_vma_walk_hole_ Christoph Hellwig
2020-03-16 16:43   ` Jason Gunthorpe
2020-03-16 13:53 ` [PATCH 5/5] mm: merge hmm_vma_do_fault into into hmm_vma_walk_hole_ Christoph Hellwig
2020-03-16 16:41   ` Jason Gunthorpe [this message]
2020-03-16 16:51     ` Christoph Hellwig
2020-03-16 18:01       ` Christoph Hellwig
2020-03-17 18:38 ` misc hmm cleanups Jason Gunthorpe
2020-03-17 18:55   ` Christoph Hellwig
2020-03-19  0:27     ` 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=20200316164110.GA27591@ziepe.ca \
    --to=jgg@ziepe.ca \
    --cc=hch@lst.de \
    --cc=jglisse@redhat.com \
    --cc=linux-mm@kvack.org \
    --cc=rcampbell@nvidia.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;
as well as URLs for NNTP newsgroup(s).