mm: add an explicit smp_wmb() to UFFDIO_CONTINUE
authorJames Houghton <jthoughton@google.com>
Thu, 7 Mar 2024 01:02:50 +0000 (01:02 +0000)
committerAndrew Morton <akpm@linux-foundation.org>
Tue, 12 Mar 2024 20:07:17 +0000 (13:07 -0700)
commitb14d1671ddd3463b931fcdc442e0a74f8ae71406
tree229bec6b73628f8cf2b5fb2ca88f48a7979f93e9
parentb555895c313511830762dbb2f469587a822c1759
mm: add an explicit smp_wmb() to UFFDIO_CONTINUE

Users of UFFDIO_CONTINUE may reasonably assume that a write memory barrier
is included as part of UFFDIO_CONTINUE.  That is, a user may believe that
all writes it has done to a page that it is now UFFDIO_CONTINUE'ing are
guaranteed to be visible to anyone subsequently reading the page through
the newly mapped virtual memory region.

Today, such a user happens to be correct.  mmget_not_zero(), for example,
is called as part of UFFDIO_CONTINUE (and comes before any PTE updates),
and it implicitly gives us a write barrier.

To be resilient against future changes, include an explicit smp_wmb().
While we're at it, optimize the smp_wmb() that is already incidentally
present for the HugeTLB case.

Merely making a syscall does not generally imply the memory ordering
constraints that we need (including on x86).

Link: https://lkml.kernel.org/r/20240307010250.3847179-1-jthoughton@google.com
Signed-off-by: James Houghton <jthoughton@google.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
Cc: Axel Rasmussen <axelrasmussen@google.com>
Cc: Muchun Song <songmuchun@bytedance.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
mm/hugetlb.c
mm/userfaultfd.c