[PATCH] rust: lsm: replace context+len with lsm_context

[PATCH] rust: lsm: replace context+len with lsm_context

[Alice Ryhl]

This brings the Rust SecurityCtx abstraction [1] up to date with the new
API where context+len is replaced with an lsm_context [2] struct.

Link: https://lore.kernel.org/r/20240915-alice-file-v10-5-88484f7a3dcf@google.com [1]
Link: https://lore.kernel.org/r/20241023212158.18718-3-casey@schaufler-ca.com [2]
Reported-by: Linux Kernel Functional Testing <lkft@linaro.org>
Closes: https://lore.kernel.org/r/CA+G9fYv_Y2tzs+uYhMGtfUK9dSYV2mFr6WyKEzJazDsdk9o5zw@mail.gmail.com
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
---
 rust/helpers/security.c |  8 ++++----
 rust/kernel/security.rs | 38 +++++++++++++++++---------------------
 2 files changed, 21 insertions(+), 25 deletions(-)

diff --git a/rust/helpers/security.c b/rust/helpers/security.c
index 239e5b4745fe..0c4c2065df28 100644
--- a/rust/helpers/security.c
+++ b/rust/helpers/security.c
@@ -8,13 +8,13 @@ void rust_helper_security_cred_getsecid(const struct cred *c, u32 *secid)
 	security_cred_getsecid(c, secid);
 }
 
-int rust_helper_security_secid_to_secctx(u32 secid, char **secdata, u32 *seclen)
+int rust_helper_security_secid_to_secctx(u32 secid, struct lsm_context *cp)
 {
-	return security_secid_to_secctx(secid, secdata, seclen);
+	return security_secid_to_secctx(secid, cp);
 }
 
-void rust_helper_security_release_secctx(char *secdata, u32 seclen)
+void rust_helper_security_release_secctx(struct lsm_context *cp)
 {
-	security_release_secctx(secdata, seclen);
+	security_release_secctx(cp);
 }
 #endif
diff --git a/rust/kernel/security.rs b/rust/kernel/security.rs
index 2522868862a1..25d2b1ac3833 100644
--- a/rust/kernel/security.rs
+++ b/rust/kernel/security.rs
@@ -15,60 +15,56 @@
 ///
 /// # Invariants
 ///
-/// The `secdata` and `seclen` fields correspond to a valid security context as returned by a
-/// successful call to `security_secid_to_secctx`, that has not yet been destroyed by calling
-/// `security_release_secctx`.
+/// The `ctx` field corresponds to a valid security context as returned by a successful call to
+/// `security_secid_to_secctx`, that has not yet been destroyed by `security_release_secctx`.
 pub struct SecurityCtx {
-    secdata: *mut core::ffi::c_char,
-    seclen: usize,
+    ctx: bindings::lsm_context,
 }
 
 impl SecurityCtx {
     /// Get the security context given its id.
     pub fn from_secid(secid: u32) -> Result<Self> {
-        let mut secdata = core::ptr::null_mut();
-        let mut seclen = 0u32;
-        // SAFETY: Just a C FFI call. The pointers are valid for writes.
-        to_result(unsafe { bindings::security_secid_to_secctx(secid, &mut secdata, &mut seclen) })?;
+        // SAFETY: `struct lsm_context` can be initialized to all zeros.
+        let mut ctx: bindings::lsm_context = unsafe { core::mem::zeroed() };
+
+        // SAFETY: Just a C FFI call. The pointer is valid for writes.
+        to_result(unsafe { bindings::security_secid_to_secctx(secid, &mut ctx) })?;
 
         // INVARIANT: If the above call did not fail, then we have a valid security context.
-        Ok(Self {
-            secdata,
-            seclen: seclen as usize,
-        })
+        Ok(Self { ctx })
     }
 
     /// Returns whether the security context is empty.
     pub fn is_empty(&self) -> bool {
-        self.seclen == 0
+        self.ctx.len == 0
     }
 
     /// Returns the length of this security context.
     pub fn len(&self) -> usize {
-        self.seclen
+        self.ctx.len as usize
     }
 
     /// Returns the bytes for this security context.
     pub fn as_bytes(&self) -> &[u8] {
-        let ptr = self.secdata;
+        let ptr = self.ctx.context;
         if ptr.is_null() {
-            debug_assert_eq!(self.seclen, 0);
+            debug_assert_eq!(self.len(), 0);
             // We can't pass a null pointer to `slice::from_raw_parts` even if the length is zero.
             return &[];
         }
 
         // SAFETY: The call to `security_secid_to_secctx` guarantees that the pointer is valid for
-        // `seclen` bytes. Furthermore, if the length is zero, then we have ensured that the
+        // `self.len()` bytes. Furthermore, if the length is zero, then we have ensured that the
         // pointer is not null.
-        unsafe { core::slice::from_raw_parts(ptr.cast(), self.seclen) }
+        unsafe { core::slice::from_raw_parts(ptr.cast(), self.len()) }
     }
 }
 
 impl Drop for SecurityCtx {
     fn drop(&mut self) {
-        // SAFETY: By the invariant of `Self`, this frees a pointer that came from a successful
+        // SAFETY: By the invariant of `Self`, this frees a context that came from a successful
         // call to `security_secid_to_secctx` and has not yet been destroyed by
         // `security_release_secctx`.
-        unsafe { bindings::security_release_secctx(self.secdata, self.seclen as u32) };
+        unsafe { bindings::security_release_secctx(&mut self.ctx) };
     }
 }

