On Thu, Aug 06, 2026 at 09:04:10AM -0700, Jakub Kicinski wrote: > Was an out of range qid actually reachable here? > ... > Could the changelog describe this as a defensive reordering rather than > as preventing an out of range dereference? > ... > since the patch touches the enable-side qid test, is the symmetric test > in virtnet_xsk_pool_disable() safe?
Thanks for the review. You are right on both counts for this patch: qid is already bounded by xsk_reg_pool_at_qid(), and the old ordering still rejected the request before sq/rq were used. The only visible difference was -EINVAL vs -ENOENT for qid in [curr_queue_pairs, max_queue_pairs). I will drop this reorder (and the overstated changelog). On the disable path / XDP detach interaction: I agree. If curr_queue_pairs shrinks while an AF_XDP pool is still bound, virtnet_xsk_pool_disable() can return -EINVAL, skip cleanup, and leave rq/sq->xsk_pool pointing at a pool that xp_clear_dev() then frees. I will drop this series and post a v2 replacement as a new thread that: 1) lets disable clean up with a max_queue_pairs bounds check, and 2) refuses XDP-driven queue shrink while AF_XDP is still bound. Thanks, Xiong Weimin
