Re: [PATCH] [suggestion] mm/gup: avoid IS_ERR_OR_NULL

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 5/28/23 09:22, Jason Gunthorpe wrote:
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.

Great!

We've had previous discussions about getting rid of this pseudo-tristate
errno in gup, so I just wanted to mention that I'm also glad to see the
movement toward, "return some pages, or else a -errno". That's progress.



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.


Yes. It's not just "audit things somewhat", it's more like, "change
quite a few call sites, some of which actually gather sets of partial
results in a retry loop". So some actual coding changes there.


thanks,
--
John Hubbard
NVIDIA





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux