Re: [linux-next:master 5585/5731] error[E0277]: `*const kernel::bindings::vm_uffd_ops` cannot be shared between threads safely

Re: [linux-next:master 5585/5731] error[E0277]: `*const kernel::bindings::vm_uffd_ops` cannot be shared between threads safely

[Nathan Chancellor]

+ relevant parties

On Thu, Mar 12, 2026 at 12:21:07PM +0800, kernel test robot wrote:
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> head:   f90aadf1c67c8b4969d1e5e6d4fd7227adb6e4d7
> commit: 9ef1985c003ea271369c900a93f8b834119fd150 [5585/5731] Merge branch 'mm-unstable' of https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
> config: x86_64-randconfig-002-20260312 (https://download.01.org/0day-ci/archive/20260312/202603121235.tpnRxFKO-lkp@intel.com/config)
> compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
> rustc: rustc 1.88.0 (6b00bc388 2025-06-23)
> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260312/202603121235.tpnRxFKO-lkp@intel.com/reproduce)
> 
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <lkp@intel.com>
> | Closes: https://lore.kernel.org/oe-kbuild-all/202603121235.tpnRxFKO-lkp@intel.com/
> 
> All errors (new ones prefixed by >>):
> 
> >> error[E0277]: `*const kernel::bindings::vm_uffd_ops` cannot be shared between threads safely
>    --> drivers/android/binder/page_range.rs:146:23
>    |
>    146   | static BINDER_VM_OPS: bindings::vm_operations_struct = pin_init::zeroed();
>    |                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `*const kernel::bindings::vm_uffd_ops` cannot be shared between threads safely
>    |
>    = help: within `kernel::bindings::vm_operations_struct`, the trait `Sync` is not implemented for `*const kernel::bindings::vm_uffd_ops`
>    note: required because it appears within the type `kernel::bindings::vm_operations_struct`
>    --> rust/bindings/bindings_generated.rs:72795:12
>    |
>    72795 | pub struct vm_operations_struct {
>    |            ^^^^^^^^^^^^^^^^^^^^
>    = note: shared static variables must have a type that implements `Sync`

I see this in next-20260313 still.

  $ cat kernel/configs/repro.config
  CONFIG_RUST=y
  CONFIG_ANDROID_BINDER_IPC_RUST=y
  CONFIG_USERFAULTFD=y

  $ make -skj"$(nproc)" ARCH=x86_64 LLVM=1 mrproper defconfig repro.config drivers/android/binder/rust_binder_main.o
  error[E0277]: `*const kernel::bindings::vm_uffd_ops` cannot be shared between threads safely
       --> drivers/android/binder/page_range.rs:146:23
        |
    146 | static BINDER_VM_OPS: bindings::vm_operations_struct = pin_init::zeroed();
        |                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `*const kernel::bindings::vm_uffd_ops` cannot be shared between threads safely
        |
        = help: within `kernel::bindings::vm_operations_struct`, the trait `Sync` is not implemented for `*const kernel::bindings::vm_uffd_ops`
  note: required because it appears within the type `kernel::bindings::vm_operations_struct`
       --> rust/bindings/bindings_generated.rs:71347:12
        |
  71347 | pub struct vm_operations_struct {
        |            ^^^^^^^^^^^^^^^^^^^^
        = note: shared static variables must have a type that implements `Sync`

  error: aborting due to 1 previous error

  For more information about this error, try `rustc --explain E0277`.
  ...

It looks like this is a conflict between Alice's "rust_binder: check ownership
before using vma" [1] (currently in char-misc-linus [2]) and Mike's
"userfaultfd: introduce vm_uffd_ops" [3] (currently in mm-unstable [4]),
hence why it was bisected to the -next merge commit.

[1]: https://lore.kernel.org/20260218-binder-vma-check-v2-1-60f9d695a990@google.com/
[2]: https://git.kernel.org/gregkh/char-misc/c/8ef2c15aeae07647f530d30f6daaf79eb801bcd1
[3]: https://lore.kernel.org/20260306171815.3160826-8-rppt@kernel.org/
[4]: https://git.kernel.org/akpm/mm/c/52b7ee1715b88c61fe0696db31ac90181999ec2e

Cheers,
Nathan

Re: [linux-next:master 5585/5731] error[E0277]: `*const kernel::bindings::vm_uffd_ops` cannot be shared between threads safely

[Miguel Ojeda]

On Fri, Mar 13, 2026 at 10:36 PM Nathan Chancellor <nathan@kernel.org> wrote:
>
> It looks like this is a conflict between Alice's "rust_binder: check ownership
> before using vma" [1] (currently in char-misc-linus [2]) and Mike's
> "userfaultfd: introduce vm_uffd_ops" [3] (currently in mm-unstable [4]),
> hence why it was bisected to the -next merge commit.

Thanks Nathan, yeah, adding a raw pointer (not function pointer) to
the struct makes the type `!Sync` in Rust.

I assume this is best handled with a patch on top of char-misc-linus.
Perhaps creating a wrapper to assert it is `Sync`, since the
`BINDER_VM_OPS` contents are unused (so far).

Cc'ing more folks related to the commit.

Cheers,
Miguel

Re: [linux-next:master 5585/5731] error[E0277]: `*const kernel::bindings::vm_uffd_ops` cannot be shared between threads safely

[Greg Kroah-Hartman]

On Fri, Mar 13, 2026 at 11:39:14PM +0100, Miguel Ojeda wrote:
> On Fri, Mar 13, 2026 at 10:36 PM Nathan Chancellor <nathan@kernel.org> wrote:
> >
> > It looks like this is a conflict between Alice's "rust_binder: check ownership
> > before using vma" [1] (currently in char-misc-linus [2]) and Mike's
> > "userfaultfd: introduce vm_uffd_ops" [3] (currently in mm-unstable [4]),
> > hence why it was bisected to the -next merge commit.
> 
> Thanks Nathan, yeah, adding a raw pointer (not function pointer) to
> the struct makes the type `!Sync` in Rust.
> 
> I assume this is best handled with a patch on top of char-misc-linus.
> Perhaps creating a wrapper to assert it is `Sync`, since the
> `BINDER_VM_OPS` contents are unused (so far).
> 
> Cc'ing more folks related to the commit.

char-misc-linus should get merged into Linus's tree "soon" and then we
can fix up the mm-unstable change for this.

thanks,

greg k-h

Re: [linux-next:master 5585/5731] error[E0277]: `*const kernel::bindings::vm_uffd_ops` cannot be shared between threads safely

[Alice Ryhl]

On Sat, Mar 14, 2026 at 12:13 PM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> On Fri, Mar 13, 2026 at 11:39:14PM +0100, Miguel Ojeda wrote:
> > On Fri, Mar 13, 2026 at 10:36 PM Nathan Chancellor <nathan@kernel.org> wrote:
> > >
> > > It looks like this is a conflict between Alice's "rust_binder: check ownership
> > > before using vma" [1] (currently in char-misc-linus [2]) and Mike's
> > > "userfaultfd: introduce vm_uffd_ops" [3] (currently in mm-unstable [4]),
> > > hence why it was bisected to the -next merge commit.
> >
> > Thanks Nathan, yeah, adding a raw pointer (not function pointer) to
> > the struct makes the type `!Sync` in Rust.
> >
> > I assume this is best handled with a patch on top of char-misc-linus.
> > Perhaps creating a wrapper to assert it is `Sync`, since the
> > `BINDER_VM_OPS` contents are unused (so far).
> >
> > Cc'ing more folks related to the commit.
>
> char-misc-linus should get merged into Linus's tree "soon" and then we
> can fix up the mm-unstable change for this.

I'm working on the fix as we speak. It would be ideal if it went into
char-misc-linus, because the commit that is wrong is mine, not the one
in mm.

Alice

[PATCH] rust_binder: use AssertSync for BINDER_VM_OPS

[Alice Ryhl]

When declaring an immutable global variable in Rust, the compiler checks
that it looks thread safe, because it is generally safe to access said
global variable. When using C bindings types for these globals, we don't
really want this check, because it is conservative and assumes pointers
are not thread safe.

In the case of BINDER_VM_OPS, this is a challenge when combined with the
patch 'userfaultfd: introduce vm_uffd_ops' [1], which introduces a
pointer field to vm_operations_struct. It previously only held function
pointers, which are considered thread safe.

Rust Binder should not be assuming that vm_operations_struct contains no
pointer fields, so to fix this, use AssertSync (which Rust Binder has
already declared for another similar global of type struct
file_operations with the same problem). This ensures that even if
another commit adds a pointer field to vm_operations_struct, this does
not cause problems.

Fixes: 8ef2c15aeae0 ("rust_binder: check ownership before using vma")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202603121235.tpnRxFKO-lkp@intel.com/
Link: https://lore.kernel.org/r/20260306171815.3160826-8-rppt@kernel.org [1]
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
---
 drivers/android/binder/page_range.rs       | 8 +++++---
 drivers/android/binder/rust_binder_main.rs | 2 +-
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/android/binder/page_range.rs b/drivers/android/binder/page_range.rs
index 9dfc154e5dd4..b57e0c7ba3f1 100644
--- a/drivers/android/binder/page_range.rs
+++ b/drivers/android/binder/page_range.rs
@@ -13,6 +13,8 @@
 //
 // The shrinker will use trylock methods because it locks them in a different order.
 
+use crate::AssertSync;
+
 use core::{
     marker::PhantomPinned,
     mem::{size_of, size_of_val, MaybeUninit},
@@ -143,14 +145,14 @@ pub(crate) struct ShrinkablePageRange {
 }
 
 // We do not define any ops. For now, used only to check identity of vmas.
-static BINDER_VM_OPS: bindings::vm_operations_struct = pin_init::zeroed();
+static BINDER_VM_OPS: AssertSync<bindings::vm_operations_struct> = AssertSync(pin_init::zeroed());
 
 // To ensure that we do not accidentally install pages into or zap pages from the wrong vma, we
 // check its vm_ops and private data before using it.
 fn check_vma(vma: &virt::VmaRef, owner: *const ShrinkablePageRange) -> Option<&virt::VmaMixedMap> {
     // SAFETY: Just reading the vm_ops pointer of any active vma is safe.
     let vm_ops = unsafe { (*vma.as_ptr()).vm_ops };
-    if !ptr::eq(vm_ops, &BINDER_VM_OPS) {
+    if !ptr::eq(vm_ops, &BINDER_VM_OPS.0) {
         return None;
     }
 
@@ -342,7 +344,7 @@ pub(crate) fn register_with_vma(&self, vma: &virt::VmaNew) -> Result<usize> {
 
         // SAFETY: We own the vma, and we don't use any methods on VmaNew that rely on
         // `vm_ops`.
-        unsafe { (*vma.as_ptr()).vm_ops = &BINDER_VM_OPS };
+        unsafe { (*vma.as_ptr()).vm_ops = &BINDER_VM_OPS.0 };
 
         Ok(num_pages)
     }
diff --git a/drivers/android/binder/rust_binder_main.rs b/drivers/android/binder/rust_binder_main.rs
index aa5f2a75adb4..014010662df8 100644
--- a/drivers/android/binder/rust_binder_main.rs
+++ b/drivers/android/binder/rust_binder_main.rs
@@ -306,7 +306,7 @@ fn init(_module: &'static kernel::ThisModule) -> Result<Self> {
 /// Makes the inner type Sync.
 #[repr(transparent)]
 pub struct AssertSync<T>(T);
-// SAFETY: Used only to insert `file_operations` into a global, which is safe.
+// SAFETY: Used only to insert C bindings types into globals, which is safe.
 unsafe impl<T> Sync for AssertSync<T> {}
 
 /// File operations that rust_binderfs.c can use.

base-commit: a0b9b0f1433c845bda708753db32befef78e0f1f
-- 
2.53.0.851.ga537e3e6e9-goog

Re: [PATCH] rust_binder: use AssertSync for BINDER_VM_OPS

[Gary Guo]

On Sat Mar 14, 2026 at 11:19 AM GMT, Alice Ryhl wrote:
> When declaring an immutable global variable in Rust, the compiler checks
> that it looks thread safe, because it is generally safe to access said
> global variable. When using C bindings types for these globals, we don't
> really want this check, because it is conservative and assumes pointers
> are not thread safe.
> 
> In the case of BINDER_VM_OPS, this is a challenge when combined with the
> patch 'userfaultfd: introduce vm_uffd_ops' [1], which introduces a
> pointer field to vm_operations_struct. It previously only held function
> pointers, which are considered thread safe.
> 
> Rust Binder should not be assuming that vm_operations_struct contains no
> pointer fields, so to fix this, use AssertSync (which Rust Binder has
> already declared for another similar global of type struct
> file_operations with the same problem). This ensures that even if
> another commit adds a pointer field to vm_operations_struct, this does
> not cause problems.
> 
> Fixes: 8ef2c15aeae0 ("rust_binder: check ownership before using vma")
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202603121235.tpnRxFKO-lkp@intel.com/
> Link: https://lore.kernel.org/r/20260306171815.3160826-8-rppt@kernel.org [1]
> Signed-off-by: Alice Ryhl <aliceryhl@google.com>

Reviewed-by: Gary Guo <gary@garyguo.net>

> ---
>  drivers/android/binder/page_range.rs       | 8 +++++---
>  drivers/android/binder/rust_binder_main.rs | 2 +-
>  2 files changed, 6 insertions(+), 4 deletions(-)

Re: [linux-next:master 5585/5731] error[E0277]: `*const kernel::bindings::vm_uffd_ops` cannot be shared between threads safely

[Alice Ryhl]

On Sat, Mar 14, 2026 at 12:15:30PM +0100, Alice Ryhl wrote:
> On Sat, Mar 14, 2026 at 12:13 PM Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> >
> > On Fri, Mar 13, 2026 at 11:39:14PM +0100, Miguel Ojeda wrote:
> > > On Fri, Mar 13, 2026 at 10:36 PM Nathan Chancellor <nathan@kernel.org> wrote:
> > > >
> > > > It looks like this is a conflict between Alice's "rust_binder: check ownership
> > > > before using vma" [1] (currently in char-misc-linus [2]) and Mike's
> > > > "userfaultfd: introduce vm_uffd_ops" [3] (currently in mm-unstable [4]),
> > > > hence why it was bisected to the -next merge commit.
> > >
> > > Thanks Nathan, yeah, adding a raw pointer (not function pointer) to
> > > the struct makes the type `!Sync` in Rust.
> > >
> > > I assume this is best handled with a patch on top of char-misc-linus.
> > > Perhaps creating a wrapper to assert it is `Sync`, since the
> > > `BINDER_VM_OPS` contents are unused (so far).
> > >
> > > Cc'ing more folks related to the commit.
> >
> > char-misc-linus should get merged into Linus's tree "soon" and then we
> > can fix up the mm-unstable change for this.
> 
> I'm working on the fix as we speak. It would be ideal if it went into
> char-misc-linus, because the commit that is wrong is mine, not the one
> in mm.

To clarify, to avoid breaking bisection, the commit needs to land
somewhere that is on top of commit 8ef2c15aeae0 ("rust_binder: check
ownership before using vma"), and before the mm commit. But I guess
there are several options for how to do that other than landing it
through char-misc-linus right now.

Alice

Re: [linux-next:master 5585/5731] error[E0277]: `*const kernel::bindings::vm_uffd_ops` cannot be shared between threads safely

[Greg Kroah-Hartman]

On Sat, Mar 14, 2026 at 11:30:24AM +0000, Alice Ryhl wrote:
> On Sat, Mar 14, 2026 at 12:15:30PM +0100, Alice Ryhl wrote:
> > On Sat, Mar 14, 2026 at 12:13 PM Greg Kroah-Hartman
> > <gregkh@linuxfoundation.org> wrote:
> > >
> > > On Fri, Mar 13, 2026 at 11:39:14PM +0100, Miguel Ojeda wrote:
> > > > On Fri, Mar 13, 2026 at 10:36 PM Nathan Chancellor <nathan@kernel.org> wrote:
> > > > >
> > > > > It looks like this is a conflict between Alice's "rust_binder: check ownership
> > > > > before using vma" [1] (currently in char-misc-linus [2]) and Mike's
> > > > > "userfaultfd: introduce vm_uffd_ops" [3] (currently in mm-unstable [4]),
> > > > > hence why it was bisected to the -next merge commit.
> > > >
> > > > Thanks Nathan, yeah, adding a raw pointer (not function pointer) to
> > > > the struct makes the type `!Sync` in Rust.
> > > >
> > > > I assume this is best handled with a patch on top of char-misc-linus.
> > > > Perhaps creating a wrapper to assert it is `Sync`, since the
> > > > `BINDER_VM_OPS` contents are unused (so far).
> > > >
> > > > Cc'ing more folks related to the commit.
> > >
> > > char-misc-linus should get merged into Linus's tree "soon" and then we
> > > can fix up the mm-unstable change for this.
> > 
> > I'm working on the fix as we speak. It would be ideal if it went into
> > char-misc-linus, because the commit that is wrong is mine, not the one
> > in mm.
> 
> To clarify, to avoid breaking bisection, the commit needs to land
> somewhere that is on top of commit 8ef2c15aeae0 ("rust_binder: check
> ownership before using vma"), and before the mm commit. But I guess
> there are several options for how to do that other than landing it
> through char-misc-linus right now.

I've sent off a pull request for the char-misc-linus branch now, and
after -rc4 is out I'll queue this up on top of that to get merged for
-rc5 to make this all work out ok.

thanks,

greg k-h

Re: [linux-next:master 5585/5731] error[E0277]: `*const kernel::bindings::vm_uffd_ops` cannot be shared between threads safely

[Alice Ryhl]

On Sat, Mar 14, 2026 at 12:53 PM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> On Sat, Mar 14, 2026 at 11:30:24AM +0000, Alice Ryhl wrote:
> > On Sat, Mar 14, 2026 at 12:15:30PM +0100, Alice Ryhl wrote:
> > > On Sat, Mar 14, 2026 at 12:13 PM Greg Kroah-Hartman
> > > <gregkh@linuxfoundation.org> wrote:
> > > >
> > > > On Fri, Mar 13, 2026 at 11:39:14PM +0100, Miguel Ojeda wrote:
> > > > > On Fri, Mar 13, 2026 at 10:36 PM Nathan Chancellor <nathan@kernel.org> wrote:
> > > > > >
> > > > > > It looks like this is a conflict between Alice's "rust_binder: check ownership
> > > > > > before using vma" [1] (currently in char-misc-linus [2]) and Mike's
> > > > > > "userfaultfd: introduce vm_uffd_ops" [3] (currently in mm-unstable [4]),
> > > > > > hence why it was bisected to the -next merge commit.
> > > > >
> > > > > Thanks Nathan, yeah, adding a raw pointer (not function pointer) to
> > > > > the struct makes the type `!Sync` in Rust.
> > > > >
> > > > > I assume this is best handled with a patch on top of char-misc-linus.
> > > > > Perhaps creating a wrapper to assert it is `Sync`, since the
> > > > > `BINDER_VM_OPS` contents are unused (so far).
> > > > >
> > > > > Cc'ing more folks related to the commit.
> > > >
> > > > char-misc-linus should get merged into Linus's tree "soon" and then we
> > > > can fix up the mm-unstable change for this.
> > >
> > > I'm working on the fix as we speak. It would be ideal if it went into
> > > char-misc-linus, because the commit that is wrong is mine, not the one
> > > in mm.
> >
> > To clarify, to avoid breaking bisection, the commit needs to land
> > somewhere that is on top of commit 8ef2c15aeae0 ("rust_binder: check
> > ownership before using vma"), and before the mm commit. But I guess
> > there are several options for how to do that other than landing it
> > through char-misc-linus right now.
>
> I've sent off a pull request for the char-misc-linus branch now, and
> after -rc4 is out I'll queue this up on top of that to get merged for
> -rc5 to make this all work out ok.

That works, thanks!

Alice