* [PATCH 1/4] rust: netlink: add raw netlink abstraction
2026-03-06 15:12 [PATCH 0/4] Rust netlink support + use in Rust Binder Alice Ryhl
@ 2026-03-06 15:12 ` Alice Ryhl
2026-03-07 15:43 ` Andrew Lunn
2026-03-06 15:12 ` [PATCH 2/4] ynl_gen: generate Rust files from yaml files Alice Ryhl
` (3 subsequent siblings)
4 siblings, 1 reply; 26+ messages in thread
From: Alice Ryhl @ 2026-03-06 15:12 UTC (permalink / raw)
To: Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Trevor Gross, Danilo Krummrich,
Donald Hunter, Jakub Kicinski, David S. Miller, Eric Dumazet,
Paolo Abeni, Simon Horman, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas
Cc: linux-kernel, rust-for-linux, netdev, Alice Ryhl
This implements a safe and relatively simple API over the netlink API,
that allows you to add different attributes to a netlink message and
broadcast it. As the first user of this API only makes use of broadcast,
only broadcast messages are supported here.
This API is intended to be safe and to be easy to use in *generated*
code. This is because netlink is generally used with yaml files that
describe the underlying API, and the python generator outputs C code
(or, soon, Rust code) that lets you use the API more easily. So for
example, if there is a string field, the code generator will output a
method that internall calls `put_string()` with the right attr type.
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
---
rust/bindings/bindings_helper.h | 3 +
rust/helpers/genetlink.c | 46 +++++++
rust/helpers/helpers.c | 1 +
rust/kernel/lib.rs | 1 +
rust/kernel/netlink.rs | 267 ++++++++++++++++++++++++++++++++++++++++
5 files changed, 318 insertions(+)
diff --git a/rust/bindings/bindings_helper.h b/rust/bindings/bindings_helper.h
index 083cc44aa952..8abb626fce6c 100644
--- a/rust/bindings/bindings_helper.h
+++ b/rust/bindings/bindings_helper.h
@@ -88,6 +88,8 @@
#include <linux/wait.h>
#include <linux/workqueue.h>
#include <linux/xarray.h>
+#include <net/genetlink.h>
+#include <net/netlink.h>
#include <trace/events/rust_sample.h>
/*
@@ -105,6 +107,7 @@
const size_t RUST_CONST_HELPER_ARCH_SLAB_MINALIGN = ARCH_SLAB_MINALIGN;
const size_t RUST_CONST_HELPER_ARCH_KMALLOC_MINALIGN = ARCH_KMALLOC_MINALIGN;
const size_t RUST_CONST_HELPER_PAGE_SIZE = PAGE_SIZE;
+const size_t RUST_CONST_HELPER_GENLMSG_DEFAULT_SIZE = GENLMSG_DEFAULT_SIZE;
const gfp_t RUST_CONST_HELPER_GFP_ATOMIC = GFP_ATOMIC;
const gfp_t RUST_CONST_HELPER_GFP_KERNEL = GFP_KERNEL;
const gfp_t RUST_CONST_HELPER_GFP_KERNEL_ACCOUNT = GFP_KERNEL_ACCOUNT;
diff --git a/rust/helpers/genetlink.c b/rust/helpers/genetlink.c
new file mode 100644
index 000000000000..99ada80cfa41
--- /dev/null
+++ b/rust/helpers/genetlink.c
@@ -0,0 +1,46 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/*
+ * Copyright (C) 2026 Google LLC.
+ */
+
+#include <net/genetlink.h>
+
+#ifdef CONFIG_NET
+
+__rust_helper struct sk_buff *rust_helper_genlmsg_new(size_t payload, gfp_t flags)
+{
+ return genlmsg_new(payload, flags);
+}
+
+__rust_helper
+int rust_helper_genlmsg_multicast(const struct genl_family *family,
+ struct sk_buff *skb, u32 portid,
+ unsigned int group, gfp_t flags)
+{
+ return genlmsg_multicast(family, skb, portid, group, flags);
+}
+
+__rust_helper void rust_helper_genlmsg_cancel(struct sk_buff *skb, void *hdr)
+{
+ return genlmsg_cancel(skb, hdr);
+}
+
+__rust_helper void rust_helper_genlmsg_end(struct sk_buff *skb, void *hdr)
+{
+ return genlmsg_end(skb, hdr);
+}
+
+__rust_helper void rust_helper_nlmsg_free(struct sk_buff *skb)
+{
+ return nlmsg_free(skb);
+}
+
+__rust_helper
+int rust_helper_genl_has_listeners(const struct genl_family *family,
+ struct net *net, unsigned int group)
+{
+ return genl_has_listeners(family, net, group);
+}
+
+#endif
diff --git a/rust/helpers/helpers.c b/rust/helpers/helpers.c
index a3c42e51f00a..0813185d8760 100644
--- a/rust/helpers/helpers.c
+++ b/rust/helpers/helpers.c
@@ -32,6 +32,7 @@
#include "err.c"
#include "irq.c"
#include "fs.c"
+#include "genetlink.c"
#include "io.c"
#include "jump_label.c"
#include "kunit.c"
diff --git a/rust/kernel/lib.rs b/rust/kernel/lib.rs
index 3da92f18f4ee..c94658051d42 100644
--- a/rust/kernel/lib.rs
+++ b/rust/kernel/lib.rs
@@ -118,6 +118,7 @@
pub mod module_param;
#[cfg(CONFIG_NET)]
pub mod net;
+pub mod netlink;
pub mod num;
pub mod of;
#[cfg(CONFIG_PM_OPP)]
diff --git a/rust/kernel/netlink.rs b/rust/kernel/netlink.rs
new file mode 100644
index 000000000000..4ac9e6d919fa
--- /dev/null
+++ b/rust/kernel/netlink.rs
@@ -0,0 +1,267 @@
+// SPDX-License-Identifier: GPL-2.0
+
+// Copyright (C) 2026 Google LLC.
+
+//! Rust support for generic netlink.
+//!
+//! Currently only supports exposing multicast groups.
+//!
+//! C header: [`include/net/genetlink.h`](srctree/include/net/genetlink.h)
+#![cfg(CONFIG_NET)]
+
+use kernel::{
+ alloc::{self, AllocError},
+ error::to_result,
+ prelude::*,
+ transmute::AsBytes,
+ types::Opaque,
+ ThisModule,
+};
+
+use core::{
+ mem::ManuallyDrop,
+ ptr::NonNull, //
+};
+
+/// The default netlink message size.
+pub const GENLMSG_DEFAULT_SIZE: usize = bindings::GENLMSG_DEFAULT_SIZE;
+
+/// A wrapper around `struct sk_buff` for generic netlink messages.
+///
+/// # Invariants
+///
+/// The pointer has ownership over a valid `sk_buff`.
+pub struct SkBuff {
+ skb: NonNull<kernel::bindings::sk_buff>,
+}
+
+impl SkBuff {
+ /// Creates a new `SkBuff` with the given size.
+ pub fn new(size: usize, flags: alloc::Flags) -> Result<SkBuff, AllocError> {
+ // SAFETY: `genlmsg_new` only requires its arguments to be valid integers.
+ let skb = unsafe { bindings::genlmsg_new(size, flags.as_raw()) };
+ let skb = NonNull::new(skb).ok_or(AllocError)?;
+ Ok(SkBuff { skb })
+ }
+
+ /// Puts a generic netlink header into the `SkBuff`.
+ pub fn genlmsg_put(
+ self,
+ portid: u32,
+ seq: u32,
+ family: &'static Family,
+ cmd: u8,
+ ) -> Result<GenlMsg, AllocError> {
+ let skb = self.skb.as_ptr();
+ // SAFETY: The skb and family pointers are valid.
+ let hdr = unsafe { bindings::genlmsg_put(skb, portid, seq, family.as_raw(), 0, cmd) };
+ let hdr = NonNull::new(hdr).ok_or(AllocError)?;
+ Ok(GenlMsg { skb: self, hdr })
+ }
+}
+
+impl Drop for SkBuff {
+ fn drop(&mut self) {
+ // SAFETY: We have ownership over the `sk_buff`, so we may free it.
+ unsafe { bindings::nlmsg_free(self.skb.as_ptr()) }
+ }
+}
+
+/// A generic netlink message being constructed.
+///
+/// # Invariants
+///
+/// `hdr` references the header in this netlink message.
+pub struct GenlMsg {
+ skb: SkBuff,
+ hdr: NonNull<c_void>,
+}
+
+impl GenlMsg {
+ /// Puts an attribute into the message.
+ #[inline]
+ fn put<T>(&mut self, attrtype: c_int, value: &T) -> Result
+ where
+ T: ?Sized + AsBytes,
+ {
+ let skb = self.skb.skb.as_ptr();
+ let len = size_of_val(value);
+ let ptr = core::ptr::from_ref(value).cast::<c_void>();
+ // SAFETY: `skb` is valid by `SkBuff` type invariants, and the provided value is readable
+ // and initialized for its `size_of` bytes.
+ to_result(unsafe { bindings::nla_put(skb, attrtype, len as c_int, ptr) })
+ }
+
+ /// Puts a `u32` attribute into the message.
+ #[inline]
+ pub fn put_u32(&mut self, attrtype: c_int, value: u32) -> Result {
+ self.put(attrtype, &value)
+ }
+
+ /// Puts a string attribute into the message.
+ #[inline]
+ pub fn put_string(&mut self, attrtype: c_int, value: &CStr) -> Result {
+ self.put(attrtype, value.to_bytes_with_nul())
+ }
+
+ /// Puts a flag attribute into the message.
+ #[inline]
+ pub fn put_flag(&mut self, attrtype: c_int) -> Result {
+ let skb = self.skb.skb.as_ptr();
+ // SAFETY: `skb` is valid by `SkBuff` type invariants, and a null pointer is valid when the
+ // length is zero.
+ to_result(unsafe { bindings::nla_put(skb, attrtype, 0, core::ptr::null()) })
+ }
+
+ /// Sends the generic netlink message as a multicast message.
+ #[inline]
+ pub fn multicast(
+ self,
+ family: &'static Family,
+ portid: u32,
+ group: u32,
+ flags: alloc::Flags,
+ ) -> Result {
+ let me = ManuallyDrop::new(self);
+ // SAFETY: The `skb` and `family` pointers are valid. We pass ownership of the `skb` to
+ // `genlmsg_multicast` by not dropping `self`.
+ unsafe {
+ bindings::genlmsg_end(me.skb.skb.as_ptr(), me.hdr.as_ptr());
+ to_result(bindings::genlmsg_multicast(
+ family.as_raw(),
+ me.skb.skb.as_ptr(),
+ portid,
+ group,
+ flags.as_raw(),
+ ))
+ }
+ }
+}
+impl Drop for GenlMsg {
+ fn drop(&mut self) {
+ // SAFETY: The `hdr` pointer references the header of this generic netlink message.
+ unsafe { bindings::genlmsg_cancel(self.skb.skb.as_ptr(), self.hdr.as_ptr()) };
+ }
+}
+
+/// A generic netlink family.
+#[repr(transparent)]
+pub struct Family {
+ inner: Opaque<bindings::genl_family>,
+}
+
+// SAFETY: The `Family` type is thread safe.
+unsafe impl Sync for Family {}
+
+impl Family {
+ /// Creates a new `Family` instance.
+ pub const fn const_new(
+ module: &ThisModule,
+ name: &[u8],
+ version: u32,
+ mcgrps: &'static [MulticastGroup],
+ ) -> Family {
+ let n_mcgrps = mcgrps.len() as u8;
+ if n_mcgrps as usize != mcgrps.len() {
+ panic!("too many mcgrps");
+ }
+ let mut genl_family = bindings::genl_family {
+ version,
+ // SAFETY: This bitfield is represented as an u8.
+ _bitfield_1: unsafe {
+ core::mem::transmute::<u8, bindings::__BindgenBitfieldUnit<[u8; 1]>>(0b11u8)
+ },
+ module: module.as_ptr(),
+ mcgrps: mcgrps.as_ptr().cast(),
+ n_mcgrps,
+ ..pin_init::zeroed()
+ };
+ if CStr::from_bytes_with_nul(name).is_err() {
+ panic!("genl_family name not nul-terminated");
+ }
+ if genl_family.name.len() < name.len() {
+ panic!("genl_family name too long");
+ }
+ let mut i = 0;
+ while i < name.len() {
+ genl_family.name[i] = name[i];
+ i += 1;
+ }
+ Family {
+ inner: Opaque::new(genl_family),
+ }
+ }
+
+ /// Checks if there are any listeners for the given multicast group.
+ pub fn has_listeners(&self, group: u32) -> bool {
+ // SAFETY: The family and init_net pointers are valid.
+ unsafe {
+ bindings::genl_has_listeners(self.as_raw(), &raw mut bindings::init_net, group) != 0
+ }
+ }
+
+ /// Returns a raw pointer to the underlying `genl_family` structure.
+ pub fn as_raw(&self) -> *mut bindings::genl_family {
+ self.inner.get()
+ }
+}
+
+/// A generic netlink multicast group.
+#[repr(transparent)]
+pub struct MulticastGroup {
+ // No Opaque because fully immutable
+ group: bindings::genl_multicast_group,
+}
+
+// SAFETY: Pure data so thread safe.
+unsafe impl Sync for MulticastGroup {}
+
+impl MulticastGroup {
+ /// Creates a new `MulticastGroup` instance.
+ pub const fn const_new(name: &CStr) -> MulticastGroup {
+ let mut group: bindings::genl_multicast_group = pin_init::zeroed();
+
+ let name = name.to_bytes_with_nul();
+ if group.name.len() < name.len() {
+ panic!("genl_multicast_group name too long");
+ }
+ let mut i = 0;
+ while i < name.len() {
+ group.name[i] = name[i];
+ i += 1;
+ }
+
+ MulticastGroup { group }
+ }
+}
+
+/// A registration of a generic netlink family.
+///
+/// This type represents the registration of a [`Family`]. When an instance of this type is
+/// dropped, its respective generic netlink family will be unregistered from the system.
+///
+/// # Invariants
+///
+/// `self.family` always holds a valid reference to an initialized and registered [`genl_family`].
+pub struct Registration {
+ family: &'static Family,
+}
+
+impl Family {
+ /// Registers the generic netlink family with the kernel.
+ pub fn register(&'static self) -> Result<Registration> {
+ // SAFETY: `self.as_raw()` is a valid pointer to a `genl_family` struct.
+ // The `genl_family` struct is static, so it will outlive the registration.
+ to_result(unsafe { bindings::genl_register_family(self.as_raw()) })?;
+ Ok(Registration { family: self })
+ }
+}
+
+impl Drop for Registration {
+ fn drop(&mut self) {
+ // SAFETY: `self.family.as_raw()` is a valid pointer to a registered `genl_family` struct.
+ // The `Registration` struct ensures that `genl_unregister_family` is called exactly once
+ // for this family when it goes out of scope.
+ unsafe { bindings::genl_unregister_family(self.family.as_raw()) };
+ }
+}
--
2.53.0.473.g4a7958ca14-goog
^ permalink raw reply related [flat|nested] 26+ messages in thread* Re: [PATCH 1/4] rust: netlink: add raw netlink abstraction
2026-03-06 15:12 ` [PATCH 1/4] rust: netlink: add raw netlink abstraction Alice Ryhl
@ 2026-03-07 15:43 ` Andrew Lunn
2026-03-07 21:28 ` Alice Ryhl
0 siblings, 1 reply; 26+ messages in thread
From: Andrew Lunn @ 2026-03-07 15:43 UTC (permalink / raw)
To: Alice Ryhl
Cc: Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Trevor Gross, Danilo Krummrich,
Donald Hunter, Jakub Kicinski, David S. Miller, Eric Dumazet,
Paolo Abeni, Simon Horman, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, linux-kernel, rust-for-linux, netdev
> diff --git a/rust/kernel/netlink.rs b/rust/kernel/netlink.rs
...
> +/// The default netlink message size.
> +pub const GENLMSG_DEFAULT_SIZE: usize = bindings::GENLMSG_DEFAULT_SIZE;
> +
> +/// A wrapper around `struct sk_buff` for generic netlink messages.
> +///
> +/// # Invariants
> +///
> +/// The pointer has ownership over a valid `sk_buff`.
> +pub struct SkBuff {
> + skb: NonNull<kernel::bindings::sk_buff>,
> +}
struct sk_buff is a core data structure which appears all over the
networking stack, but also other places like crypto, scsi, tty, file
systems, etc. Since it is a top level data structure, it seems odd
Rust puts it into netlink.rs.
How do you see the Rust SkBuff evolving to a general purpose data
structure which can be used everywhere?
Andrew
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [PATCH 1/4] rust: netlink: add raw netlink abstraction
2026-03-07 15:43 ` Andrew Lunn
@ 2026-03-07 21:28 ` Alice Ryhl
2026-03-08 14:48 ` Andrew Lunn
0 siblings, 1 reply; 26+ messages in thread
From: Alice Ryhl @ 2026-03-07 21:28 UTC (permalink / raw)
To: Andrew Lunn
Cc: Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Trevor Gross, Danilo Krummrich,
Donald Hunter, Jakub Kicinski, David S. Miller, Eric Dumazet,
Paolo Abeni, Simon Horman, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, linux-kernel, rust-for-linux, netdev
On Sat, Mar 07, 2026 at 04:43:02PM +0100, Andrew Lunn wrote:
> > diff --git a/rust/kernel/netlink.rs b/rust/kernel/netlink.rs
>
> ...
>
> > +/// The default netlink message size.
> > +pub const GENLMSG_DEFAULT_SIZE: usize = bindings::GENLMSG_DEFAULT_SIZE;
> > +
> > +/// A wrapper around `struct sk_buff` for generic netlink messages.
> > +///
> > +/// # Invariants
> > +///
> > +/// The pointer has ownership over a valid `sk_buff`.
> > +pub struct SkBuff {
> > + skb: NonNull<kernel::bindings::sk_buff>,
> > +}
>
> struct sk_buff is a core data structure which appears all over the
> networking stack, but also other places like crypto, scsi, tty, file
> systems, etc. Since it is a top level data structure, it seems odd
> Rust puts it into netlink.rs.
>
> How do you see the Rust SkBuff evolving to a general purpose data
> structure which can be used everywhere?
We can make a kernel::net module (rust/kernel/net/) and put it there
instead? I guess netlink.rs can also be a submodule of that.
Hmm ... but I'm currently using genlmsg_new() / nlmsg_free(), and I
assume the other use-cases do not go through those methods, since they
sound netlink specific.
To be honest, I'm new to the kernel's networking stack, so I probably
can't design Rust wrapper for sk_buff that supports all those different
usecases without someone walking me through how it works. It may or may
not be best to write a netlink-specific struct now and expand it later.
Alice
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [PATCH 1/4] rust: netlink: add raw netlink abstraction
2026-03-07 21:28 ` Alice Ryhl
@ 2026-03-08 14:48 ` Andrew Lunn
2026-03-08 15:23 ` Alice Ryhl
0 siblings, 1 reply; 26+ messages in thread
From: Andrew Lunn @ 2026-03-08 14:48 UTC (permalink / raw)
To: Alice Ryhl
Cc: Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Trevor Gross, Danilo Krummrich,
Donald Hunter, Jakub Kicinski, David S. Miller, Eric Dumazet,
Paolo Abeni, Simon Horman, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, linux-kernel, rust-for-linux, netdev
> We can make a kernel::net module (rust/kernel/net/) and put it there
> instead? I guess netlink.rs can also be a submodule of that.
>
> Hmm ... but I'm currently using genlmsg_new() / nlmsg_free(), and I
> assume the other use-cases do not go through those methods, since they
> sound netlink specific.
>
> To be honest, I'm new to the kernel's networking stack, so I probably
> can't design Rust wrapper for sk_buff that supports all those different
> usecases without someone walking me through how it works. It may or may
> not be best to write a netlink-specific struct now and expand it later.
At its core, an skbuff represents a block of memory. Normally that
memory would be packet data flowing through the network stack. You can
append to the front and back of the data in the buffer. You can add
the buffer to linked lists, there are reference counting operations,
so the buffer can have multiple users, there are places you can store
per protocol data, and places you can store data while within one
protocol layer, etc.
When using sk_buff for packet data, you are generally on a fast path,
so much of the code is in header files as inline functions. This is
going to make rust binding harder, my current understanding is that it
is hard to make use of such functions from rust.
However, for netlink, its is slow path code, it seems like all the
functions you need to call are in object files, not inline headers.
I also suspect, but don't know, that the netlink upper API is disjoint
to the packet handling upper API. How you allocate a skbuff for
netlink is different to packet data. It is very likely an error if you
try to transmit out an interface an skbuff allocated for netlink
usage, etc.
So, maybe you can have a base definition of skbuff in rust/kernel/net,
and build on top of that to make a netlink specific skbuff, with a
limited list of methods which can access it, those needed for netlink?
Make use of the Rust type system? And leave the messy fast path packet
data things for somebody else.
Andrew
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [PATCH 1/4] rust: netlink: add raw netlink abstraction
2026-03-08 14:48 ` Andrew Lunn
@ 2026-03-08 15:23 ` Alice Ryhl
2026-03-08 17:24 ` Andrew Lunn
0 siblings, 1 reply; 26+ messages in thread
From: Alice Ryhl @ 2026-03-08 15:23 UTC (permalink / raw)
To: Andrew Lunn
Cc: Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Trevor Gross, Danilo Krummrich,
Donald Hunter, Jakub Kicinski, David S. Miller, Eric Dumazet,
Paolo Abeni, Simon Horman, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, linux-kernel, rust-for-linux, netdev
On Sun, Mar 08, 2026 at 03:48:40PM +0100, Andrew Lunn wrote:
> > We can make a kernel::net module (rust/kernel/net/) and put it there
> > instead? I guess netlink.rs can also be a submodule of that.
> >
> > Hmm ... but I'm currently using genlmsg_new() / nlmsg_free(), and I
> > assume the other use-cases do not go through those methods, since they
> > sound netlink specific.
> >
> > To be honest, I'm new to the kernel's networking stack, so I probably
> > can't design Rust wrapper for sk_buff that supports all those different
> > usecases without someone walking me through how it works. It may or may
> > not be best to write a netlink-specific struct now and expand it later.
>
> At its core, an skbuff represents a block of memory. Normally that
> memory would be packet data flowing through the network stack. You can
> append to the front and back of the data in the buffer. You can add
> the buffer to linked lists, there are reference counting operations,
> so the buffer can have multiple users, there are places you can store
> per protocol data, and places you can store data while within one
> protocol layer, etc.
>
> When using sk_buff for packet data, you are generally on a fast path,
> so much of the code is in header files as inline functions. This is
> going to make rust binding harder, my current understanding is that it
> is hard to make use of such functions from rust.
>
> However, for netlink, its is slow path code, it seems like all the
> functions you need to call are in object files, not inline headers.
There are several static inline methods that I need to call. Here is the
list:
- genlmsg_new
- genlmsg_multicast
- genlmsg_cancel
- genlmsg_end
- nlmsg_free
- genl_has_listeners
And on Android devices running this code, they will in fact have been
inlined into Rust code, permitting fast code without function call
overhead. Inlining happens via my other (recent) patchset [1], which the
Android kernel is already using in production.
[1]: https://lore.kernel.org/all/20260203-inline-helpers-v2-0-beb8547a03c9@google.com/
> I also suspect, but don't know, that the netlink upper API is disjoint
> to the packet handling upper API. How you allocate a skbuff for
> netlink is different to packet data. It is very likely an error if you
> try to transmit out an interface an skbuff allocated for netlink
> usage, etc.
If that is the case, then it sounds like the correct API design would be
to have a separate NetlinkSkBuff type so that you cannot mix them up
with an sk_buff used for packet data.
> So, maybe you can have a base definition of skbuff in rust/kernel/net,
> and build on top of that to make a netlink specific skbuff, with a
> limited list of methods which can access it, those needed for netlink?
> Make use of the Rust type system? And leave the messy fast path packet
> data things for somebody else.
That makes sense to me. If there is duplication between the two sk_buff
types, then one can be defined in terms of the other (or maybe it's
easier to not do that).
Alice
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH 1/4] rust: netlink: add raw netlink abstraction
2026-03-08 15:23 ` Alice Ryhl
@ 2026-03-08 17:24 ` Andrew Lunn
2026-03-09 8:38 ` Alice Ryhl
0 siblings, 1 reply; 26+ messages in thread
From: Andrew Lunn @ 2026-03-08 17:24 UTC (permalink / raw)
To: Alice Ryhl
Cc: Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Trevor Gross, Danilo Krummrich,
Donald Hunter, Jakub Kicinski, David S. Miller, Eric Dumazet,
Paolo Abeni, Simon Horman, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, linux-kernel, rust-for-linux, netdev
> There are several static inline methods that I need to call. Here is the
> list:
>
> - genlmsg_new
> - genlmsg_multicast
> - genlmsg_cancel
> - genlmsg_end
> - nlmsg_free
> - genl_has_listeners
>
> And on Android devices running this code, they will in fact have been
> inlined into Rust code, permitting fast code without function call
> overhead. Inlining happens via my other (recent) patchset [1], which the
> Android kernel is already using in production.
>
> [1]: https://lore.kernel.org/all/20260203-inline-helpers-v2-0-beb8547a03c9@google.com/
Ah, cool. That is going to be very useful in networking.
> If that is the case, then it sounds like the correct API design would be
> to have a separate NetlinkSkBuff type so that you cannot mix them up
> with an sk_buff used for packet data.
>
> > So, maybe you can have a base definition of skbuff in rust/kernel/net,
> > and build on top of that to make a netlink specific skbuff, with a
> > limited list of methods which can access it, those needed for netlink?
> > Make use of the Rust type system? And leave the messy fast path packet
> > data things for somebody else.
>
> That makes sense to me. If there is duplication between the two sk_buff
> types, then one can be defined in terms of the other (or maybe it's
> easier to not do that).
Probably struct sk_buff is one of those complex things where we make
our best guess design now, and be prepared to redesign and refactor
the code as we learn more. To me, it feels like we need a base SkBuff
with full access to all API methods. And then a restricted type for
NetlinkSkBuff on top of that for users of netlink.
Andrew
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH 1/4] rust: netlink: add raw netlink abstraction
2026-03-08 17:24 ` Andrew Lunn
@ 2026-03-09 8:38 ` Alice Ryhl
0 siblings, 0 replies; 26+ messages in thread
From: Alice Ryhl @ 2026-03-09 8:38 UTC (permalink / raw)
To: Andrew Lunn
Cc: Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Trevor Gross, Danilo Krummrich,
Donald Hunter, Jakub Kicinski, David S. Miller, Eric Dumazet,
Paolo Abeni, Simon Horman, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, linux-kernel, rust-for-linux, netdev
On Sun, Mar 08, 2026 at 06:24:16PM +0100, Andrew Lunn wrote:
> > If that is the case, then it sounds like the correct API design would be
> > to have a separate NetlinkSkBuff type so that you cannot mix them up
> > with an sk_buff used for packet data.
> >
> > > So, maybe you can have a base definition of skbuff in rust/kernel/net,
> > > and build on top of that to make a netlink specific skbuff, with a
> > > limited list of methods which can access it, those needed for netlink?
> > > Make use of the Rust type system? And leave the messy fast path packet
> > > data things for somebody else.
> >
> > That makes sense to me. If there is duplication between the two sk_buff
> > types, then one can be defined in terms of the other (or maybe it's
> > easier to not do that).
>
> Probably struct sk_buff is one of those complex things where we make
> our best guess design now, and be prepared to redesign and refactor
> the code as we learn more. To me, it feels like we need a base SkBuff
> with full access to all API methods. And then a restricted type for
> NetlinkSkBuff on top of that for users of netlink.
Agreed. Though in this patchset, I don't believe I use any of the base
skbuff methods, except for the fact that the nlmsg methods seem to wrap
them. So it is probably dead code to add much right now unless I bypass
the nlmsg wrappers.
Alice
^ permalink raw reply [flat|nested] 26+ messages in thread
* [PATCH 2/4] ynl_gen: generate Rust files from yaml files
2026-03-06 15:12 [PATCH 0/4] Rust netlink support + use in Rust Binder Alice Ryhl
2026-03-06 15:12 ` [PATCH 1/4] rust: netlink: add raw netlink abstraction Alice Ryhl
@ 2026-03-06 15:12 ` Alice Ryhl
2026-03-07 18:41 ` Jakub Kicinski
2026-03-06 15:12 ` [PATCH 3/4] rust_binder: add generated netlink.rs file Alice Ryhl
` (2 subsequent siblings)
4 siblings, 1 reply; 26+ messages in thread
From: Alice Ryhl @ 2026-03-06 15:12 UTC (permalink / raw)
To: Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Trevor Gross, Danilo Krummrich,
Donald Hunter, Jakub Kicinski, David S. Miller, Eric Dumazet,
Paolo Abeni, Simon Horman, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas
Cc: linux-kernel, rust-for-linux, netdev, Alice Ryhl
To generate netlink frames from Rust code easily, generate Rust
libraries with methods for generating different netlink messages as
appropriate.
The new 'rust' type corresponds to a Rust version of the C target
'kernel'. There is no Rust version of the 'uapi' target since Rust code
exports its uapi via C headers - choice of language is opaque to
userspace.
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
---
tools/net/ynl/pyynl/ynl_gen_c.py | 132 ++++++++++++++++++++++++++++++++++++++-
tools/net/ynl/ynl-regen.sh | 2 +-
2 files changed, 132 insertions(+), 2 deletions(-)
diff --git a/tools/net/ynl/pyynl/ynl_gen_c.py b/tools/net/ynl/pyynl/ynl_gen_c.py
index 0e1e486c1185..5ddc8f84c4a3 100755
--- a/tools/net/ynl/pyynl/ynl_gen_c.py
+++ b/tools/net/ynl/pyynl/ynl_gen_c.py
@@ -19,6 +19,7 @@ import pathlib
import os
import re
import shutil
+import subprocess
import sys
import tempfile
import yaml as pyyaml
@@ -1744,6 +1745,19 @@ class CodeWriter:
else:
self.p('}' + line)
+ def array_start(self, line=''):
+ if line:
+ line = line + ' '
+ self.p(line + '[')
+ self._ind += 1
+
+ def array_end(self, line=''):
+ if line and line[0] not in {';', ','}:
+ line = ' ' + line
+ self._ind -= 1
+ self._nl = False
+ self.p(']' + line)
+
def write_doc_line(self, doc, indent=True):
words = doc.split()
line = ' *'
@@ -3415,10 +3429,119 @@ def find_kernel_root(full_path):
return full_path, sub_path[:-1]
+def render_rust(family, cw):
+ cw.p('#![allow(unreachable_pub, clippy::wrong_self_convention)]')
+ cw.p('use kernel::netlink::{Family, MulticastGroup};')
+ cw.p('use kernel::prelude::*;')
+ cw.nl()
+
+ family_upper = c_upper(family.ident_name)
+ family_name = f'{family_upper}_NL_FAMILY'
+ mcgrps_name = f'{family_name}_MCGRPS'
+
+ cw.p(f'pub static {family_name}: Family = Family::const_new(')
+ cw._ind += 1
+ cw.p('&crate::THIS_MODULE,')
+ cw.p(f'kernel::uapi::{family.fam_key},')
+ cw.p(f'kernel::uapi::{family.ver_key},')
+ cw.p(f'&{mcgrps_name},')
+ cw._ind -= 1
+ cw.p(');')
+ cw.nl()
+
+ if family.mcgrps['list']:
+ cw.array_start(f'static {mcgrps_name}: [MulticastGroup; {len(family.mcgrps["list"])}] = ')
+ for grp in family.mcgrps['list']:
+ cw.p(f'MulticastGroup::const_new(c"{grp["name"]}"),')
+ cw.array_end(';')
+ cw.nl()
+
+ for idx, (op_name, op) in enumerate(item for item in family.msgs.items() if 'event' in item[1]):
+ struct_name = op_name.capitalize()
+
+ if 'doc' in op:
+ doc_lines = op['doc'].strip().split('\n')
+ for line in doc_lines:
+ cw.p(f'/// {line.strip()}')
+
+ cw.block_start(f'pub struct {struct_name}')
+ cw.p('skb: kernel::netlink::GenlMsg,')
+ cw.block_end()
+ cw.nl()
+
+ cw.block_start(f'impl {struct_name}')
+ cw.p('/// Create a new multicast message.')
+ cw.p('pub fn new(')
+ cw._ind += 1
+ cw.p('size: usize,')
+ cw.p('portid: u32,')
+ cw.p('seq: u32,')
+ cw.p('flags: kernel::alloc::Flags,')
+ cw._ind -= 1
+ cw.block_start(') -> Result<Self, kernel::alloc::AllocError>')
+ cw.p(f'const {op.enum_name}: u8 = kernel::uapi::{op.enum_name} as u8;')
+ cw.p('let skb = kernel::netlink::SkBuff::new(size, flags)?;')
+ cw.p(f'let skb = skb.genlmsg_put(portid, seq, &{family_name}, {op.enum_name})?;')
+ cw.p('Ok(Self { skb })')
+ cw.block_end()
+ cw.nl()
+
+ cw.p('/// Broadcast this message.')
+ cw.block_start('pub fn multicast(self, portid: u32, flags: kernel::alloc::Flags) -> Result')
+ cw.p(f'self.skb.multicast(&{family_name}, portid, {idx}, flags)')
+ cw.block_end()
+ cw.nl()
+
+ cw.p('/// Check if this message type has listeners.')
+ cw.block_start('pub fn has_listeners() -> bool')
+ cw.p(f'{family_name}.has_listeners({idx})')
+ cw.block_end()
+
+ attr_set_name = op['attribute-set']
+ attr_set = family.attr_sets[attr_set_name]
+ event_attrs = op['event']['attributes']
+
+ for attr_name in event_attrs:
+ attr = attr_set[attr_name]
+ method_name = attr_name.replace('-', '_')
+
+ if attr.type == 'u32':
+ put_fn = 'put_u32'
+ arg_str = ', val'
+ method_args = '(&mut self, val: u32)'
+ elif attr.type == 'string':
+ put_fn = 'put_string'
+ arg_str = ', val'
+ method_args = '(&mut self, val: &CStr)'
+ elif attr.type == 'flag':
+ put_fn = 'put_flag'
+ arg_str = ''
+ method_args = '(&mut self)'
+ else:
+ put_fn = 'put_u32'
+ arg_str = ', val'
+ method_args = f'(&mut self, val: {attr.type})'
+
+ cw.nl()
+ if 'doc' in attr.yaml:
+ doc_lines = attr.yaml['doc'].strip().split('\n')
+ for line in doc_lines:
+ cw.p(f'/// {line.strip()}')
+
+ cw.block_start(f'pub fn {method_name}{method_args} -> Result')
+ cw.p(f'const {attr.enum_name}: c_int = kernel::uapi::{attr.enum_name} as c_int;')
+ cw.p(f'self.skb.{put_fn}({attr.enum_name}{arg_str})')
+ cw.block_end()
+
+ cw.block_end()
+ cw.nl()
+ cw.p(' ')
+
+
def main():
parser = argparse.ArgumentParser(description='Netlink simple parsing generator')
parser.add_argument('--mode', dest='mode', type=str, required=True,
- choices=('user', 'kernel', 'uapi'))
+ choices=('user', 'kernel', 'uapi', 'rust'))
parser.add_argument('--spec', dest='spec', type=str, required=True)
parser.add_argument('--header', dest='header', action='store_true', default=None)
parser.add_argument('--source', dest='header', action='store_false')
@@ -3471,6 +3594,13 @@ def main():
render_uapi(parsed, cw)
return
+ if args.mode == 'rust':
+ render_rust(parsed, cw)
+ cw.close_out_file()
+ if args.out_file:
+ subprocess.run(['rustfmt', '--edition', '2021', args.out_file])
+ return
+
hdr_prot = f"_LINUX_{parsed.c_name.upper()}_GEN_H"
if args.header:
cw.p('#ifndef ' + hdr_prot)
diff --git a/tools/net/ynl/ynl-regen.sh b/tools/net/ynl/ynl-regen.sh
index d9809276db98..4f5ceb4fe147 100755
--- a/tools/net/ynl/ynl-regen.sh
+++ b/tools/net/ynl/ynl-regen.sh
@@ -17,7 +17,7 @@ done
KDIR=$(dirname $(dirname $(dirname $(dirname $(realpath $0)))))
pushd ${search:-$KDIR} >>/dev/null
-files=$(git grep --files-with-matches '^/\* YNL-GEN \(kernel\|uapi\|user\)')
+files=$(git grep --files-with-matches '^/\* YNL-GEN \(kernel\|uapi\|user\|rust\)')
for f in $files; do
# params: 0 1 2 3
# $YAML YNL-GEN kernel $mode
--
2.53.0.473.g4a7958ca14-goog
^ permalink raw reply related [flat|nested] 26+ messages in thread* Re: [PATCH 2/4] ynl_gen: generate Rust files from yaml files
2026-03-06 15:12 ` [PATCH 2/4] ynl_gen: generate Rust files from yaml files Alice Ryhl
@ 2026-03-07 18:41 ` Jakub Kicinski
2026-03-07 21:30 ` Alice Ryhl
0 siblings, 1 reply; 26+ messages in thread
From: Jakub Kicinski @ 2026-03-07 18:41 UTC (permalink / raw)
To: Alice Ryhl
Cc: Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Trevor Gross, Danilo Krummrich,
Donald Hunter, David S. Miller, Eric Dumazet, Paolo Abeni,
Simon Horman, Greg Kroah-Hartman, Arve Hjønnevåg,
Todd Kjos, Christian Brauner, Carlos Llamas, linux-kernel,
rust-for-linux, netdev
On Fri, 06 Mar 2026 15:12:14 +0000 Alice Ryhl wrote:
> +++ b/tools/net/ynl/pyynl/ynl_gen_c.py
The name of the file says gen_c ...
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH 2/4] ynl_gen: generate Rust files from yaml files
2026-03-07 18:41 ` Jakub Kicinski
@ 2026-03-07 21:30 ` Alice Ryhl
0 siblings, 0 replies; 26+ messages in thread
From: Alice Ryhl @ 2026-03-07 21:30 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Trevor Gross, Danilo Krummrich,
Donald Hunter, David S. Miller, Eric Dumazet, Paolo Abeni,
Simon Horman, Greg Kroah-Hartman, Arve Hjønnevåg,
Todd Kjos, Christian Brauner, Carlos Llamas, linux-kernel,
rust-for-linux, netdev
On Sat, Mar 07, 2026 at 10:41:55AM -0800, Jakub Kicinski wrote:
> On Fri, 06 Mar 2026 15:12:14 +0000 Alice Ryhl wrote:
> > +++ b/tools/net/ynl/pyynl/ynl_gen_c.py
>
> The name of the file says gen_c ...
I see there is also an ynl_gen_rst.py file in the same directory. Are
you suggesting that I create a ynl_gen_rust.py file instead?
Alice
^ permalink raw reply [flat|nested] 26+ messages in thread
* [PATCH 3/4] rust_binder: add generated netlink.rs file
2026-03-06 15:12 [PATCH 0/4] Rust netlink support + use in Rust Binder Alice Ryhl
2026-03-06 15:12 ` [PATCH 1/4] rust: netlink: add raw netlink abstraction Alice Ryhl
2026-03-06 15:12 ` [PATCH 2/4] ynl_gen: generate Rust files from yaml files Alice Ryhl
@ 2026-03-06 15:12 ` Alice Ryhl
2026-03-16 12:07 ` Andreas Hindborg
2026-03-06 15:12 ` [PATCH 4/4] rust_binder: report netlink transactions Alice Ryhl
2026-03-07 18:41 ` [PATCH 0/4] Rust netlink support + use in Rust Binder Jakub Kicinski
4 siblings, 1 reply; 26+ messages in thread
From: Alice Ryhl @ 2026-03-06 15:12 UTC (permalink / raw)
To: Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Trevor Gross, Danilo Krummrich,
Donald Hunter, Jakub Kicinski, David S. Miller, Eric Dumazet,
Paolo Abeni, Simon Horman, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas
Cc: linux-kernel, rust-for-linux, netdev, Alice Ryhl
To use netlink from Rust Binder, add a new generated netlink file using
the new script and Documentation/netlink/specs/binder.yaml.
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
---
drivers/android/Kconfig | 2 +-
drivers/android/binder/netlink.rs | 113 +++++++++++++++++++++++++++++
drivers/android/binder/rust_binder_main.rs | 9 ++-
rust/uapi/uapi_helper.h | 1 +
4 files changed, 122 insertions(+), 3 deletions(-)
diff --git a/drivers/android/Kconfig b/drivers/android/Kconfig
index e2e402c9d175..606a9d07f774 100644
--- a/drivers/android/Kconfig
+++ b/drivers/android/Kconfig
@@ -16,7 +16,7 @@ config ANDROID_BINDER_IPC
config ANDROID_BINDER_IPC_RUST
bool "Rust version of Android Binder IPC Driver"
- depends on RUST && MMU && !ANDROID_BINDER_IPC
+ depends on RUST && MMU && NET && !ANDROID_BINDER_IPC
help
This enables the Rust implementation of the Binder driver.
diff --git a/drivers/android/binder/netlink.rs b/drivers/android/binder/netlink.rs
new file mode 100644
index 000000000000..0537be08f4d5
--- /dev/null
+++ b/drivers/android/binder/netlink.rs
@@ -0,0 +1,113 @@
+// SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)
+/* Do not edit directly, auto-generated from: */
+/* Documentation/netlink/specs/binder.yaml */
+/* YNL-GEN rust source */
+/* To regenerate run: tools/net/ynl/ynl-regen.sh */
+
+#![allow(unreachable_pub, clippy::wrong_self_convention)]
+use kernel::netlink::{Family, MulticastGroup};
+use kernel::prelude::*;
+
+pub static BINDER_NL_FAMILY: Family = Family::const_new(
+ &crate::THIS_MODULE,
+ kernel::uapi::BINDER_FAMILY_NAME,
+ kernel::uapi::BINDER_FAMILY_VERSION,
+ &BINDER_NL_FAMILY_MCGRPS,
+);
+
+static BINDER_NL_FAMILY_MCGRPS: [MulticastGroup; 1] = [MulticastGroup::const_new(c"report")];
+
+/// A multicast event sent to userspace subscribers to notify them about
+/// binder transaction failures. The generated report provides the full
+/// details of the specific transaction that failed. The intention is for
+/// programs to monitor these events and react to the failures as needed.
+pub struct Report {
+ skb: kernel::netlink::GenlMsg,
+}
+
+impl Report {
+ /// Create a new multicast message.
+ pub fn new(
+ size: usize,
+ portid: u32,
+ seq: u32,
+ flags: kernel::alloc::Flags,
+ ) -> Result<Self, kernel::alloc::AllocError> {
+ const BINDER_CMD_REPORT: u8 = kernel::uapi::BINDER_CMD_REPORT as u8;
+ let skb = kernel::netlink::SkBuff::new(size, flags)?;
+ let skb = skb.genlmsg_put(portid, seq, &BINDER_NL_FAMILY, BINDER_CMD_REPORT)?;
+ Ok(Self { skb })
+ }
+
+ /// Broadcast this message.
+ pub fn multicast(self, portid: u32, flags: kernel::alloc::Flags) -> Result {
+ self.skb.multicast(&BINDER_NL_FAMILY, portid, 0, flags)
+ }
+
+ /// Check if this message type has listeners.
+ pub fn has_listeners() -> bool {
+ BINDER_NL_FAMILY.has_listeners(0)
+ }
+
+ /// The enum binder_driver_return_protocol returned to the sender.
+ pub fn error(&mut self, val: u32) -> Result {
+ const BINDER_A_REPORT_ERROR: c_int = kernel::uapi::BINDER_A_REPORT_ERROR as c_int;
+ self.skb.put_u32(BINDER_A_REPORT_ERROR, val)
+ }
+
+ /// The binder context where the transaction occurred.
+ pub fn context(&mut self, val: &CStr) -> Result {
+ const BINDER_A_REPORT_CONTEXT: c_int = kernel::uapi::BINDER_A_REPORT_CONTEXT as c_int;
+ self.skb.put_string(BINDER_A_REPORT_CONTEXT, val)
+ }
+
+ /// The PID of the sender process.
+ pub fn from_pid(&mut self, val: u32) -> Result {
+ const BINDER_A_REPORT_FROM_PID: c_int = kernel::uapi::BINDER_A_REPORT_FROM_PID as c_int;
+ self.skb.put_u32(BINDER_A_REPORT_FROM_PID, val)
+ }
+
+ /// The TID of the sender thread.
+ pub fn from_tid(&mut self, val: u32) -> Result {
+ const BINDER_A_REPORT_FROM_TID: c_int = kernel::uapi::BINDER_A_REPORT_FROM_TID as c_int;
+ self.skb.put_u32(BINDER_A_REPORT_FROM_TID, val)
+ }
+
+ /// The PID of the recipient process. This attribute may not be present
+ /// if the target could not be determined.
+ pub fn to_pid(&mut self, val: u32) -> Result {
+ const BINDER_A_REPORT_TO_PID: c_int = kernel::uapi::BINDER_A_REPORT_TO_PID as c_int;
+ self.skb.put_u32(BINDER_A_REPORT_TO_PID, val)
+ }
+
+ /// The TID of the recipient thread. This attribute may not be present
+ /// if the target could not be determined.
+ pub fn to_tid(&mut self, val: u32) -> Result {
+ const BINDER_A_REPORT_TO_TID: c_int = kernel::uapi::BINDER_A_REPORT_TO_TID as c_int;
+ self.skb.put_u32(BINDER_A_REPORT_TO_TID, val)
+ }
+
+ /// When present, indicates the failed transaction is a reply.
+ pub fn is_reply(&mut self) -> Result {
+ const BINDER_A_REPORT_IS_REPLY: c_int = kernel::uapi::BINDER_A_REPORT_IS_REPLY as c_int;
+ self.skb.put_flag(BINDER_A_REPORT_IS_REPLY)
+ }
+
+ /// The bitmask of enum transaction_flags from the transaction.
+ pub fn flags(&mut self, val: u32) -> Result {
+ const BINDER_A_REPORT_FLAGS: c_int = kernel::uapi::BINDER_A_REPORT_FLAGS as c_int;
+ self.skb.put_u32(BINDER_A_REPORT_FLAGS, val)
+ }
+
+ /// The application-defined code from the transaction.
+ pub fn code(&mut self, val: u32) -> Result {
+ const BINDER_A_REPORT_CODE: c_int = kernel::uapi::BINDER_A_REPORT_CODE as c_int;
+ self.skb.put_u32(BINDER_A_REPORT_CODE, val)
+ }
+
+ /// The transaction payload size in bytes.
+ pub fn data_size(&mut self, val: u32) -> Result {
+ const BINDER_A_REPORT_DATA_SIZE: c_int = kernel::uapi::BINDER_A_REPORT_DATA_SIZE as c_int;
+ self.skb.put_u32(BINDER_A_REPORT_DATA_SIZE, val)
+ }
+}
diff --git a/drivers/android/binder/rust_binder_main.rs b/drivers/android/binder/rust_binder_main.rs
index aa5f2a75adb4..65dae8931676 100644
--- a/drivers/android/binder/rust_binder_main.rs
+++ b/drivers/android/binder/rust_binder_main.rs
@@ -36,6 +36,8 @@
mod deferred_close;
mod defs;
mod error;
+#[allow(dead_code)]
+mod netlink;
mod node;
mod page_range;
mod process;
@@ -285,7 +287,9 @@ fn ptr_align(value: usize) -> Option<usize> {
// SAFETY: We call register in `init`.
static BINDER_SHRINKER: Shrinker = unsafe { Shrinker::new() };
-struct BinderModule {}
+struct BinderModule {
+ _netlink: kernel::netlink::Registration,
+}
impl kernel::Module for BinderModule {
fn init(_module: &'static kernel::ThisModule) -> Result<Self> {
@@ -294,12 +298,13 @@ fn init(_module: &'static kernel::ThisModule) -> Result<Self> {
pr_warn!("Loaded Rust Binder.");
+ let netlink = crate::netlink::BINDER_NL_FAMILY.register()?;
BINDER_SHRINKER.register(c"android-binder")?;
// SAFETY: The module is being loaded, so we can initialize binderfs.
unsafe { kernel::error::to_result(binderfs::init_rust_binderfs())? };
- Ok(Self {})
+ Ok(Self { _netlink: netlink })
}
}
diff --git a/rust/uapi/uapi_helper.h b/rust/uapi/uapi_helper.h
index 06d7d1a2e8da..86c7b6b284b0 100644
--- a/rust/uapi/uapi_helper.h
+++ b/rust/uapi/uapi_helper.h
@@ -11,6 +11,7 @@
#include <uapi/drm/nova_drm.h>
#include <uapi/drm/panthor_drm.h>
#include <uapi/linux/android/binder.h>
+#include <uapi/linux/android/binder_netlink.h>
#include <uapi/linux/mdio.h>
#include <uapi/linux/mii.h>
#include <uapi/linux/ethtool.h>
--
2.53.0.473.g4a7958ca14-goog
^ permalink raw reply related [flat|nested] 26+ messages in thread* Re: [PATCH 3/4] rust_binder: add generated netlink.rs file
2026-03-06 15:12 ` [PATCH 3/4] rust_binder: add generated netlink.rs file Alice Ryhl
@ 2026-03-16 12:07 ` Andreas Hindborg
0 siblings, 0 replies; 26+ messages in thread
From: Andreas Hindborg @ 2026-03-16 12:07 UTC (permalink / raw)
To: Alice Ryhl, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Trevor Gross,
Danilo Krummrich, Donald Hunter, Jakub Kicinski, David S. Miller,
Eric Dumazet, Paolo Abeni, Simon Horman, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas
Cc: linux-kernel, rust-for-linux, netdev, Alice Ryhl
"Alice Ryhl" <aliceryhl@google.com> writes:
> To use netlink from Rust Binder, add a new generated netlink file using
> the new script and Documentation/netlink/specs/binder.yaml.
>
> Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Does this have to be in tree? Can't we run the generator during build?
Best regards,
Andreas Hindborg
^ permalink raw reply [flat|nested] 26+ messages in thread
* [PATCH 4/4] rust_binder: report netlink transactions
2026-03-06 15:12 [PATCH 0/4] Rust netlink support + use in Rust Binder Alice Ryhl
` (2 preceding siblings ...)
2026-03-06 15:12 ` [PATCH 3/4] rust_binder: add generated netlink.rs file Alice Ryhl
@ 2026-03-06 15:12 ` Alice Ryhl
2026-03-07 16:56 ` Andrew Lunn
2026-03-07 18:41 ` [PATCH 0/4] Rust netlink support + use in Rust Binder Jakub Kicinski
4 siblings, 1 reply; 26+ messages in thread
From: Alice Ryhl @ 2026-03-06 15:12 UTC (permalink / raw)
To: Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Trevor Gross, Danilo Krummrich,
Donald Hunter, Jakub Kicinski, David S. Miller, Eric Dumazet,
Paolo Abeni, Simon Horman, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas
Cc: linux-kernel, rust-for-linux, netdev, Alice Ryhl
From: Carlos Llamas <cmllamas@google.com>
The Android Binder driver supports a netlink API that reports
transaction *failures* to a userapce daemon. This allows devices to
monitor processes with many failed transactions so that it can e.g. kill
misbehaving apps.
One very important thing that this monitors is when many oneway messages
are sent to a frozen process, so there is special handling to ensure
this scenario is surfaced over netlink.
Signed-off-by: Carlos Llamas <cmllamas@google.com>
---
drivers/android/binder/rust_binder_main.rs | 1 -
drivers/android/binder/thread.rs | 9 +++++++
drivers/android/binder/transaction.rs | 38 ++++++++++++++++++++++++++++++
3 files changed, 47 insertions(+), 1 deletion(-)
diff --git a/drivers/android/binder/rust_binder_main.rs b/drivers/android/binder/rust_binder_main.rs
index 65dae8931676..f96264406ef3 100644
--- a/drivers/android/binder/rust_binder_main.rs
+++ b/drivers/android/binder/rust_binder_main.rs
@@ -36,7 +36,6 @@
mod deferred_close;
mod defs;
mod error;
-#[allow(dead_code)]
mod netlink;
mod node;
mod page_range;
diff --git a/drivers/android/binder/thread.rs b/drivers/android/binder/thread.rs
index 97a5e4acf64c..49879e615ce5 100644
--- a/drivers/android/binder/thread.rs
+++ b/drivers/android/binder/thread.rs
@@ -1262,6 +1262,15 @@ fn transaction(self: &Arc<Self>, cmd: u32, reader: &mut UserSliceReader) -> Resu
}
}
+ if info.oneway_spam_suspect {
+ // If this is both a oneway spam suspect and a failure, we report it twice. This is
+ // useful in case the transaction failed with BR_TRANSACTION_PENDING_FROZEN.
+ info.report_netlink(BR_ONEWAY_SPAM_SUSPECT, &self.process.ctx);
+ }
+ if info.reply != 0 {
+ info.report_netlink(info.reply, &self.process.ctx);
+ }
+
Ok(())
}
diff --git a/drivers/android/binder/transaction.rs b/drivers/android/binder/transaction.rs
index 5dff3d655c4d..4b3fba76114a 100644
--- a/drivers/android/binder/transaction.rs
+++ b/drivers/android/binder/transaction.rs
@@ -3,6 +3,7 @@
// Copyright (C) 2025 Google LLC.
use kernel::{
+ netlink::GENLMSG_DEFAULT_SIZE,
prelude::*,
seq_file::SeqFile,
seq_print,
@@ -17,6 +18,7 @@
allocation::{Allocation, TranslatedFds},
defs::*,
error::{BinderError, BinderResult},
+ netlink::Report,
node::{Node, NodeRef},
process::{Process, ProcessInner},
ptr_align,
@@ -49,6 +51,42 @@ impl TransactionInfo {
pub(crate) fn is_oneway(&self) -> bool {
self.flags & TF_ONE_WAY != 0
}
+
+ pub(crate) fn report_netlink(&self, reply: u32, ctx: &crate::Context) {
+ if let Err(err) = self.report_netlink_inner(reply, ctx) {
+ pr_warn!(
+ "{}:{} netlink report failed: {err:?}\n",
+ self.from_pid,
+ self.from_tid
+ );
+ }
+ }
+
+ fn report_netlink_inner(&self, reply: u32, ctx: &crate::Context) -> kernel::error::Result {
+ if !Report::has_listeners() {
+ return Ok(());
+ }
+ let mut report = Report::new(GENLMSG_DEFAULT_SIZE, 0, 0, GFP_KERNEL)?;
+
+ report.error(reply)?;
+ report.context(&ctx.name)?;
+ report.from_pid(self.from_pid as u32)?;
+ report.from_tid(self.from_tid as u32)?;
+ report.to_pid(self.to_pid as u32)?;
+ if self.to_tid != 0 {
+ report.to_tid(self.to_tid as u32)?;
+ }
+
+ if self.is_reply {
+ report.is_reply()?;
+ }
+ report.flags(self.flags)?;
+ report.code(self.code)?;
+ report.data_size(self.data_size as u32)?;
+
+ report.multicast(0, GFP_KERNEL)?;
+ Ok(())
+ }
}
use core::mem::offset_of;
--
2.53.0.473.g4a7958ca14-goog
^ permalink raw reply related [flat|nested] 26+ messages in thread* Re: [PATCH 4/4] rust_binder: report netlink transactions
2026-03-06 15:12 ` [PATCH 4/4] rust_binder: report netlink transactions Alice Ryhl
@ 2026-03-07 16:56 ` Andrew Lunn
2026-03-07 21:19 ` Alice Ryhl
0 siblings, 1 reply; 26+ messages in thread
From: Andrew Lunn @ 2026-03-07 16:56 UTC (permalink / raw)
To: Alice Ryhl
Cc: Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Trevor Gross, Danilo Krummrich,
Donald Hunter, Jakub Kicinski, David S. Miller, Eric Dumazet,
Paolo Abeni, Simon Horman, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, linux-kernel, rust-for-linux, netdev
On Fri, Mar 06, 2026 at 03:12:16PM +0000, Alice Ryhl wrote:
> From: Carlos Llamas <cmllamas@google.com>
>
> The Android Binder driver supports a netlink API that reports
> transaction *failures* to a userapce daemon. This allows devices to
> monitor processes with many failed transactions so that it can e.g. kill
> misbehaving apps.
>
> One very important thing that this monitors is when many oneway messages
> are sent to a frozen process, so there is special handling to ensure
> this scenario is surfaced over netlink.
>
> Signed-off-by: Carlos Llamas <cmllamas@google.com>
Hi Alice
Since you are submitting this it needs your Signed-off-by as well.
Andrew
---
pw-bot: cr
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [PATCH 4/4] rust_binder: report netlink transactions
2026-03-07 16:56 ` Andrew Lunn
@ 2026-03-07 21:19 ` Alice Ryhl
0 siblings, 0 replies; 26+ messages in thread
From: Alice Ryhl @ 2026-03-07 21:19 UTC (permalink / raw)
To: Andrew Lunn
Cc: Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Trevor Gross, Danilo Krummrich,
Donald Hunter, Jakub Kicinski, David S. Miller, Eric Dumazet,
Paolo Abeni, Simon Horman, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, linux-kernel, rust-for-linux, netdev
On Sat, Mar 07, 2026 at 05:56:45PM +0100, Andrew Lunn wrote:
> On Fri, Mar 06, 2026 at 03:12:16PM +0000, Alice Ryhl wrote:
> > From: Carlos Llamas <cmllamas@google.com>
> >
> > The Android Binder driver supports a netlink API that reports
> > transaction *failures* to a userapce daemon. This allows devices to
> > monitor processes with many failed transactions so that it can e.g. kill
> > misbehaving apps.
> >
> > One very important thing that this monitors is when many oneway messages
> > are sent to a frozen process, so there is special handling to ensure
> > this scenario is surfaced over netlink.
> >
> > Signed-off-by: Carlos Llamas <cmllamas@google.com>
>
> Hi Alice
>
> Since you are submitting this it needs your Signed-off-by as well.
Oh I forgot to update this, thanks for reminding me!
Alice
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH 0/4] Rust netlink support + use in Rust Binder
2026-03-06 15:12 [PATCH 0/4] Rust netlink support + use in Rust Binder Alice Ryhl
` (3 preceding siblings ...)
2026-03-06 15:12 ` [PATCH 4/4] rust_binder: report netlink transactions Alice Ryhl
@ 2026-03-07 18:41 ` Jakub Kicinski
2026-03-07 21:19 ` Alice Ryhl
4 siblings, 1 reply; 26+ messages in thread
From: Jakub Kicinski @ 2026-03-07 18:41 UTC (permalink / raw)
To: Alice Ryhl
Cc: Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Trevor Gross, Danilo Krummrich,
Donald Hunter, David S. Miller, Eric Dumazet, Paolo Abeni,
Simon Horman, Greg Kroah-Hartman, Arve Hjønnevåg,
Todd Kjos, Christian Brauner, Carlos Llamas, linux-kernel,
rust-for-linux, netdev
On Fri, 06 Mar 2026 15:12:12 +0000 Alice Ryhl wrote:
> The C Binder driver exposes messages over netlink when transactions
> fail, so that a userpace daemon can respond to processes with many
> failing transactions.
Ugh, now I regret letting binder use Netlink. Should have seen this
coming :/
> This patch series adds netlink support from Rust, then implements an
> equivalent API in Rust Binder.
>
> As Binder only uses broadcast messages, I did not add support for other
> kinds of messages.
Please no duplication of existing code in Rust.
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [PATCH 0/4] Rust netlink support + use in Rust Binder
2026-03-07 18:41 ` [PATCH 0/4] Rust netlink support + use in Rust Binder Jakub Kicinski
@ 2026-03-07 21:19 ` Alice Ryhl
2026-03-07 21:39 ` Andrew Lunn
2026-03-07 21:59 ` Jakub Kicinski
0 siblings, 2 replies; 26+ messages in thread
From: Alice Ryhl @ 2026-03-07 21:19 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Trevor Gross, Danilo Krummrich,
Donald Hunter, David S. Miller, Eric Dumazet, Paolo Abeni,
Simon Horman, Greg Kroah-Hartman, Arve Hjønnevåg,
Todd Kjos, Christian Brauner, Carlos Llamas, linux-kernel,
rust-for-linux, netdev
On Sat, Mar 07, 2026 at 10:41:31AM -0800, Jakub Kicinski wrote:
> On Fri, 06 Mar 2026 15:12:12 +0000 Alice Ryhl wrote:
> > The C Binder driver exposes messages over netlink when transactions
> > fail, so that a userpace daemon can respond to processes with many
> > failing transactions.
>
> Ugh, now I regret letting binder use Netlink. Should have seen this
> coming :/
To be honest, I'm not entirely happy with what Binder is using netlink
for either, but it is what it is.
> > This patch series adds netlink support from Rust, then implements an
> > equivalent API in Rust Binder.
> >
> > As Binder only uses broadcast messages, I did not add support for other
> > kinds of messages.
>
> Please no duplication of existing code in Rust.
The plan is certainly to get rid of C Binder, but it was unfortunately
not possible to get there without a transition period.
Alice
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH 0/4] Rust netlink support + use in Rust Binder
2026-03-07 21:19 ` Alice Ryhl
@ 2026-03-07 21:39 ` Andrew Lunn
2026-03-07 22:41 ` Alice Ryhl
2026-03-07 21:59 ` Jakub Kicinski
1 sibling, 1 reply; 26+ messages in thread
From: Andrew Lunn @ 2026-03-07 21:39 UTC (permalink / raw)
To: Alice Ryhl
Cc: Jakub Kicinski, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Trevor Gross, Danilo Krummrich, Donald Hunter, David S. Miller,
Eric Dumazet, Paolo Abeni, Simon Horman, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, linux-kernel, rust-for-linux, netdev
> > Please no duplication of existing code in Rust.
>
> The plan is certainly to get rid of C Binder, but it was unfortunately
> not possible to get there without a transition period.
Dumb question....
Why?
You are just sending messages to user space. Does the rust version
send different messages? Can user space tell the difference?
Andrew
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [PATCH 0/4] Rust netlink support + use in Rust Binder
2026-03-07 21:39 ` Andrew Lunn
@ 2026-03-07 22:41 ` Alice Ryhl
2026-03-08 14:12 ` Andrew Lunn
0 siblings, 1 reply; 26+ messages in thread
From: Alice Ryhl @ 2026-03-07 22:41 UTC (permalink / raw)
To: Andrew Lunn
Cc: Jakub Kicinski, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Trevor Gross, Danilo Krummrich, Donald Hunter, David S. Miller,
Eric Dumazet, Paolo Abeni, Simon Horman, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, linux-kernel, rust-for-linux, netdev
On Sat, Mar 07, 2026 at 10:39:28PM +0100, Andrew Lunn wrote:
> > > Please no duplication of existing code in Rust.
> >
> > The plan is certainly to get rid of C Binder, but it was unfortunately
> > not possible to get there without a transition period.
>
> Dumb question....
>
> Why?
The reasons for moving to a Rust implementation are discussed in the
cover letter [1], and in my 2023 plumbers talk [2].
[1]: https://lore.kernel.org/all/20231101-rust-binder-v1-0-08ba9197f637@google.com/
[2]: https://www.youtube.com/watch?v=Kt3hpvMZv8o
> You are just sending messages to user space. Does the rust version
> send different messages? Can user space tell the difference?
No, it sends the same messages. The intent is for Android to move to the
Rust implementation without userspace being able to tell the difference.
Alice
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH 0/4] Rust netlink support + use in Rust Binder
2026-03-07 22:41 ` Alice Ryhl
@ 2026-03-08 14:12 ` Andrew Lunn
2026-03-08 15:08 ` Alice Ryhl
0 siblings, 1 reply; 26+ messages in thread
From: Andrew Lunn @ 2026-03-08 14:12 UTC (permalink / raw)
To: Alice Ryhl
Cc: Jakub Kicinski, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Trevor Gross, Danilo Krummrich, Donald Hunter, David S. Miller,
Eric Dumazet, Paolo Abeni, Simon Horman, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, linux-kernel, rust-for-linux, netdev
On Sat, Mar 07, 2026 at 10:41:09PM +0000, Alice Ryhl wrote:
> On Sat, Mar 07, 2026 at 10:39:28PM +0100, Andrew Lunn wrote:
> > > > Please no duplication of existing code in Rust.
> > >
> > > The plan is certainly to get rid of C Binder, but it was unfortunately
> > > not possible to get there without a transition period.
> >
> > Dumb question....
> >
> > Why?
>
> The reasons for moving to a Rust implementation are discussed in the
> cover letter [1], and in my 2023 plumbers talk [2].
Ah, so you meant binder itself has be dual implementation for a while.
> No, it sends the same messages. The intent is for Android to move to the
> Rust implementation without userspace being able to tell the difference.
Any reason you cannot use this Rust netlink code with the C binder?
You can then throw away the C netlink code, no code duplication.
Andrew
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH 0/4] Rust netlink support + use in Rust Binder
2026-03-08 14:12 ` Andrew Lunn
@ 2026-03-08 15:08 ` Alice Ryhl
0 siblings, 0 replies; 26+ messages in thread
From: Alice Ryhl @ 2026-03-08 15:08 UTC (permalink / raw)
To: Andrew Lunn
Cc: Jakub Kicinski, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Trevor Gross, Danilo Krummrich, Donald Hunter, David S. Miller,
Eric Dumazet, Paolo Abeni, Simon Horman, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, linux-kernel, rust-for-linux, netdev
On Sun, Mar 08, 2026 at 03:12:55PM +0100, Andrew Lunn wrote:
> On Sat, Mar 07, 2026 at 10:41:09PM +0000, Alice Ryhl wrote:
> > On Sat, Mar 07, 2026 at 10:39:28PM +0100, Andrew Lunn wrote:
> > > > > Please no duplication of existing code in Rust.
> > > >
> > > > The plan is certainly to get rid of C Binder, but it was unfortunately
> > > > not possible to get there without a transition period.
> > >
> > > Dumb question....
> > >
> > > Why?
> >
> > The reasons for moving to a Rust implementation are discussed in the
> > cover letter [1], and in my 2023 plumbers talk [2].
>
> Ah, so you meant binder itself has be dual implementation for a while.
Yes, that's right.
> > No, it sends the same messages. The intent is for Android to move to the
> > Rust implementation without userspace being able to tell the difference.
>
> Any reason you cannot use this Rust netlink code with the C binder?
> You can then throw away the C netlink code, no code duplication.
I think the benefit from that would be quite little. It would probably
not have helped avoid commit 5e8a3d015442 ("binder: fix UAF in
binder_netlink_report()") because that was a bug in the caller of
binder_netlink_report(), rather than a bug in the function itself.
And as for the benefit from avoiding duplication on its own, Binder's
netlink logic is very small to begin with, so I do not think that's
worth it either. It'll go away eventually when the entire C driver is
deleted.
Alice
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH 0/4] Rust netlink support + use in Rust Binder
2026-03-07 21:19 ` Alice Ryhl
2026-03-07 21:39 ` Andrew Lunn
@ 2026-03-07 21:59 ` Jakub Kicinski
2026-03-07 22:50 ` Alice Ryhl
1 sibling, 1 reply; 26+ messages in thread
From: Jakub Kicinski @ 2026-03-07 21:59 UTC (permalink / raw)
To: Alice Ryhl
Cc: Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Trevor Gross, Danilo Krummrich,
Donald Hunter, David S. Miller, Eric Dumazet, Paolo Abeni,
Simon Horman, Greg Kroah-Hartman, Arve Hjønnevåg,
Todd Kjos, Christian Brauner, Carlos Llamas, linux-kernel,
rust-for-linux, netdev
On Sat, 7 Mar 2026 21:19:06 +0000 Alice Ryhl wrote:
> On Sat, Mar 07, 2026 at 10:41:31AM -0800, Jakub Kicinski wrote:
> > On Fri, 06 Mar 2026 15:12:12 +0000 Alice Ryhl wrote:
> > > The C Binder driver exposes messages over netlink when transactions
> > > fail, so that a userpace daemon can respond to processes with many
> > > failing transactions.
> >
> > Ugh, now I regret letting binder use Netlink. Should have seen this
> > coming :/
>
> To be honest, I'm not entirely happy with what Binder is using netlink
> for either, but it is what it is.
If we're both not happy let's take this opportunity to find a better
solution?
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH 0/4] Rust netlink support + use in Rust Binder
2026-03-07 21:59 ` Jakub Kicinski
@ 2026-03-07 22:50 ` Alice Ryhl
2026-03-09 21:24 ` Jakub Kicinski
0 siblings, 1 reply; 26+ messages in thread
From: Alice Ryhl @ 2026-03-07 22:50 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Trevor Gross, Danilo Krummrich,
Donald Hunter, David S. Miller, Eric Dumazet, Paolo Abeni,
Simon Horman, Greg Kroah-Hartman, Arve Hjønnevåg,
Todd Kjos, Christian Brauner, Carlos Llamas, linux-kernel,
rust-for-linux, netdev
On Sat, Mar 07, 2026 at 01:59:41PM -0800, Jakub Kicinski wrote:
> On Sat, 7 Mar 2026 21:19:06 +0000 Alice Ryhl wrote:
> > On Sat, Mar 07, 2026 at 10:41:31AM -0800, Jakub Kicinski wrote:
> > > On Fri, 06 Mar 2026 15:12:12 +0000 Alice Ryhl wrote:
> > > > The C Binder driver exposes messages over netlink when transactions
> > > > fail, so that a userpace daemon can respond to processes with many
> > > > failing transactions.
> > >
> > > Ugh, now I regret letting binder use Netlink. Should have seen this
> > > coming :/
> >
> > To be honest, I'm not entirely happy with what Binder is using netlink
> > for either, but it is what it is.
>
> If we're both not happy let's take this opportunity to find a better
> solution?
My understanding is that userspace is already using or looking into
using the netlink uapi that Binder exposes here. I don't know to what
extent; it's not used *that* much yet, but it may still be tricky to
change the uapi at this point.
Alice
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH 0/4] Rust netlink support + use in Rust Binder
2026-03-07 22:50 ` Alice Ryhl
@ 2026-03-09 21:24 ` Jakub Kicinski
2026-03-10 7:47 ` Alice Ryhl
0 siblings, 1 reply; 26+ messages in thread
From: Jakub Kicinski @ 2026-03-09 21:24 UTC (permalink / raw)
To: Alice Ryhl
Cc: Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Trevor Gross, Danilo Krummrich,
Donald Hunter, David S. Miller, Eric Dumazet, Paolo Abeni,
Simon Horman, Greg Kroah-Hartman, Arve Hjønnevåg,
Todd Kjos, Christian Brauner, Carlos Llamas, linux-kernel,
rust-for-linux, netdev
On Sat, 7 Mar 2026 22:50:31 +0000 Alice Ryhl wrote:
> > > To be honest, I'm not entirely happy with what Binder is using netlink
> > > for either, but it is what it is.
> >
> > If we're both not happy let's take this opportunity to find a better
> > solution?
>
> My understanding is that userspace is already using or looking into
> using the netlink uapi that Binder exposes here. I don't know to what
> extent; it's not used *that* much yet, but it may still be tricky to
> change the uapi at this point.
Let's explore it? What user space components would need to be updated?
What's a better design?
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH 0/4] Rust netlink support + use in Rust Binder
2026-03-09 21:24 ` Jakub Kicinski
@ 2026-03-10 7:47 ` Alice Ryhl
0 siblings, 0 replies; 26+ messages in thread
From: Alice Ryhl @ 2026-03-10 7:47 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Trevor Gross, Danilo Krummrich,
Donald Hunter, David S. Miller, Eric Dumazet, Paolo Abeni,
Simon Horman, Greg Kroah-Hartman, Arve Hjønnevåg,
Todd Kjos, Christian Brauner, Carlos Llamas, linux-kernel,
rust-for-linux, netdev
On Mon, Mar 09, 2026 at 02:24:00PM -0700, Jakub Kicinski wrote:
> On Sat, 7 Mar 2026 22:50:31 +0000 Alice Ryhl wrote:
> > > > To be honest, I'm not entirely happy with what Binder is using netlink
> > > > for either, but it is what it is.
> > >
> > > If we're both not happy let's take this opportunity to find a better
> > > solution?
> >
> > My understanding is that userspace is already using or looking into
> > using the netlink uapi that Binder exposes here. I don't know to what
> > extent; it's not used *that* much yet, but it may still be tricky to
> > change the uapi at this point.
>
> Let's explore it? What user space components would need to be updated?
> What's a better design?
Well ... the thing I'm the most unhappy about is needing to have a
userspace daemon that is notified about all transaction failures to
begin with.
But if you must have such a daemon, I think the netlink based API is
an okay way to do it. You can easily add new fields in the future, and
it implements notifications to userspace on our behalf.
Though using raw pids in the netlink messages is pretty ugly ... pids
can change, and the pid namespace of the receiving proc ends up ignored.
Alice
^ permalink raw reply [flat|nested] 26+ messages in thread