From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 999942798F3 for ; Mon, 2 Mar 2026 15:12:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772464339; cv=none; b=UrNNlwHaQ0ZXZ5vHylZjcwMv3jak4gz0C5k28oxR+Onh9MoUj6ftFd6oXZgB03OESf4rfFr2mA56RHiqAfBucDcNprPpfYoQwMWnkOVw3V8xOl1/iZcXLFhJyeS9+peunRaNUPu8xTVdflBIE1k86HSkZz5JsEgrHmEsPqYUIsk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772464339; c=relaxed/simple; bh=op0liavrrZXpHIYFE8b5murCMpJBWBYITF7jRogwVXU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=TWezsPNV6lYgzVLgHSRxijVMBMqlJ7II9lRB2ixAtEdzLmAAJPi/pJCH1HLCr/NGc+9eGe7m/8j/sTU+XssfjlKyi1GPO76ID5Gpr+N9Sci/2t2jfqyke7M51HH23oq1Xv5Tt6OxW6Z7i2Mawm7cLmW0HWsuh60OWA6k/Lqedng= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=f7Yq+j0Y; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=FiKaHq+2; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="f7Yq+j0Y"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="FiKaHq+2" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1772464337; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=RF0n2SJ1RvllNep2fFvHq0JPMVeIU4OKpnJDj8ItlsE=; b=f7Yq+j0Ytmpr/fRVP0tAtZbm71mFQUs6vJvoxgZ0+AZWyioS6dxgFDHZv9X13Pp+xOyy+a vsO7zXrRRekLDCg9V9WzUIz8iTXR0WwoAcSGL7s7xJSKfhFBiNapTaP8WaPL+8Wopi2il/ 13vrhHg+uZ1HAiWjkF3qP0OfM3i3vdI= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-563-K6xcQGSoOviIMl4ZPIun4g-1; Mon, 02 Mar 2026 10:12:16 -0500 X-MC-Unique: K6xcQGSoOviIMl4ZPIun4g-1 X-Mimecast-MFC-AGG-ID: K6xcQGSoOviIMl4ZPIun4g_1772464335 Received: by mail-wm1-f69.google.com with SMTP id 5b1f17b1804b1-4832c4621c2so50439825e9.3 for ; Mon, 02 Mar 2026 07:12:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1772464335; x=1773069135; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=RF0n2SJ1RvllNep2fFvHq0JPMVeIU4OKpnJDj8ItlsE=; b=FiKaHq+2tyH8zoTrCU34EKgaF6VI4eGrN7Cpbgpl+PK5i9Xi1gzBpVkXVTuX0/q+a0 GrU8h9k5AzbcY92nNVQACuup3wznw+f/TOJ1Dc5QUwJMgS/3gUHhyvOFMOw+SKm/jmAa 7vwIfA2H4OV8wzoSeCRzOKTBwyFtVgHf+qkV3silkj5mu1YfM4P+q/evcNISgDe5MiMV lmm3qELJZMuLhM74D257VLkImoXcgGS/tVtoQm++PHkshiu8gSx8VvdOBrU3UvvtxzpZ nIzYn0LoiPHZR9xsY1hAI0CCwwM8DHzHmYdaWSQzVcBdWNrlRJVWcxQtELEQHGcZahdd /9GA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772464335; x=1773069135; h=in-reply-to:content-disposition: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; bh=RF0n2SJ1RvllNep2fFvHq0JPMVeIU4OKpnJDj8ItlsE=; b=JtgCiNQ6fucLW6L3Kg/A9RunPNBiVP4aJx/8u+Nq9p80aDHz8/TRYGuuXZicuLMr/o bDxu3E3oHfMkkdPMky7jjP8QbZlG3Xot/t/1r5u3OifwQBMRA7EWjIjpVysJfO8hJlCK cuAzbPPKNsMzA4P/6QjgxzJZFEIJbILmr+sTiBGRIkABXgGvZzIAu9jocryAIif5eKHW CfHkjHkr5qCMpMKGLU8cp5fskkTeGK2V1G4J60juQWUCxHP8i9Rx+QGLvjjQWKip8I87 vk1O8aT77BSPPA3/KmI+I/VUouHKHgUCbDGW28e4+ScEKqEu2qeUYrIBEnFm9Z6eiwoM 4i1w== X-Gm-Message-State: AOJu0YwoS5zy+vNrIt4vvLBJ+1TxFqVq+376eRh7lHnSJxzKhwary3Co xEYT2SKp7U+XlJVpEgyMG5WBGSLyyqyvFdRCXkY3RGY1CWD37NoAobTg8nqWF1IezTmryt5NMpe WtYYJnalgGZrrEbRGUFTt3O2/+f8NO4Ypx11esa4zeZREgT0EruCumy2ZM2oiHMh+Xw== X-Gm-Gg: ATEYQzxK+M2V3hGsVjeQxSJ0MbfVAYXCyLtACIRemHUxrc/Of+hPQ39ufj8FqsTILUK 4a1XQXq2HA0xpb/+dgbIxoSNNyob/YRFAIrXrbWbZkpbBMcnvUt6EiI/Lnv8GCvZ9h8HEmhQxLt M5Q4ZAYT/3h+u8WYxUoHp56SaQDlD3cE1g9zpiw4bNvhfEHsOhqiWZfvQRHDDdtRPcJbRyw6sw+ 5z0Cc71J5d8MjTpRLFwX2DxLS2rNtA8YJwA5ME1sB+rmvw05k2h/DZAoRusppcrAWaoqrh6SyBL gxD6tuIoRTphg879UV7BPC6/fOKr4KaUXrBWMufYmIUzna5PxN0wLaZwnqjPJ8KHwxwtD/0nkSp 3BQBfkDg+bS39epuGxBxL27JeThzGwE14ocBAGza24QHJMg== X-Received: by 2002:a05:600c:8106:b0:46f:c55a:5a8d with SMTP id 5b1f17b1804b1-483c9bb6559mr206067775e9.4.1772464335149; Mon, 02 Mar 2026 07:12:15 -0800 (PST) X-Received: by 2002:a05:600c:8106:b0:46f:c55a:5a8d with SMTP id 5b1f17b1804b1-483c9bb6559mr206067215e9.4.1772464334575; Mon, 02 Mar 2026 07:12:14 -0800 (PST) Received: from redhat.com (IGLD-80-230-79-166.inter.net.il. [80.230.79.166]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-483bd765604sm360962425e9.15.2026.03.02.07.12.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Mar 2026 07:12:13 -0800 (PST) Date: Mon, 2 Mar 2026 10:12:11 -0500 From: "Michael S. Tsirkin" To: Stefano Garzarella Cc: linux-kernel@vger.kernel.org, ShuangYu , Stefan Hajnoczi , Jason Wang , Eugenio =?iso-8859-1?Q?P=E9rez?= , kvm@vger.kernel.org, virtualization@lists.linux.dev, netdev@vger.kernel.org Subject: Re: [PATCH RFC] vhost: fix vhost_get_avail_idx for a non empty ring Message-ID: <20260302101125-mutt-send-email-mst@kernel.org> References: <559b04ae6ce52973c535dc47e461638b7f4c3d63.1772441455.git.mst@redhat.com> 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: On Mon, Mar 02, 2026 at 03:30:53PM +0100, Stefano Garzarella wrote: > On Mon, Mar 02, 2026 at 03:51:49AM -0500, Michael S. Tsirkin wrote: > > vhost_get_avail_idx is supposed to report whether it has updated > > vq->avail_idx. Instead, it returns whether all entries have been > > consumed, which is usually the same. But not always - in > > drivers/vhost/net.c and when mergeable buffers have been enabled, the > > driver checks whether the combined entries are big enough to store an > > incoming packet. If not, the driver re-enables notifications with > > available entries still in the ring. The incorrect return value from > > vhost_get_avail_idx propagates through vhost_enable_notify and causes > > the host to livelock if the guest is not making progress, as vhost will > > immediately disable notifications and retry using the available entries. > > Here I'd add something like this just to make it clear the full picture, > because I spent quite some time to understand how it was related to the > Fixes tag (which I agree is the right one to use). > > This goes back to commit d3bb267bbdcb ("vhost: cache avail index in > vhost_enable_notify()") which changed vhost_enable_notify() to compare > the freshly read avail index against vq->last_avail_idx instead of the > previously cached vq->avail_idx. Commit 7ad472397667 ("vhost: move > smp_rmb() into vhost_get_avail_idx()") then carried over the same > comparison when refactoring vhost_enable_notify() to call the unified > vhost_get_avail_idx(). Indeed. > > > > The obvious fix is to make vhost_get_avail_idx do what the comment > > says it does and report whether new entries have been added. > > > > Reported-by: ShuangYu > > Fixes: d3bb267bbdcb ("vhost: cache avail index in vhost_enable_notify()") > > Cc: Stefano Garzarella > > Cc: Stefan Hajnoczi > > Signed-off-by: Michael S. Tsirkin > > --- > > > > Lightly tested, posting early to simplify testing for the reporter. > > Tested with vhost-vsock and I didn't see any issue. > > Thanks! > > Reviewed-by: Stefano Garzarella > > > > > drivers/vhost/vhost.c | 11 +++++++---- > > 1 file changed, 7 insertions(+), 4 deletions(-) > > > > diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c > > index 2f2c45d20883..db329a6f6145 100644 > > --- a/drivers/vhost/vhost.c > > +++ b/drivers/vhost/vhost.c > > @@ -1522,6 +1522,7 @@ static void vhost_dev_unlock_vqs(struct vhost_dev *d) > > static inline int vhost_get_avail_idx(struct vhost_virtqueue *vq) > > { > > __virtio16 idx; > > + u16 avail_idx; > > int r; > > > > r = vhost_get_avail(vq, idx, &vq->avail->idx); > > @@ -1532,17 +1533,19 @@ static inline int vhost_get_avail_idx(struct vhost_virtqueue *vq) > > } > > > > /* Check it isn't doing very strange thing with available indexes */ > > - vq->avail_idx = vhost16_to_cpu(vq, idx); > > - if (unlikely((u16)(vq->avail_idx - vq->last_avail_idx) > vq->num)) { > > + avail_idx = vhost16_to_cpu(vq, idx); > > + if (unlikely((u16)(avail_idx - vq->last_avail_idx) > vq->num)) { > > vq_err(vq, "Invalid available index change from %u to %u", > > - vq->last_avail_idx, vq->avail_idx); > > + vq->last_avail_idx, avail_idx); > > return -EINVAL; > > } > > > > /* We're done if there is nothing new */ > > - if (vq->avail_idx == vq->last_avail_idx) > > + if (avail_idx == vq->avail_idx) > > return 0; > > > > + vq->avail_idx = avail_idx; > > + > > /* > > * We updated vq->avail_idx so we need a memory barrier between > > * the index read above and the caller reading avail ring entries. > > -- > > MST > >