From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f53.google.com (mail-wm1-f53.google.com [209.85.128.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CB1D83DCD9B for ; Mon, 10 Aug 2026 13:25:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.53 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786368327; cv=none; b=vEaIcgVzzN3Z+26nki+mVhwSazZCfqA9yWWr9P/8fD/nF8/gJzVmlmRhX+CB79agv1VEgQ24yPziBOsONQQEiKv4IrklYL1rnBiLv/vJVA8ZiLEADbNDoJCuXCCbUfZkAPKv8Y7/ozjECj9cdBIVnm6qc9HUE3Eq5Vxqpggxig8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786368327; c=relaxed/simple; bh=B8Kpw0JPqJEXYAOLDMKIaAc4pa002KqgaAqibO7rajc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Q8NV9DTUgg3/y8L9znpgLi26X6W+7Rk24e99ojJaVWu3+EfdEvfXqMijsXJbUxpAkBmIO3AFBCcgwJar3AWeg29k8S+yE+WiFy8XBreg5BSrIOrR04tVckk7V4QumeOMqOQ6M3cMURgZqvJrJmLGJoDqvKtB0DNGnR507aD2Zm0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=K2xcQEdq; arc=none smtp.client-ip=209.85.128.53 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="K2xcQEdq" Received: by mail-wm1-f53.google.com with SMTP id 5b1f17b1804b1-4954d29264cso8847805e9.2 for ; Mon, 10 Aug 2026 06:25:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786368324; x=1786973124; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=N0ofoODcYWs3I9OWUEGLHyeHF210MGua+sArH7R31wk=; b=K2xcQEdqGBHowxxZs8MPx/yE039bJWgPMxxkp4/jDRHdmNgymHgAgc9WngTbmWFVE8 kR0lg/VezGKI02S2gOXPAvMPl1NL4qHChCPG/ThTLPbos/o+rJtEqopk9/dNOEXLUdkK O2Sk74awk7+s3DGBCsv4xDud6+vtc1gs0iSAiK94pR/d81O63/1bMuYlWiDFy6hgZysZ mk4RcYp9fwIDkk/R/u6/I3XeFDVaWHBF7dDR4s+jn6HQLrImLmURgtDa+AtGng0ZCHoz lpsaMhWbPAETUSj6urdZuNZ6rFCuTBD50gm30wvjxvewK6EQwhFSCJn3EE/+EOkYDHu0 Rr/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786368324; x=1786973124; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=N0ofoODcYWs3I9OWUEGLHyeHF210MGua+sArH7R31wk=; b=Jq6qhXcNOmSdAwN5eFa72Tt+n4YkgsX3N2DfvLyRoWijsdp8bhnybdi0DQUUZ5QItR rhV4hdLFDqW10VNcmbD5uS+knt7E7z3zPiWvxTSPqCPJq+JnQd5HPeeARtABm1MPtJBu mwu4Ug7Jnzqyts8ktl0DCXJa5+9yz80+ObVlGxBbGhHiUXWz/8FkroATAWcU3feLnqvi YD40+UpqzrfiGIttTICNgCygathz/MI2tfCOoodOcbgUS9IandJnRhRyE88Iwptz284x AZWpHNEf7SKFm6iDqTqu4ipMaRgE4DfxTsRzUJsDTPIPsI781MVU/wI+RjT4hW1S2tpn SLjQ== X-Forwarded-Encrypted: i=1; AHgh+Ro1IoqKUA+t3JGtY1HnGTF6sEzLwN2fX00RSLg/GHuZ9htRyyDu0JdK9OCNe/aeoVHxC0VMBa7bjef3mZc=@vger.kernel.org X-Gm-Message-State: AOJu0Yye2mbeS3/iNhDRmFldNUCtg498zZ3ls6Verqj9rTWmyUlb31Mt bZ8I3gDUfOpil8OD7CIGR+hbY9WxuFaSWu3DP8kowrTtcs9BACedeWzw X-Gm-Gg: AR+sD10qssPSnM5zPSYLK0NWe7/iNl8uceHl3CnS6KwWim8UuNfzIHjF3OSlYAJbHbc 8wZ5bCnCzoNhYjIVYmCBLzUe5pFOdGHC5WfkAZryVGLQT6Ht4S0C2toyAZZ3K+KOjdFqpYvbD+7 ScpiljwxvoJp0kYyXUE9PiW6nyTCkbzXmurRyAY2kIvD6DEfIGyQiQg5oPdHbv3FHftQbtLDY/A KTQLvbp0R2TRpMtYCIsK2VQ3bPC7QIgY01D49DeH5BkMFiVd5Y13uAy0gIiiC2hAvXRew2EcgHj riauTBQgv7IZtdZOY2ovYO5GNolVIoLp4ImAsSSCU5vXJ60kGB+XZ9Xl4sWWUaGPD27VQwZav7o yd+gO6xm9IxMPIdiFWY/a2K22qTuqbAhVdgPGUU3q8GCSkiyowuF5iviikb27IY5ZgOAibwtdmJ lLsdD8WiQDPr01C+fGIOMAAGRnyNCH25te2co+dEEVoDQMmSSQDK5r3C9y5gCse3sExNysDw== X-Received: by 2002:a05:600c:4f86:b0:495:4d00:2fda with SMTP id 5b1f17b1804b1-4994e72f7c1mr558010415e9.2.1786368323764; Mon, 10 Aug 2026 06:25:23 -0700 (PDT) Received: from mail.gmail.com ([2a04:ee41:4:b2de:1ac0:4dff:fe0f:3782]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4995c69c8ffsm229399395e9.2.2026.08.10.06.25.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 10 Aug 2026 06:25:22 -0700 (PDT) Date: Mon, 10 Aug 2026 13:35:51 +0000 From: Anton Protopopov To: Vadim Fedorenko Cc: "Michael S. Tsirkin" , Jason Wang , Xuan Zhuo , Eugenio =?iso-8859-1?Q?P=E9rez?= , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , netdev@vger.kernel.org, virtualization@lists.linux.dev, linux-kernel@vger.kernel.org Subject: Re: [PATCH net] virtio_net: Fix resize of the RX ring Message-ID: References: <20260810120728.47445-1-a.s.protopopov@gmail.com> <2aef652e-d98d-4ca5-8270-5f108e5593a2@linux.dev> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2aef652e-d98d-4ca5-8270-5f108e5593a2@linux.dev> On 26/08/10 02:07PM, Vadim Fedorenko wrote: > On 10/08/2026 13:07, Anton Protopopov wrote: > > When a AF_XDP socket is attached, the virtnet_rx_resize > > should resize the rq->xsk_buffs XSK buffer array. Otherwise, > > when the size grows, the virtnet_rx_resume() causes a write > > past the end of the array. This is easily reproducable with > > > > ethtool -G ens3 rx 32 > > ./xdpsock -i eth0 -q 0 -r -z & > > ethtool -G eth0 rx 256 > > > > Fixes: e9f3962441c0 ("virtio_net: xsk: rx: support fill with xsk buffer") > > Signed-off-by: Anton Protopopov > > --- > > drivers/net/virtio_net.c | 14 ++++++++++++++ > > 1 file changed, 14 insertions(+) > > > > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c > > index 3e2a5876c6c8..e34c52d059d3 100644 > > --- a/drivers/net/virtio_net.c > > +++ b/drivers/net/virtio_net.c > > @@ -3444,17 +3444,31 @@ static void virtnet_rx_resume_all(struct virtnet_info *vi) > > static int virtnet_rx_resize(struct virtnet_info *vi, > > struct receive_queue *rq, u32 ring_num) > > { > > + unsigned int old_ring_num = virtqueue_get_vring_size(rq->vq); > > + struct xdp_buff **tmp_xsk_buffs = NULL; > > int err, qindex; > > qindex = rq - vi->rq; > > + if (rq->xsk_pool && ring_num > old_ring_num) { > > why do you cover only the case for growing buffer? Don't we expect to > free some memory in case of shrinking? Should be fine given you are > swapping buffers completely... Isn't this common for "realloc[s]" to just return the same ptr, when shrinking (to avoid extra actual allocations)? But I do not have any strong feelings about this, can switch to "shrink/grow", if this looks better. > > + tmp_xsk_buffs = kvzalloc_objs(*tmp_xsk_buffs, ring_num); > > + if (!tmp_xsk_buffs) > > + return -ENOMEM; > > + } > > + > > virtnet_rx_pause(vi, rq); > > err = virtqueue_resize(rq->vq, ring_num, virtnet_rq_unmap_free_buf, NULL); > > + > > + /* virtqueue_resize may have changed the size even if err != 0 */ > > + if (tmp_xsk_buffs && virtqueue_get_vring_size(rq->vq) > old_ring_num) > > + swap(rq->xsk_buffs, tmp_xsk_buffs); > > + > > if (err) > > netdev_err(vi->dev, "resize rx fail: rx queue index: %d err: %d\n", qindex, err); > > virtnet_rx_resume(vi, rq, true); > > + kvfree(tmp_xsk_buffs); > > return err; > > } >