base-commit: c88416ba074a8913cf6d61b789dd834bbca6681c
-- 
2.47.0.199.ga7371fff76-goog

Re: [PATCH] rust: lsm: replace context+len with lsm_context

[Paul Moore]

On Fri, Nov 1, 2024 at 5:56 AM Alice Ryhl <aliceryhl@google.com> wrote:
>
> This brings the Rust SecurityCtx abstraction [1] up to date with the new
> API where context+len is replaced with an lsm_context [2] struct.
>
> Link: https://lore.kernel.org/r/20240915-alice-file-v10-5-88484f7a3dcf@google.com [1]
> Link: https://lore.kernel.org/r/20241023212158.18718-3-casey@schaufler-ca.com [2]
> Reported-by: Linux Kernel Functional Testing <lkft@linaro.org>
> Closes: https://lore.kernel.org/r/CA+G9fYv_Y2tzs+uYhMGtfUK9dSYV2mFr6WyKEzJazDsdk9o5zw@mail.gmail.com
> Signed-off-by: Alice Ryhl <aliceryhl@google.com>
> ---
>  rust/helpers/security.c |  8 ++++----
>  rust/kernel/security.rs | 38 +++++++++++++++++---------------------
>  2 files changed, 21 insertions(+), 25 deletions(-)

Thanks Alice.  Would you like me to pull this in via the LSM tree with
the associated LSM changes, or would you prefer to do this some other
way?

I'm going to merge this into lsm/dev for now so that we fix the issue
in linux-next, but I'm happy to drop it or do something else, let me
know.

-- 
paul-moore.com

Re: [PATCH] rust: lsm: replace context+len with lsm_context

[Paul Moore]

On Fri, Nov 1, 2024 at 12:56 PM Paul Moore <paul@paul-moore.com> wrote:
> On Fri, Nov 1, 2024 at 5:56 AM Alice Ryhl <aliceryhl@google.com> wrote:
> >
> > This brings the Rust SecurityCtx abstraction [1] up to date with the new
> > API where context+len is replaced with an lsm_context [2] struct.
> >
> > Link: https://lore.kernel.org/r/20240915-alice-file-v10-5-88484f7a3dcf@google.com [1]
> > Link: https://lore.kernel.org/r/20241023212158.18718-3-casey@schaufler-ca.com [2]
> > Reported-by: Linux Kernel Functional Testing <lkft@linaro.org>
> > Closes: https://lore.kernel.org/r/CA+G9fYv_Y2tzs+uYhMGtfUK9dSYV2mFr6WyKEzJazDsdk9o5zw@mail.gmail.com
> > Signed-off-by: Alice Ryhl <aliceryhl@google.com>
> > ---
> >  rust/helpers/security.c |  8 ++++----
> >  rust/kernel/security.rs | 38 +++++++++++++++++---------------------
> >  2 files changed, 21 insertions(+), 25 deletions(-)
>
> Thanks Alice.  Would you like me to pull this in via the LSM tree with
> the associated LSM changes, or would you prefer to do this some other
> way?
>
> I'm going to merge this into lsm/dev for now so that we fix the issue
> in linux-next, but I'm happy to drop it or do something else, let me
> know.

