linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Lorenzo Stoakes <lstoakes@gmail.com>
To: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 3/7] mm/gup: remove vmas parameter from get_user_pages_remote()
Date: Sat, 15 Apr 2023 12:27:13 +0100	[thread overview]
Message-ID: <64ae6557-0e46-48a8-badd-af8993645330@lucifer.local> (raw)
In-Reply-To: <65e79cf8-8713-4d2d-7a50-76d7e2aa454a@I-love.SAKURA.ne.jp>

On Sat, Apr 15, 2023 at 07:36:06PM +0900, Tetsuo Handa wrote:
> On 2023/04/15 19:14, Lorenzo Stoakes wrote:
> > On Sat, Apr 15, 2023 at 06:52:41PM +0900, Tetsuo Handa wrote:
> >> On 2023/04/15 18:08, Lorenzo Stoakes wrote:
> >>> @@ -475,10 +474,14 @@ int uprobe_write_opcode(struct arch_uprobe *auprobe, struct mm_struct *mm,
> >>>  		gup_flags |= FOLL_SPLIT_PMD;
> >>>  	/* Read the page with vaddr into memory */
> >>>  	ret = get_user_pages_remote(mm, vaddr, 1, gup_flags,
> >>> -				    &old_page, &vma, NULL);
> >>> +				    &old_page, NULL);
> >>>  	if (ret <= 0)
> >>>  		return ret;
> >>>
> >>> +	vma = vma_lookup(mm, vaddr);
> >>> +	if (!vma)
> >>> +		goto put_old;
> >>> +
> >>>  	ret = verify_opcode(old_page, vaddr, &opcode);
> >>>  	if (ret <= 0)
> >>>  		goto put_old;
> >>
> >> This conversion looks wrong.
> >> This causes returning a positive number when vma_lookup() returned NULL.
> >>
> >>   * Return 0 (success) or a negative errno.
> >>
> > 
> > In reality it shouldn't be possible for vma to return NULL, I'm adding the
> > checks to be extra careful.
> > 
> > In any case you're right, attaching a -fix patch to avoid spam:-
> 
> If you want to return -EINVAL when vma_lookup() returned NULL for whatever
> unexpected reason, returning -EOPNOTSUPP in below path looks strange.
>

This feels a little pedantic, this is not a condition that is expected to
occur in practice, I'm not sure users will be writing code to differentiate
between the two, and certainly vma being NULL implies MTE is not supported.

To differentiate with minimal churn, I'll add a WARN_ON_ONCE() here and in
each other case where an impossible condition arises as it would be
indicative of a kernel bug.

> > @@ -448,7 +448,8 @@ static int __access_remote_tags(struct mm_struct *mm, unsigned long addr,
> >  		 * would cause the existing tags to be cleared if the page
> >  		 * was never mapped with PROT_MTE.
> >  		 */
> > -		if (!(vma->vm_flags & VM_MTE)) {
> > +		vma = vma_lookup(mm, addr);
> > +		if (!vma || !(vma->vm_flags & VM_MTE)) {
> >  			ret = -EOPNOTSUPP;
> >  			put_page(page);
> >  			break;
> 
> Also,
> 
> > @@ -5591,7 +5591,9 @@ int __access_remote_vm(struct mm_struct *mm, unsigned long addr, void *buf,
> >  		struct page *page = NULL;
> >  
> >  		ret = get_user_pages_remote(mm, addr, 1,
> > -				gup_flags, &page, &vma, NULL);
> > +				gup_flags, &page, NULL);
> > +		vma = vma_lookup(mm, addr);
> > +
> >  		if (ret <= 0) {
> >  #ifndef CONFIG_HAVE_IOREMAP_PROT
> >  			break;
> > @@ -5600,7 +5602,6 @@ int __access_remote_vm(struct mm_struct *mm, unsigned long addr, void *buf,
> >  			 * Check if this is a VM_IO | VM_PFNMAP VMA, which
> >  			 * we can access using slightly different code.
> >  			 */
> > -			vma = vma_lookup(mm, addr);
> >  			if (!vma)
> >  				break;
> >  			if (vma->vm_ops && vma->vm_ops->access)
> > @@ -5617,11 +5618,11 @@ int __access_remote_vm(struct mm_struct *mm, unsigned long addr, void *buf,
> >  				bytes = PAGE_SIZE-offset;
> >  
> >  			maddr = kmap(page);
> > -			if (write) {
> > +			if (write && vma) {
> >  				copy_to_user_page(vma, page, addr,
> >  						  maddr + offset, buf, bytes);
> >  				set_page_dirty_lock(page);
> > -			} else {
> > +			} else if (vma) {
> >  				copy_from_user_page(vma, page, addr,
> >  						    buf, maddr + offset, bytes);
> >  			}
> 
> not calling copy_{from,to}_user_page() if vma == NULL is not sufficient for
> propagating an error to caller.
> 

This is a product of wanting to avoid churn, again this condition is simply
impossible. Also as a pedantic side note - the loop explicitly indicates no
errors are propagated, so there is no need to do so.

However, I want to be consistent with how I handle this and also I think
it's sensible to add warnings for violation of this 'impossible' condition
so I'll add a branch for it.

Since I'd end up confusingly fixing up a fix-patch (and I want to change
another patch in series to be consistent), I'll do a respin, apologies for
spam in advance...


  reply	other threads:[~2023-04-15 11:27 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-15  9:06 [PATCH v2 0/7] remove the vmas parameter from GUP APIs Lorenzo Stoakes
2023-04-15  9:07 ` [PATCH v2 1/7] mm/gup: remove unused vmas parameter from get_user_pages() Lorenzo Stoakes
2023-04-15  9:08 ` [PATCH v2 2/7] mm/gup: remove unused vmas parameter from pin_user_pages_remote() Lorenzo Stoakes
2023-04-15  9:08 ` [PATCH v2 3/7] mm/gup: remove vmas parameter from get_user_pages_remote() Lorenzo Stoakes
2023-04-15  9:52   ` Tetsuo Handa
2023-04-15 10:14     ` Lorenzo Stoakes
2023-04-15 10:36       ` Tetsuo Handa
2023-04-15 11:27         ` Lorenzo Stoakes [this message]
2023-04-15 11:40           ` Tetsuo Handa
2023-04-15 11:48             ` Lorenzo Stoakes
2023-04-15  9:08 ` [PATCH v2 4/7] mm/gup: introduce the FOLL_SAME_FILE GUP flag Lorenzo Stoakes
2023-04-15  9:08 ` [PATCH v2 5/7] io_uring: rsrc: use FOLL_SAME_FILE on pin_user_pages() Lorenzo Stoakes
2023-04-15  9:08 ` [PATCH v2 6/7] mm/gup: remove vmas parameter from pin_user_pages() Lorenzo Stoakes
2023-04-15  9:09 ` [PATCH v2 7/7] mm/gup: remove vmas array from internal GUP functions Lorenzo Stoakes

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=64ae6557-0e46-48a8-badd-af8993645330@lucifer.local \
    --to=lstoakes@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=penguin-kernel@i-love.sakura.ne.jp \
    /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).