Skip to content

Commit 26c92d3

Browse files
xzpeterakpm00
authored andcommitted
mm/selftest: uffd: explain the write missing fault check
It's not obvious why we had a write check for each of the missing messages, especially when it should be a locking op. Add a rich comment for that, and also try to explain its good side and limitations, so that if someone hit it again for either a bug or a different glibc impl there'll be some clue to start with. Link: https://lkml.kernel.org/r/20221004193400.110155-4-peterx@redhat.com Signed-off-by: Peter Xu <peterx@redhat.com> Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com> Reviewed-by: David Hildenbrand <david@redhat.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: Axel Rasmussen <axelrasmussen@google.com> Cc: Mike Rapoport <rppt@linux.vnet.ibm.com> Cc: Nadav Amit <nadav.amit@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
1 parent f9bf6c0 commit 26c92d3

File tree

1 file changed

+21
-1
lines changed

1 file changed

+21
-1
lines changed

tools/testing/selftests/vm/userfaultfd.c

Lines changed: 21 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -774,7 +774,27 @@ static void uffd_handle_page_fault(struct uffd_msg *msg,
774774
continue_range(uffd, msg->arg.pagefault.address, page_size);
775775
stats->minor_faults++;
776776
} else {
777-
/* Missing page faults */
777+
/*
778+
* Missing page faults.
779+
*
780+
* Here we force a write check for each of the missing mode
781+
* faults. It's guaranteed because the only threads that
782+
* will trigger uffd faults are the locking threads, and
783+
* their first instruction to touch the missing page will
784+
* always be pthread_mutex_lock().
785+
*
786+
* Note that here we relied on an NPTL glibc impl detail to
787+
* always read the lock type at the entry of the lock op
788+
* (pthread_mutex_t.__data.__type, offset 0x10) before
789+
* doing any locking operations to guarantee that. It's
790+
* actually not good to rely on this impl detail because
791+
* logically a pthread-compatible lib can implement the
792+
* locks without types and we can fail when linking with
793+
* them. However since we used to find bugs with this
794+
* strict check we still keep it around. Hopefully this
795+
* could be a good hint when it fails again. If one day
796+
* it'll break on some other impl of glibc we'll revisit.
797+
*/
778798
if (msg->arg.pagefault.flags & UFFD_PAGEFAULT_FLAG_WRITE)
779799
err("unexpected write fault");
780800

0 commit comments

Comments
 (0)