Re: [PATCH] io_uring/rsrc: use refcount_t for io_rsrc_node.refs

On 5/13/26 5:15 PM, Oleg Sevostyanov wrote:
> Hello,
> 
> This patch converts the refs field in struct io_rsrc_node from plain
> int to refcount_t.
> 
> Background
> ----------
> During a static analysis pass of io_uring/rsrc.{c,h} I examined all
> sites that touch io_rsrc_node.refs:
> 
>   - io_rsrc_node_alloc()     rsrc.c:147   initialises to 1
>   - io_buf_node_lookup()     rsrc.c:1117  refs++ under io_ring_submit_lock
>   - io_clone_buffers() x2    rsrc.c:1199  refs++ under uring_lock (lockdep_assert_held
>                              rsrc.c:1232  asserted on both ctx's)
>   - io_put_rsrc_node()       rsrc.h:107   --refs under uring_lock
> 
> All four sites are correctly guarded by ctx->uring_lock, so there is no
> present race or overflow risk.  This is a defence-in-depth change only.
> 
> Rationale
> ---------
> io_mapped_ubuf (defined in the same header, rsrc.h:40) already uses
> refcount_t for its own refs field.  Aligning io_rsrc_node to the same
> convention:

Because those can be shared across rings (cloning buffers), hence we
cannot rely on the ring lock for that.

>   1. Gives lockless overflow/underflow detection "for free" on kernels
>      built with REFCOUNT_FULL or on architectures that provide
>      REFCOUNT_ARCH_OPTIMIZED (x86 since 4.14).

It's certainly not "for free".

>   2. Makes it harder for a future patch that removes or relaxes locking
>      to silently introduce a refcount bug?the saturating behaviour of
>      refcount_t would catch wraps and emit a WARN_ONCE before a
>      use-after-free could occur.

You could just add a lockdep assert for that.

>   3. Self-documents the intent: the field is a reference counter, not an
>      arbitrary signed integer.

I mean, it's named ->refs, you'd think that'd make it clear enough.

> No functional change is intended.  I do not have a stable kernel build
> environment that includes the full io_uring tree, so I am unable to
> provide a Tested-by, but the patch compiles cleanly against the 6.8
> source tree (io_uring/ sparse checkout).

So in other words, you didn't even test this? And it's against an
ancient kernel?

None of that matters though, as that's a hard no on this patch.

-- 
Jens Axboe