Re: [PATCH 1/4] mm/gup: Add FOLL_INTERRUPTIBLE
From: John Hubbard
Date: Tue Jun 28 2022 - 17:41:02 EST
On 6/28/22 12:31, Peter Xu wrote:
diff --git a/mm/gup.c b/mm/gup.c
index 551264407624..ad74b137d363 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -933,8 +933,17 @@ static int faultin_page(struct vm_area_struct *vma,
fault_flags |= FAULT_FLAG_WRITE;
if (*flags & FOLL_REMOTE)
fault_flags |= FAULT_FLAG_REMOTE;
- if (locked)
+ if (locked) {
fault_flags |= FAULT_FLAG_ALLOW_RETRY | FAULT_FLAG_KILLABLE;
+ /*
+ * We should only grant FAULT_FLAG_INTERRUPTIBLE when we're
+ * (at least) killable. It also mostly means we're not
+ * with NOWAIT. Otherwise ignore FOLL_INTERRUPTIBLE since
+ * it won't make a lot of sense to be used alone.
+ */
This comment seems a little confusing due to its location. We've just
checked "locked", but the comment is talking about other constraints.
Not sure what to suggest. Maybe move it somewhere else?
I put it here to be after FAULT_FLAG_KILLABLE we just set.
Only if we have "locked" will we set FAULT_FLAG_KILLABLE. That's also the
key we grant "killable" attribute to this GUP. So I thought it'll be good
to put here because I want to have FOLL_INTERRUPTIBLE dependent on "locked"
being set.
The key point is the connection between "locked" and killable. If the comment
explained why "locked" means "killable", that would help clear this up. The
NOWAIT sentence is also confusing to me, and adding "mostly NOWAIT" does not
clear it up either... :)
Generally, gup callers handle failures pretty well, so it's probably
not too bad. But I wanted to mention the idea that handled interrupts
might be a little surprising here.
Yes as I mentioned anyway it'll be an opt-in flag, so by default we don't
need to worry at all, IMHO, because it should really work exactly like
before, otherwise I had a bug somewhere else.. :)
Yes, that's true. OK then.
thanks,
--
John Hubbard
NVIDIA