Nevermind, no I'm not, as I don't have the LSM/security rust helpers
in the LSM tree as it looks like those aren't in Linus' tree yet.

-- 
paul-moore.com

Re: [PATCH] rust: lsm: replace context+len with lsm_context

[Paul Moore]

On Fri, Nov 1, 2024 at 1:02 PM Paul Moore <paul@paul-moore.com> wrote:
> On Fri, Nov 1, 2024 at 12:56 PM Paul Moore <paul@paul-moore.com> wrote:
> > On Fri, Nov 1, 2024 at 5:56 AM Alice Ryhl <aliceryhl@google.com> wrote:
> > >
> > > This brings the Rust SecurityCtx abstraction [1] up to date with the new
> > > API where context+len is replaced with an lsm_context [2] struct.
> > >
> > > Link: https://lore.kernel.org/r/20240915-alice-file-v10-5-88484f7a3dcf@google.com [1]
> > > Link: https://lore.kernel.org/r/20241023212158.18718-3-casey@schaufler-ca.com [2]
> > > Reported-by: Linux Kernel Functional Testing <lkft@linaro.org>
> > > Closes: https://lore.kernel.org/r/CA+G9fYv_Y2tzs+uYhMGtfUK9dSYV2mFr6WyKEzJazDsdk9o5zw@mail.gmail.com
> > > Signed-off-by: Alice Ryhl <aliceryhl@google.com>
> > > ---
> > >  rust/helpers/security.c |  8 ++++----
> > >  rust/kernel/security.rs | 38 +++++++++++++++++---------------------
> > >  2 files changed, 21 insertions(+), 25 deletions(-)
> >
> > Thanks Alice.  Would you like me to pull this in via the LSM tree with
> > the associated LSM changes, or would you prefer to do this some other
> > way?
> >
> > I'm going to merge this into lsm/dev for now so that we fix the issue
> > in linux-next, but I'm happy to drop it or do something else, let me
> > know.
>
> Nevermind, no I'm not, as I don't have the LSM/security rust helpers
> in the LSM tree as it looks like those aren't in Linus' tree yet.

With all of the dependencies now in Linus' tree, I'm going to merge
this into lsm/dev-staging so we can get some crude testing done.
Thanks again :)

-- 
paul-moore.com

Re: [PATCH] rust: lsm: replace context+len with lsm_context

[Miguel Ojeda]

On Fri, Nov 1, 2024 at 5:56 PM Paul Moore <paul@paul-moore.com> wrote:
>
> Thanks Alice.  Would you like me to pull this in via the LSM tree with
> the associated LSM changes, or would you prefer to do this some other
> way?
>
> I'm going to merge this into lsm/dev for now so that we fix the issue
> in linux-next, but I'm happy to drop it or do something else, let me
> know.

Christian has the VFS side, and both are needed for this -- do you
mean you will cross-merge vfs' branch too?

By the way, merging both vfs.rust.file and lsm/dev I confirm this builds fine:

Acked-by: Miguel Ojeda <ojeda@kernel.org>

Thanks!

Cheers,
Miguel

Re: [PATCH] rust: lsm: replace context+len with lsm_context

[Paul Moore]

On Fri, Nov 1, 2024 at 1:04 PM Miguel Ojeda
<miguel.ojeda.sandonis@gmail.com> wrote:
> On Fri, Nov 1, 2024 at 5:56 PM Paul Moore <paul@paul-moore.com> wrote:
> >
> > Thanks Alice.  Would you like me to pull this in via the LSM tree with
> > the associated LSM changes, or would you prefer to do this some other
> > way?
> >
> > I'm going to merge this into lsm/dev for now so that we fix the issue
> > in linux-next, but I'm happy to drop it or do something else, let me
> > know.
>
> Christian has the VFS side, and both are needed for this -- do you
> mean you will cross-merge vfs' branch too?

I think our last emails crossed paths.  I'm not going to merge this
via the LSM tree as we don't have the Rust security.c helpers.
Ideally it would have been better to have the Rust LSM/security
helpers in the LSM tree for reasons like this, but it looks like it's
too late for that now.

> By the way, merging both vfs.rust.file and lsm/dev I confirm this builds fine:
>
> Acked-by: Miguel Ojeda <ojeda@kernel.org>

