On 1/15/20 7:30 AM, Christoph Hellwig wrote: > On Tue, Jan 07, 2020 at 02:45:47PM -0800, John Hubbard wrote: >> Introduce pin_user_pages*() variations of get_user_pages*() calls, >> and also pin_longterm_pages*() variations. >> >> For now, these are placeholder calls, until the various call sites >> are converted to use the correct get_user_pages*() or >> pin_user_pages*() API. > > What do the pure placeholders buy us? The API itself looks ok, > but until it actually is properly implemented it doesn't help at > all, and we've had all kinds of bad experiences with these sorts > of stub APIs. > Hi Christoph, Absolutely agreed, and in fact, after spending some time in this area I am getting a much better understanding of just how problematic "this will be used soon" APIs really are. However, this is not quite that case. The following things make this different from a "pure placeholder" API: 1) These APIs are all exercised in the following patches in this series, unless I've overlooked one, and 2) The pages are actually tracked in the very next patch that I want to post. That patch was posted as part of the v11 series [1], but Leon Romanovsky reported a problem with it, and so I'm going to add in the ability to handle larger "pin" refcounts for the huge page cases. Meanwhile, I wanted to get these long-simmering simpler preparatory patches submitted, because it's clear that the API is unaffected by the huge page refcount fix. (That fix will likely use the second struct page of the compound page, to count up higher.) [1] https://lore.kernel.org/r/20191216222537.491123-24-jhubbard@xxxxxxxxxx [PATCH v11 23/25] mm/gup: track FOLL_PIN pages thanks, -- John Hubbard NVIDIA _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
