diff --git a/src/new/linux_uapi/linux/can.rs b/src/new/linux_uapi/linux/can.rs
index 8fb4b9d6dc972..971e579bc8d6e 100644
--- a/src/new/linux_uapi/linux/can.rs
+++ b/src/new/linux_uapi/linux/can.rs
@@ -1,9 +1,6 @@
 //! Header: `uapi/linux/can.h`
 
-// FIXME(ctest): we shouldn't have to specify the path but garando doesn't find modules otherwise
-#[path = "can/j1939.rs"]
 pub(crate) mod j1939;
-#[path = "can/raw.rs"]
 pub(crate) mod raw;
 
 pub use j1939::*;
diff --git a/src/primitives.rs b/src/primitives.rs
index b4c614eb388d1..630b03a911230 100644
--- a/src/primitives.rs
+++ b/src/primitives.rs
@@ -99,35 +99,6 @@ cfg_if! {
             target_os = "watchos"
         ))
     ))] {
-        // This introduces partial support for FFI with __int128 and
-        // equivalent types on platforms where Rust's definition is validated
-        // to match the standard C ABI of that platform.
-        //
-        // Rust does not guarantee u128/i128 are sound for FFI, and its
-        // definitions are in fact known to be incompatible. [0]
-        //
-        // However these problems aren't fundamental, and are just platform
-        // inconsistencies. Specifically at the time of this writing:
-        //
-        // * For x64 SysV ABIs (everything but Windows), the types are underaligned.
-        // * For all Windows ABIs, Microsoft doesn't actually officially define __int128,
-        //   and as a result different implementations don't actually agree on its ABI.
-        //
-        // But on the other major aarch64 platforms (android, linux, ios, macos) we have
-        // validated that rustc has the right ABI for these types. This is important because
-        // aarch64 uses these types in some fundamental OS types like user_fpsimd_struct,
-        // which represents saved simd registers.
-        //
-        // Any API which uses these types will need to `#[ignore(improper_ctypes)]`
-        // until the upstream rust issue is resolved, but this at least lets us make
-        // progress on platforms where this type is important.
-        //
-        // The list of supported architectures and OSes is intentionally very restricted,
-        // as careful work needs to be done to verify that a particular platform
-        // has a conformant ABI.
-        //
-        // [0]: https://github.com/rust-lang/rust/issues/54341
-
         /// C `__int128` (a GCC extension that's part of many ABIs)
         pub type __int128 = i128;
         /// C `unsigned __int128` (a GCC extension that's part of many ABIs)
@@ -136,41 +107,6 @@ cfg_if! {
         pub type __int128_t = i128;
         /// C __uint128_t (alternate name for [__uint128][])
         pub type __uint128_t = u128;
-
-        // NOTE: if you add more platforms to here, you may need to cfg
-        // these consts. They should always match the platform's values
-        // for `sizeof(__int128)` and `_Alignof(__int128)`.
-        const _SIZE_128: usize = 16;
-        const _ALIGN_128: usize = 16;
-
-        // FIXME(ctest): ctest doesn't handle `_` as an identifier so these tests are temporarily
-        // disabled.
-        // macro_rules! static_assert_eq {
-        //     ($a:expr, $b:expr) => {
-        //         const _: [(); $a] = [(); $b];
-        //     };
-        // }
-        //
-        // // Since Rust doesn't officially guarantee that these types
-        // // have compatible ABIs, we const assert that these values have the
-        // // known size/align of the target platform's libc. If rustc ever
-        // // tries to regress things, it will cause a compilation error.
-        // //
-        // // This isn't a bullet-proof solution because e.g. it doesn't
-        // // catch the fact that llvm and gcc disagree on how x64 __int128
-        // // is actually *passed* on the stack (clang underaligns it for
-        // // the same reason that rustc *never* properly aligns it).
-        // static_assert_eq!(size_of::<__int128>(), _SIZE_128);
-        // static_assert_eq!(align_of::<__int128>(), _ALIGN_128);
-
-        // static_assert_eq!(size_of::<__uint128>(), _SIZE_128);
-        // static_assert_eq!(align_of::<__uint128>(), _ALIGN_128);
-
-        // static_assert_eq!(size_of::<__int128_t>(), _SIZE_128);
-        // static_assert_eq!(align_of::<__int128_t>(), _ALIGN_128);
-
-        // static_assert_eq!(size_of::<__uint128_t>(), _SIZE_128);
-        // static_assert_eq!(align_of::<__uint128_t>(), _ALIGN_128);
     } else if #[cfg(all(
         target_arch = "aarch64",
         any(
diff --git a/src/unix/linux_like/mod.rs b/src/unix/linux_like/mod.rs
index f4f88e365edf3..521b2890fc1e1 100644
--- a/src/unix/linux_like/mod.rs
+++ b/src/unix/linux_like/mod.rs
@@ -1783,13 +1783,10 @@ cfg_if! {
 
         /// Build an ioctl number, analogous to the C macro of the same name.
         const fn _IOC(dir: u32, ty: u32, nr: u32, size: usize) -> Ioctl {
-            // FIXME(ctest) the `garando_syntax` crate (used by ctest in the CI test suite)
-            // cannot currently parse these `debug_assert!`s
-            //
-            // debug_assert!(dir <= _IOC_DIRMASK);
-            // debug_assert!(ty <= _IOC_TYPEMASK);
-            // debug_assert!(nr <= _IOC_NRMASK);
-            // debug_assert!(size <= (_IOC_SIZEMASK as usize));
+            core::debug_assert!(dir <= _IOC_DIRMASK);
+            core::debug_assert!(ty <= _IOC_TYPEMASK);
+            core::debug_assert!(nr <= _IOC_NRMASK);
+            core::debug_assert!(size <= (_IOC_SIZEMASK as usize));
 
             ((dir << _IOC_DIRSHIFT)
                 | (ty << _IOC_TYPESHIFT)