On 11/12/19 12:38 PM, Jason Gunthorpe wrote: > On Mon, Nov 11, 2019 at 04:06:37PM -0800, John Hubbard wrote: >> Hi, >> >> The cover letter is long, so the more important stuff is first: >> >> * Jason, if you or someone could look at the the VFIO cleanup (patch 8) >> and conversion to FOLL_PIN (patch 18), to make sure it's use of >> remote and longterm gup matches what we discussed during the review >> of v2, I'd appreciate it. >> >> * Also for Jason and IB: as noted below, in patch 11, I am (too?) boldly >> converting from put_user_pages() to release_pages(). > > Why are we doing this? I think things got confused here someplace, as Because: a) These need put_page() calls, and b) there is no put_pages() call, but there is a release_pages() call that is, arguably, what put_pages() would be. > the comment still says: > > /** > * put_user_page() - release a gup-pinned page > * @page: pointer to page to be released > * > * Pages that were pinned via get_user_pages*() must be released via > * either put_user_page(), or one of the put_user_pages*() routines > * below. Ohhh, I missed those comments. They need to all be changed over to say "pages that were pinned via pin_user_pages*() or pin_longterm_pages*() must be released via put_user_page*()." The get_user_pages*() pages must still be released via put_page. The churn is due to a fairly significant change in strategy, whis is: instead of changing all get_user_pages*() sites to call put_user_page(), change selected sites to call pin_user_pages*() or pin_longterm_pages*(), plus put_user_page(). That allows incrementally converting the kernel over to using the new pin APIs, without taking on the huge risk of a big one-shot conversion. So, I've ended up with one place that actually needs to get reverted back to get_user_pages(), and that's the IB ODP code. > > I feel like if put_user_pages() is not the correct way to undo > get_user_pages() then it needs to be deleted. > Yes, you're right. I'll fix the put_user_page comments() as described. thanks, John Hubbard NVIDIA
