Skip to content

Commit 8b0f9fa

Browse files
committed
filemap: add a comment about FAULT_FLAG_RETRY_NOWAIT behavior
I thought Josef Bacik's patch to drop the mmap_sem was buggy, because when looking at the error cases, there was one case where we returned VM_FAULT_RETRY without actually dropping the mmap_sem. Josef had to explain to me (using small words) that yes, that's actually what we're supposed to do, and his patch was correct. Which not only convinced me he knew what he was doing and I should stop arguing with him, but also that I should add a comment to the case I was confused about. Patiently-pointed-out-by: Josef Bacik <josef@toxicpanda.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
1 parent 6b4c9f4 commit 8b0f9fa

File tree

1 file changed

+5
-0
lines changed

1 file changed

+5
-0
lines changed

mm/filemap.c

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -2428,6 +2428,11 @@ static int lock_page_maybe_drop_mmap(struct vm_fault *vmf, struct page *page,
24282428
if (trylock_page(page))
24292429
return 1;
24302430

2431+
/*
2432+
* NOTE! This will make us return with VM_FAULT_RETRY, but with
2433+
* the mmap_sem still held. That's how FAULT_FLAG_RETRY_NOWAIT
2434+
* is supposed to work. We have way too many special cases..
2435+
*/
24312436
if (vmf->flags & FAULT_FLAG_RETRY_NOWAIT)
24322437
return 0;
24332438

0 commit comments

Comments
 (0)