From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 96F72A0C47; Thu, 14 Oct 2021 13:38:35 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 87BEC41219; Thu, 14 Oct 2021 13:38:35 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mails.dpdk.org (Postfix) with ESMTP id 5A21B40041 for ; Thu, 14 Oct 2021 13:38:33 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1634211512; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=lU//wBSfszlsMwdjixmaIpzS8fptBxlceUXJlenwOUk=; b=B3k+F5S9OaORg91Jp2XPXkP9GDulwrzNDY1Gei3tehN/9N60gR6VRHVbg9yCfp1ZiOK6pN d0yzuYNG2t8xsZEJWFRI6LrcshT1U/QwCChSzNO/2fT47Bdyw2z3Zg6LKRiMmrsySIs4TY vUTQo3lp1aT/1c23MY/phmGrTRPNpaY= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-76-8maLTf_zO0CemGLOoxiiSg-1; Thu, 14 Oct 2021 07:38:28 -0400 X-MC-Unique: 8maLTf_zO0CemGLOoxiiSg-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id BB5689F92A; Thu, 14 Oct 2021 11:38:27 +0000 (UTC) Received: from [10.39.208.20] (unknown [10.39.208.20]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C349860583; Thu, 14 Oct 2021 11:38:26 +0000 (UTC) Message-ID: <1d3701ab-071b-e92c-6e95-639bdff048de@redhat.com> Date: Thu, 14 Oct 2021 13:38:24 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.1.0 To: Li Feng Cc: Chenbo Xia , JinYu , dev References: <20210827051241.2448098-1-fengli@smartx.com> From: Maxime Coquelin In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=maxime.coquelin@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v1] vhost: add sanity check for resubmiting reqs in split ring X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 10/14/21 13:25, Li Feng wrote: > Thank you for your response. > > On Thu, Oct 14, 2021 at 4:17 PM Maxime Coquelin > wrote: >> >> Hi Li, >> >> Adding Jin Yu who introduced this function. >> >> On 8/27/21 07:12, Li Feng wrote: >>> When getting reqs from the avail ring, the id may exceed inflight >>> queue size. Then the dpdk will crash forever. >> >> You need to add Fixes tag and Cc stable@dpdk.org so that it can be >> backported. > OK, I will send the v2 version. > >> >>> Signed-off-by: Li Feng >>> --- >>> lib/vhost/vhost_user.c | 10 ++++++++-- >>> 1 file changed, 8 insertions(+), 2 deletions(-) >>> >>> diff --git a/lib/vhost/vhost_user.c b/lib/vhost/vhost_user.c >>> index 29a4c9af60..f09d0f6a48 100644 >>> --- a/lib/vhost/vhost_user.c >>> +++ b/lib/vhost/vhost_user.c >>> @@ -1823,8 +1823,14 @@ vhost_check_queue_inflights_split(struct virtio_net *dev, >>> last_io = inflight_split->last_inflight_io; >>> >>> if (inflight_split->used_idx != used->idx) { >>> - inflight_split->desc[last_io].inflight = 0; >>> - rte_atomic_thread_fence(__ATOMIC_SEQ_CST); >>> + if (unlikely(last_io >= inflight_split->desc_num)) { >>> + VHOST_LOG_CONFIG(ERR, "last_inflight_io '%"PRIu16"' exceeds inflight " >>> + "queue size (%"PRIu16").\n", last_io, >>> + inflight_split->desc_num); >> >> If such error happens, shouldn't we return RTE_VHOST_MSG_RESULT_ERR >> instead of just logging an error? > I think ignoring the error is ok. No one could handle this error correctly. > At this time the guest virtio driver of this virtqueue may be in an > incorrect state. Not sure to understand how it can happen. But I see that last_io is actually vq->inflight_split->last_inflight_io, which is set only by rte_vhost_set_last_inflight_io_split() API. Shouldn't there be a sanity check there to ensure that last_inflight_io is smaller than desc_num value set by the frontend? Returning an error is the right thing to do anyway. >> >>> + } else { >>> + inflight_split->desc[last_io].inflight = 0; >>> + rte_atomic_thread_fence(__ATOMIC_SEQ_CST); >>> + } >>> inflight_split->used_idx = used->idx; >>> } >>> >>> >> >> Regards, >> Maxime >> >