Thanks for the build test!

-- 
paul-moore.com

Re: [PATCH] rust: lsm: replace context+len with lsm_context

[Alice Ryhl]

On Fri, Nov 1, 2024 at 6:11 PM Paul Moore <paul@paul-moore.com> wrote:
>
> On Fri, Nov 1, 2024 at 1:04 PM Miguel Ojeda
> <miguel.ojeda.sandonis@gmail.com> wrote:
> > On Fri, Nov 1, 2024 at 5:56 PM Paul Moore <paul@paul-moore.com> wrote:
> > >
> > > Thanks Alice.  Would you like me to pull this in via the LSM tree with
> > > the associated LSM changes, or would you prefer to do this some other
> > > way?
> > >
> > > I'm going to merge this into lsm/dev for now so that we fix the issue
> > > in linux-next, but I'm happy to drop it or do something else, let me
> > > know.
> >
> > Christian has the VFS side, and both are needed for this -- do you
> > mean you will cross-merge vfs' branch too?
>
> I think our last emails crossed paths.  I'm not going to merge this
> via the LSM tree as we don't have the Rust security.c helpers.
> Ideally it would have been better to have the Rust LSM/security
> helpers in the LSM tree for reasons like this, but it looks like it's
> too late for that now.

If Christian is okay with rewriting the vfs.rust.file tree, we can
drop commit 94d356c0335f ("rust: security: add abstraction for
secctx") from there and I'll update it and send it for inclusion in
the LSM tree instead. I'll need to drop the piece that ties together
`struct cred` and `secctx` from the patch, but I can follow up with a
small patch for that for the 6.14 merge window.

Alice

[PATCH] rust: security: add abstraction for secctx

[Alice Ryhl]

Add an abstraction for viewing the string representation of a security
context.

This is needed by Rust Binder because it has a feature where a process
can view the string representation of the security context for incoming
transactions. The process can use that to authenticate incoming
transactions, and since the feature is provided by the kernel, the
process can trust that the security context is legitimate.

This abstraction makes the following assumptions about the C side:
* When a call to `security_secid_to_secctx` is successful, it returns an
  lsm context containing a pointer and length. The pointer references a
  byte string and is valid for reading for that many bytes.
* The string may be referenced until `security_release_secctx` is
  called.
* If CONFIG_SECURITY is set, then the three methods mentioned in
  rust/helpers are available without a helper. (That is, they are not a
  #define or `static inline`.)

This patch had to be modified after its first landing due to some
conflicts with other changes. Please see [1] for details.

Reviewed-by: Benno Lossin <benno.lossin@proton.me>
Reviewed-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com>
Reviewed-by: Trevor Gross <tmgross@umich.edu>
Reviewed-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Kees Cook <kees@kernel.org>
Link: https://lore.kernel.org/r/20241101095620.2526421-1-aliceryhl@google.com [1]
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
---
 rust/bindings/bindings_helper.h |  1 +
 rust/helpers/helpers.c          |  1 +
 rust/helpers/security.c         | 15 +++++++
 rust/kernel/lib.rs              |  1 +
 rust/kernel/security.rs         | 70 +++++++++++++++++++++++++++++++++
 5 files changed, 88 insertions(+)
 create mode 100644 rust/helpers/security.c
 create mode 100644 rust/kernel/security.rs

diff --git a/rust/bindings/bindings_helper.h b/rust/bindings/bindings_helper.h
index ae82e9c941af..3f3c39f9a83b 100644
--- a/rust/bindings/bindings_helper.h
+++ b/rust/bindings/bindings_helper.h
@@ -18,6 +18,7 @@
 #include <linux/phy.h>
 #include <linux/refcount.h>
 #include <linux/sched.h>
+#include <linux/security.h>
 #include <linux/slab.h>
 #include <linux/wait.h>
 #include <linux/workqueue.h>
diff --git a/rust/helpers/helpers.c b/rust/helpers/helpers.c
index 30f40149f3a9..36a0c833e7b4 100644
--- a/rust/helpers/helpers.c
+++ b/rust/helpers/helpers.c
@@ -17,6 +17,7 @@
 #include "page.c"
 #include "rbtree.c"
 #include "refcount.c"
+#include "security.c"
 #include "signal.c"
 #include "slab.c"
 #include "spinlock.c"
diff --git a/rust/helpers/security.c b/rust/helpers/security.c
new file mode 100644
index 000000000000..f6deb0b28b48
--- /dev/null
+++ b/rust/helpers/security.c
@@ -0,0 +1,15 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include <linux/security.h>
+
+#ifndef CONFIG_SECURITY
+int rust_helper_security_secid_to_secctx(u32 secid, struct lsm_context *cp)
+{
+	return security_secid_to_secctx(secid, cp);
+}
+
+void rust_helper_security_release_secctx(struct lsm_context *cp)
+{
+	security_release_secctx(cp);
+}
+#endif
diff --git a/rust/kernel/lib.rs b/rust/kernel/lib.rs
index 22a3bfa5a9e9..a71dc73a0d9d 100644
--- a/rust/kernel/lib.rs
+++ b/rust/kernel/lib.rs
@@ -46,6 +46,7 @@
 pub mod print;
 pub mod sizes;
 pub mod rbtree;
+pub mod security;
 mod static_assert;
 #[doc(hidden)]
 pub mod std_vendor;
diff --git a/rust/kernel/security.rs b/rust/kernel/security.rs
new file mode 100644
index 000000000000..25d2b1ac3833
--- /dev/null
+++ b/rust/kernel/security.rs
@@ -0,0 +1,70 @@
+// SPDX-License-Identifier: GPL-2.0
+
+// Copyright (C) 2024 Google LLC.
+
+//! Linux Security Modules (LSM).
+//!
+//! C header: [`include/linux/security.h`](srctree/include/linux/security.h).
+
+use crate::{
+    bindings,
+    error::{to_result, Result},
+};
+
+/// A security context string.
+///
+/// # Invariants
+///
+/// The `ctx` field corresponds to a valid security context as returned by a successful call to
+/// `security_secid_to_secctx`, that has not yet been destroyed by `security_release_secctx`.
+pub struct SecurityCtx {
+    ctx: bindings::lsm_context,
+}
+
+impl SecurityCtx {
+    /// Get the security context given its id.
+    pub fn from_secid(secid: u32) -> Result<Self> {
+        // SAFETY: `struct lsm_context` can be initialized to all zeros.
+        let mut ctx: bindings::lsm_context = unsafe { core::mem::zeroed() };
+
+        // SAFETY: Just a C FFI call. The pointer is valid for writes.
+        to_result(unsafe { bindings::security_secid_to_secctx(secid, &mut ctx) })?;
+
+        // INVARIANT: If the above call did not fail, then we have a valid security context.
+        Ok(Self { ctx })
+    }
+
+    /// Returns whether the security context is empty.
+    pub fn is_empty(&self) -> bool {
+        self.ctx.len == 0
+    }
+
+    /// Returns the length of this security context.
+    pub fn len(&self) -> usize {
+        self.ctx.len as usize
+    }
+
+    /// Returns the bytes for this security context.
+    pub fn as_bytes(&self) -> &[u8] {
+        let ptr = self.ctx.context;
+        if ptr.is_null() {
+            debug_assert_eq!(self.len(), 0);
+            // We can't pass a null pointer to `slice::from_raw_parts` even if the length is zero.
+            return &[];
+        }
+
+        // SAFETY: The call to `security_secid_to_secctx` guarantees that the pointer is valid for
+        // `self.len()` bytes. Furthermore, if the length is zero, then we have ensured that the
+        // pointer is not null.
+        unsafe { core::slice::from_raw_parts(ptr.cast(), self.len()) }
+    }
+}
+
+impl Drop for SecurityCtx {
+    fn drop(&mut self) {
+        // SAFETY: By the invariant of `Self`, this frees a context that came from a successful
+        // call to `security_secid_to_secctx` and has not yet been destroyed by
+        // `security_release_secctx`.
+        unsafe { bindings::security_release_secctx(&mut self.ctx) };
+    }
+}

base-commit: 1008010aafe7b1e06974b8b1bf29b052fcf87f92
-- 
2.47.0.199.ga7371fff76-goog

Re: [PATCH] rust: lsm: replace context+len with lsm_context

[Paul Moore]

On Fri, Nov 1, 2024 at 1:24 PM Alice Ryhl <aliceryhl@google.com> wrote:
> On Fri, Nov 1, 2024 at 6:11 PM Paul Moore <paul@paul-moore.com> wrote:
> > On Fri, Nov 1, 2024 at 1:04 PM Miguel Ojeda
> > <miguel.ojeda.sandonis@gmail.com> wrote:
> > > On Fri, Nov 1, 2024 at 5:56 PM Paul Moore <paul@paul-moore.com> wrote:
> > > >
> > > > Thanks Alice.  Would you like me to pull this in via the LSM tree with
> > > > the associated LSM changes, or would you prefer to do this some other
> > > > way?
> > > >
> > > > I'm going to merge this into lsm/dev for now so that we fix the issue
> > > > in linux-next, but I'm happy to drop it or do something else, let me
> > > > know.
> > >
> > > Christian has the VFS side, and both are needed for this -- do you
> > > mean you will cross-merge vfs' branch too?
> >
> > I think our last emails crossed paths.  I'm not going to merge this
> > via the LSM tree as we don't have the Rust security.c helpers.
> > Ideally it would have been better to have the Rust LSM/security
> > helpers in the LSM tree for reasons like this, but it looks like it's
> > too late for that now.
>
> If Christian is okay with rewriting the vfs.rust.file tree, we can
> drop commit 94d356c0335f ("rust: security: add abstraction for
> secctx") from there and I'll update it and send it for inclusion in
> the LSM tree instead. I'll need to drop the piece that ties together
> `struct cred` and `secctx` from the patch, but I can follow up with a
> small patch for that for the 6.14 merge window.

I can only guess at what Chrisitian wants to do, but my guess is that
he isn't going to be very excited about rewriting a VFS tree at this
stage ... which is very understandable as far as I'm concerned.

I wouldn't worry too much about this right now, I'm going to plan on
holding Casey's patchset in a staging area until after the upcoming
merge window.

-- 
paul-moore.com

Re: [PATCH] rust: lsm: replace context+len with lsm_context

[Alice Ryhl]

On Fri, Nov 1, 2024 at 6:59 PM Paul Moore <paul@paul-moore.com> wrote:
>
> On Fri, Nov 1, 2024 at 1:24 PM Alice Ryhl <aliceryhl@google.com> wrote:
> > On Fri, Nov 1, 2024 at 6:11 PM Paul Moore <paul@paul-moore.com> wrote:
> > > On Fri, Nov 1, 2024 at 1:04 PM Miguel Ojeda
> > > <miguel.ojeda.sandonis@gmail.com> wrote:
> > > > On Fri, Nov 1, 2024 at 5:56 PM Paul Moore <paul@paul-moore.com> wrote:
> > > > >
> > > > > Thanks Alice.  Would you like me to pull this in via the LSM tree with
> > > > > the associated LSM changes, or would you prefer to do this some other
> > > > > way?
> > > > >
> > > > > I'm going to merge this into lsm/dev for now so that we fix the issue
> > > > > in linux-next, but I'm happy to drop it or do something else, let me
> > > > > know.
> > > >
> > > > Christian has the VFS side, and both are needed for this -- do you
> > > > mean you will cross-merge vfs' branch too?
> > >
> > > I think our last emails crossed paths.  I'm not going to merge this
> > > via the LSM tree as we don't have the Rust security.c helpers.
> > > Ideally it would have been better to have the Rust LSM/security
> > > helpers in the LSM tree for reasons like this, but it looks like it's
> > > too late for that now.
> >
> > If Christian is okay with rewriting the vfs.rust.file tree, we can
> > drop commit 94d356c0335f ("rust: security: add abstraction for
> > secctx") from there and I'll update it and send it for inclusion in
> > the LSM tree instead. I'll need to drop the piece that ties together
> > `struct cred` and `secctx` from the patch, but I can follow up with a
> > small patch for that for the 6.14 merge window.
>
> I can only guess at what Chrisitian wants to do, but my guess is that
> he isn't going to be very excited about rewriting a VFS tree at this
> stage ... which is very understandable as far as I'm concerned.
>
> I wouldn't worry too much about this right now, I'm going to plan on
> holding Casey's patchset in a staging area until after the upcoming
> merge window.

Okay. If Casey's patchset is not landing for 6.13, then the fix I
posted initially can be used. Casey is also welcome to squash my fix
into his series if you all prefer that. I'm happy with whatever is
easiest for you all.

Alice