Re: [PATCH 6/8] io_uring/zcrx: notify user when out of buffers

On 5/19/26 5:44 AM, Pavel Begunkov wrote:
> @@ -1126,6 +1142,48 @@ static unsigned io_zcrx_refill_slow(struct page_pool *pp, struct io_zcrx_ifq *if
>  	return allocated;
>  }
>  
> +static void zcrx_notif_tw(struct io_tw_req tw_req, io_tw_token_t tw)
> +{
> +	struct io_kiocb *req = tw_req.req;
> +	struct io_ring_ctx *ctx = req->ctx;
> +
> +	io_post_aux_cqe(ctx, req->cqe.user_data, req->cqe.res, 0);
> +	percpu_ref_put(&ctx->refs);
> +	io_poison_req(req);
> +	kmem_cache_free(req_cachep, req);
> +}
> +
> +static void zcrx_send_notif(struct io_zcrx_ifq *ifq, unsigned type)
> +{
> +	gfp_t gfp = GFP_ATOMIC | __GFP_NOWARN | __GFP_ZERO;
> +	u32 type_mask = 1 << type;
> +	struct io_kiocb *req;
> +
> +	if (!(type_mask & ifq->allowed_notif_mask))
> +		return;
> +
> +	guard(spinlock_bh)(&ifq->ctx_lock);
> +	if (!ifq->master_ctx)
> +		return;
> +	if (type_mask & ifq->fired_notifs)
> +		return;
> +
> +	req = kmem_cache_alloc(req_cachep, gfp);
> +	if (unlikely(!req))
> +		return;

It'd be nice to avoid an allocation here inside ctx_lock and with bh's
disabled, which looks like is also the only reason why GFP_ATOMIC is
being used here.

Maybe opportunistically check ->fired_notifs early? Might also avoid the
lock in the first place if we get back-to-back of these.

-- 
Jens Axboe