Messages in this thread | | | Subject | Re: [PATCH 2/2] mm/frame-vec: use FOLL_LONGTERM | From | John Hubbard <> | Date | Sat, 3 Oct 2020 15:52:32 -0700 |
| |
On 10/3/20 2:45 AM, Daniel Vetter wrote: > On Sat, Oct 3, 2020 at 12:39 AM John Hubbard <jhubbard@nvidia.com> wrote: >> >> On 10/2/20 10:53 AM, Daniel Vetter wrote: >>> For $reasons I've stumbled over this code and I'm not sure the change >>> to the new gup functions in 55a650c35fea ("mm/gup: frame_vector: >>> convert get_user_pages() --> pin_user_pages()") was entirely correct. >>> >>> This here is used for long term buffers (not just quick I/O) like >>> RDMA, and John notes this in his patch. But I thought the rule for >>> these is that they need to add FOLL_LONGTERM, which John's patch >>> didn't do. >> >> Yep. The earlier gup --> pup conversion patches were intended to not >> have any noticeable behavior changes, and FOLL_LONGTERM, with it's >> special cases and such, added some risk that I wasn't ready to take >> on yet. Also, FOLL_LONGTERM rules are only *recently* getting firmed >> up. So there was some doubt at least in my mind, about which sites >> should have it. >> >> But now that we're here, I think it's really good that you've brought >> this up. It's definitely time to add FOLL_LONGTERM wherever it's missing. > > So should I keep this patch, or will it collide with a series you're working on?
It doesn't collide with anything on my end yet, because I've been slow to pick up on the need for changing callsites to add FOLL_LONGTERM. :)
And it looks like that's actually a problem, because:
> > Also with the firmed up rules, correct that I can also drop the > vma_is_fsdax check when the FOLL_LONGTERM flag is set?
That's the right direction to go *in general*, but I see that the pin_user_pages code is still a bit stuck in the past. And this patch won't actually work, with or without that vma_is_fsdax() check. Because:
get_vaddr_frames(FOLL_LONGTERM) pin_user_pages_locked() if (WARN_ON_ONCE(gup_flags & FOLL_LONGTERM)) return -EINVAL;
So, again, pin_user_pages*() is at least partly behind the times here. I can jump in and start fixing it up, but it depends on what you and Oded and others are planning? Note: there is a particular combination of dax and locking that we have to still avoid, within gup.c. That's already covered, but needs to continue to be covered when we enable FOLL_LONGTERM in the remaining pin_user_pages*() calling paths.
thanks, -- John Hubbard NVIDIA
| |