Claude review: rust: interop: Add list module for C linked list interface

[Claude Code Review Bot <claude-review@example.com>]

Patch Review

**`is_linked` semantics are inverted vs C convention (moderate concern)**

The `is_linked` method at line ~413 checks:
```rust
unsafe { (*raw).next != raw && (*raw).prev != raw }
```

This checks that *both* `next` and `prev` don't point to self. However, the C `list_empty()` only checks `head->next == head`. The `&&` here means a node where only `prev` points to self (a corrupted/partially-linked state) would be considered "linked." While this likely doesn't matter in practice for well-formed lists, it's inconsistent with C semantics. More importantly, `is_empty` on `CList` delegates to `!is_linked()`, so an empty list check would use different logic than C's `list_empty()`.

Consider using just `(*raw).next != raw` to match C's `list_empty` semantics, or document why the stricter check is intentional.

**`CList` is `#[repr(transparent)]` but contains `PhantomData` (minor)**

```rust
#[repr(transparent)]
pub struct CList<T, const OFFSET: usize>(CListHead, PhantomData<T>);
```

This is actually fine — `PhantomData<T>` is a ZST and `#[repr(transparent)]` allows one non-ZST field plus any number of ZST fields. Just noting this is correct.

**`clist_create` macro type-checking closure is uncalled (minor)**

```rust
let _: fn(*const $c_type) -> *const $crate::bindings::list_head =
    |p| &raw const (*p).$($field).+;
```

This is a clever compile-time check that the field path produces a `list_head`, but the closure is never called and the raw pointer dereference inside it is in an unsafe context (closures coerced to fn pointers). Since it's a dead code path used only for type checking, it's fine, but a comment explaining *why* this pattern works would help future readers.

**`Send`/`Sync` impls warrant careful consideration (minor)**

```rust
// SAFETY: `list_head` contains no thread-bound state; it only holds
// `next`/`prev` pointers.
unsafe impl Send for CListHead {}

// SAFETY: `CListHead` can be shared among threads as modifications are
// not allowed at the moment.
unsafe impl Sync for CListHead {}
```

The `Sync` justification "modifications are not allowed at the moment" is fragile — if mutation methods are added later (e.g., `list_add`, `list_del`), `Sync` would need to be reconsidered. The safety comment should more precisely state the invariant rather than describe a temporal condition. That said, the `from_raw` safety contract already requires "must not be concurrently modified," so the `Sync` impl relies on callers upholding that contract.

**`#![feature(offset_of_nested)]` addition**

```rust
#![feature(offset_of_nested)]
```

This enables nested field access in `offset_of!` (e.g., `offset_of!(Type, field.subfield)`). The macro signature `$($field:tt).+` supports dotted paths, so this feature gate is needed. This is stabilized in Rust 1.77+, so depending on the minimum Rust version for the kernel, the feature gate may or may not be needed. Worth confirming the kernel's minimum Rust version.

**C helpers look correct**

The `rust_helper_INIT_LIST_HEAD` and `rust_helper_list_add_tail` wrappers are straightforward and follow the existing pattern in `rust/helpers/`. The alphabetical placement of `#include "list.c"` after `kunit.c` is correct.

**MAINTAINERS entry looks good**

The `RUST [INTEROP]` section follows existing conventions with appropriate maintainers, mailing list, git tree, and file patterns.

**Overall**: This is a solid, well-reviewed patch. The main actionable item is the `is_linked` semantics question. The rest are minor observations that don't block merging.

---
Generated by Claude Code Patch Reviewer