On 2/4/21 12:11 AM, John Hubbard wrote:

On 2/3/21 2:00 PM, Joao Martins wrote:
...

quoted

+void unpin_user_page_range_dirty_lock(struct page *page, unsigned long npages,
+				      bool make_dirty)
+{
+	unsigned long index;
+	struct page *head;
+	unsigned int ntails;
+
+	for_each_compound_range(index, &page, npages, head, ntails) {
+		if (make_dirty && !PageDirty(head))
+			set_page_dirty_lock(head);
+		put_compound_head(head, ntails, FOLL_PIN);
+	}
+}
+EXPORT_SYMBOL(unpin_user_page_range_dirty_lock);
+

Also, looking at this again while trying to verify the sg diffs in patch #4, I noticed
that the name is tricky. Usually a "range" would not have a single struct page* as the
argument. So in this case, perhaps a comment above the function would help, something
approximately like this:

/*
  * The "range" in the function name refers to the fact that the page may be a
  * compound page. If so, then that compound page will be treated as one or more
  * ranges of contiguous tail pages.
  */

...I guess. Or maybe the name is just wrong (a comment block explaining a name is
always a bad sign). 

Naming aside, a comment is probably worth nonetheless to explain what the function does.

Perhaps we should rename it to something like:

	unpin_user_compound_page_dirty_lock()

?

The thing though, is that it doesn't *only* unpin a compound page. It unpins a contiguous
range of pages (hence page_range) *and* if these are compound pages it further accelerates
things.

Albeit, your name suggestion then probably hints the caller that you should be passing a
compound page anyways, so your suggestion does have a ring to it.

	Joao