linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Liam R. Howlett" <Liam.Howlett@oracle.com>
To: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Cc: Xiao Yang <ice_yangxiao@163.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:00:02 -0400	[thread overview]
Message-ID: <adu5bbfqfurbe5tbzguhsmdgpp66guiq5akavjwfk4w37q4pwv@pd6lsmbzi3b7> (raw)
In-Reply-To: <9a899c60-cb88-4991-8c5f-3fb14c8a09b8@lucifer.local>

* Lorenzo Stoakes <lorenzo.stoakes@oracle.com> [240909 05:09]:
> 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()")

This fixes line will mean nothing in the long run, but Andrew can use it
to identify the target to squash things.

If this patch is merged and not squshed, you will create more work for
stable and get emails asking what commit it fixes.

> > 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.

We should probably drop the assignment all together.

Thanks,
Liam



  parent reply	other threads:[~2024-09-09 14:45 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
2024-09-09 12:55   ` 杨晓
2024-09-09 14:00   ` Liam R. Howlett [this message]
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=adu5bbfqfurbe5tbzguhsmdgpp66guiq5akavjwfk4w37q4pwv@pd6lsmbzi3b7 \
    --to=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=lorenzo.stoakes@oracle.com \
    --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