linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
To: Xiao Yang <ice_yangxiao@163.com>
Cc: Liam.Howlett@oracle.com, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, ltp@lists.linux.it,
	oliver.sang@intel.com, Andrew Morton <akpm@linux-foundation.org>,
	Vlastimil Babka <vbabka@suse.cz>
Subject: Re: [PATCH] mm/vma: Return the exact errno for __split_vma() and mas_store_gfp()
Date: Mon, 9 Sep 2024 10:09:43 +0100	[thread overview]
Message-ID: <9a899c60-cb88-4991-8c5f-3fb14c8a09b8@lucifer.local> (raw)
In-Reply-To: <20240909050226.2053-1-ice_yangxiao@163.com>

On Mon, Sep 09, 2024 at 02:02:26PM GMT, Xiao Yang wrote:
> __split_vma() and mas_store_gfp() returns several types of errno on
> failure so don't ignore them in vms_gather_munmap_vmas(). For example,
> __split_vma() returns -EINVAL when an unaligned huge page is unmapped.
> This issue is reproduced by ltp memfd_create03 test.

Thanks for this! :)

Though pedantic note - please ensure to check scripts/get_maintainer.pl and cc-
the reviewers and maintainer, the maintainer being Andrew and the
reviewers being me, Liam and Vlastimil.

The maintainer is especially important as it's Andrew who'll take the patch
;)

I've cc'd them here :)

>
> Fixes: 6898c9039bc8 ("mm/vma: extract the gathering of vmas from do_vmi_align_munmap()")
> Signed-off-by: Xiao Yang <ice_yangxiao@163.com>
> Reported-by: kernel test robot <oliver.sang@intel.com>
> Closes: https://lore.kernel.org/oe-lkp/202409081536.d283a0fb-oliver.sang@intel.com
> ---
>  mm/vma.c | 9 ++++++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/mm/vma.c b/mm/vma.c
> index 8d1686fc8d5a..3feeea9a8c3d 100644
> --- a/mm/vma.c
> +++ b/mm/vma.c
> @@ -1200,7 +1200,8 @@ int vms_gather_munmap_vmas(struct vma_munmap_struct *vms,
>  			goto start_split_failed;
>  		}
>
> -		if (__split_vma(vms->vmi, vms->vma, vms->start, 1))
> +		error = __split_vma(vms->vmi, vms->vma, vms->start, 1);
> +		if (error)
>  			goto start_split_failed;

We'd probably want to stop assigning error = ENOMEM and just leave it
uninitialised if we're always going to assign it rather than filter.

You'd want to make sure that you caught any case that relies on it being
pre-assigned though.

>  	}
>  	vms->prev = vma_prev(vms->vmi);
> @@ -1220,12 +1221,14 @@ int vms_gather_munmap_vmas(struct vma_munmap_struct *vms,
>  		}
>  		/* Does it split the end? */
>  		if (next->vm_end > vms->end) {
> -			if (__split_vma(vms->vmi, next, vms->end, 0))
> +			error = __split_vma(vms->vmi, next, vms->end, 0);
> +			if (error)
>  				goto end_split_failed;

Related to point above, In this and above, you are now resetting error to 0
should this succeed while some later code might rely on this not being the
case.

Basically I'd prefer us, if Liam is cool with it, to just not initialise
error and assign when an error actually occurs.

But we filtered for a reason, need to figure out if that is still
needed...
m
>  		}
>  		vma_start_write(next);
>  		mas_set(mas_detach, vms->vma_count++);
> -		if (mas_store_gfp(mas_detach, next, GFP_KERNEL))
> +		error = mas_store_gfp(mas_detach, next, GFP_KERNEL);
> +		if (error)
>  			goto munmap_gather_failed;
>
>  		vma_mark_detached(next, true);
> --
> 2.46.0
>

I'm in general in favour of what this patch does (modulo the points about
not initialising error and checking that we don't rely on it being
initialised above), but it very much need's Liam's input.

If Liam is cool with it, I'll add tags, but let's hold off on this until we
have confirmation from him.

Thanks!


  reply	other threads:[~2024-09-09  9:10 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-09  5:02 Xiao Yang
2024-09-09  9:09 ` Lorenzo Stoakes [this message]
2024-09-09 12:55   ` 杨晓
2024-09-09 14:00   ` Liam R. Howlett
2024-09-10 13:37 ` Dan Carpenter
2024-09-10 13:55   ` Liam R. Howlett
2024-09-10 13:55   ` 杨晓

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=9a899c60-cb88-4991-8c5f-3fb14c8a09b8@lucifer.local \
    --to=lorenzo.stoakes@oracle.com \
    --cc=Liam.Howlett@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=ice_yangxiao@163.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=ltp@lists.linux.it \
    --cc=oliver.sang@intel.com \
    --cc=vbabka@suse.cz \
    /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