All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: Lorenzo Stoakes <lstoakes@gmail.com>
Cc: Arnd Bergmann <arnd@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@kernel.org>, Namhyung Kim <namhyung@kernel.org>,
	Ian Rogers <irogers@google.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linux-perf-users@vger.kernel.org
Subject: Re: [PATCH] [suggestion] mm/gup: avoid IS_ERR_OR_NULL
Date: Sun, 28 May 2023 13:22:19 -0300	[thread overview]
Message-ID: <ZHN/u5hefVwsIdDN@nvidia.com> (raw)
In-Reply-To: <617c2e26-8450-4a35-9b47-c0482921f030@lucifer.local>

On Sun, May 28, 2023 at 04:13:44PM +0100, Lorenzo Stoakes wrote:
> On Sat, May 27, 2023 at 06:52:01AM -0300, Jason Gunthorpe wrote:
> > On Sat, May 20, 2023 at 10:12:40AM +0100, Lorenzo Stoakes wrote:
> > > > No, this returning 0 on failure is a foot gun. Failing to pin a single
> > > > page is always an error, the only question is what sub reason caused
> > > > the error to happen. There is no third case where it is not an error.
> > >
> > > The uprobe path thinks otherwise, but maybe the answer is that we just need
> > > to -EFAULT on missing VMA and -EPERM on invalid flags.
> >
> > I think uprobe is just broken to think there is a third outcome. Let's
> > just fix it instead of trying to pretend it makes sense.
> 
> Sure, will take a look at that if I get a chance. We can at the very least
> adjust get_user_page_vma_remote() with this fixed.
> 
> Do you feel that a partially successful pinning for other GUP callers
> should equally be treated as an error (and pages unpinned -> return error
> code)? In that instance we'd need to audit things somewhat.

That seems more deeply ingrained at least, I'm not as keen to change
it as to get rid of the 0 return result.

Jason

WARNING: multiple messages have this Message-ID (diff)
From: Jason Gunthorpe <jgg@nvidia.com>
To: Lorenzo Stoakes <lstoakes@gmail.com>
Cc: Arnd Bergmann <arnd@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@kernel.org>, Namhyung Kim <namhyung@kernel.org>,
	Ian Rogers <irogers@google.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linux-perf-users@vger.kernel.org
Subject: Re: [PATCH] [suggestion] mm/gup: avoid IS_ERR_OR_NULL
Date: Sun, 28 May 2023 13:22:19 -0300	[thread overview]
Message-ID: <ZHN/u5hefVwsIdDN@nvidia.com> (raw)
In-Reply-To: <617c2e26-8450-4a35-9b47-c0482921f030@lucifer.local>

On Sun, May 28, 2023 at 04:13:44PM +0100, Lorenzo Stoakes wrote:
> On Sat, May 27, 2023 at 06:52:01AM -0300, Jason Gunthorpe wrote:
> > On Sat, May 20, 2023 at 10:12:40AM +0100, Lorenzo Stoakes wrote:
> > > > No, this returning 0 on failure is a foot gun. Failing to pin a single
> > > > page is always an error, the only question is what sub reason caused
> > > > the error to happen. There is no third case where it is not an error.
> > >
> > > The uprobe path thinks otherwise, but maybe the answer is that we just need
> > > to -EFAULT on missing VMA and -EPERM on invalid flags.
> >
> > I think uprobe is just broken to think there is a third outcome. Let's
> > just fix it instead of trying to pretend it makes sense.
> 
> Sure, will take a look at that if I get a chance. We can at the very least
> adjust get_user_page_vma_remote() with this fixed.
> 
> Do you feel that a partially successful pinning for other GUP callers
> should equally be treated as an error (and pages unpinned -> return error
> code)? In that instance we'd need to audit things somewhat.

That seems more deeply ingrained at least, I'm not as keen to change
it as to get rid of the 0 return result.

Jason

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2023-05-28 16:22 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-19  9:39 [PATCH] [suggestion] mm/gup: avoid IS_ERR_OR_NULL Arnd Bergmann
2023-05-19  9:39 ` Arnd Bergmann
2023-05-19 14:51 ` Lorenzo Stoakes
2023-05-19 14:51   ` Lorenzo Stoakes
2023-05-19 15:09   ` Arnd Bergmann
2023-05-19 15:09     ` Arnd Bergmann
2023-05-19 15:30     ` Lorenzo Stoakes
2023-05-19 15:30       ` Lorenzo Stoakes
2023-05-19 22:17   ` Jason Gunthorpe
2023-05-19 22:17     ` Jason Gunthorpe
2023-05-20  5:19     ` Lorenzo Stoakes
2023-05-20  5:19       ` Lorenzo Stoakes
2023-05-20  8:25       ` Jason Gunthorpe
2023-05-20  8:25         ` Jason Gunthorpe
2023-05-20  9:12         ` Lorenzo Stoakes
2023-05-20  9:12           ` Lorenzo Stoakes
2023-05-27  9:52           ` Jason Gunthorpe
2023-05-27  9:52             ` Jason Gunthorpe
2023-05-28 15:13             ` Lorenzo Stoakes
2023-05-28 15:13               ` Lorenzo Stoakes
2023-05-28 16:22               ` Jason Gunthorpe [this message]
2023-05-28 16:22                 ` Jason Gunthorpe
2023-05-28 23:07                 ` John Hubbard
2023-05-28 23:07                   ` John Hubbard

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=ZHN/u5hefVwsIdDN@nvidia.com \
    --to=jgg@nvidia.com \
    --cc=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=arnd@arndb.de \
    --cc=arnd@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=irogers@google.com \
    --cc=jolsa@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=lstoakes@gmail.com \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.org \
    --cc=will@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.