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 D7788A00C4; Fri, 30 Sep 2022 12:22:46 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id BD95740E5A; Fri, 30 Sep 2022 12:22:46 +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 CCDFC40684 for ; Fri, 30 Sep 2022 12:22:45 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1664533365; 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=eLEUxWk5xIuHlSMk0tvdNX+kDLzOkXpbnazgrywr7pw=; b=WlJwLl8ePrJvEFO8UTTeBZ9oBXDrxHjhbqnqG2Uuw7FhWwbLc6d5tmmZhjjOdguq9N+LlN JlWNL1zy76wytwG9lkNal0GpWKFiBKAo7cT33GGknyI9B2LF52Sk/sbPc0sGB08ZJrexNh Mk1Ndat2GCt7ttl5mYcu59f2tQvdZMw= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-326--Bqjz0zOM5SqdHZ-0jqhrg-1; Fri, 30 Sep 2022 06:22:44 -0400 X-MC-Unique: -Bqjz0zOM5SqdHZ-0jqhrg-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id D6654811E81; Fri, 30 Sep 2022 10:22:43 +0000 (UTC) Received: from [10.39.208.19] (unknown [10.39.208.19]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 0786E40C206B; Fri, 30 Sep 2022 10:22:42 +0000 (UTC) Message-ID: Date: Fri, 30 Sep 2022 12:22:41 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.0 To: Thomas Monjalon , Claudio Fontana Cc: Chenbo Xia , dev@dpdk.org References: <20220802004938.23670-1-cfontana@suse.de> <228bf109-57c2-91f0-ab2c-6ac92d688781@redhat.com> <77f63478-88d1-01b2-0cdd-c93289bd42a6@suse.de> <5662486.1B3tZ46Xf9@thomas> From: Maxime Coquelin Subject: Re: [PATCH v3 1/2] vhost: check for nr_vec == 0 in desc_to_mbuf, mbuf_to_desc In-Reply-To: <5662486.1B3tZ46Xf9@thomas> X-Scanned-By: MIMEDefang 3.1 on 10.11.54.1 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 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 On 9/28/22 18:03, Thomas Monjalon wrote: > 28/09/2022 17:21, Claudio Fontana: >> On 9/28/22 16:37, Maxime Coquelin wrote: >>> The title should be reworded, maybe something like below? >>> "vhost: fix possible out of bound access in buffer vectors" >> >> possible, I leave it to you and other maintainers here now to figure out. > > Maxime is suggesting a reword to you for your next version. > >>> On 8/2/22 02:49, Claudio Fontana wrote: > [...] >>>> This should fix errors that have been reported in multiple occasions >>>> from telcos to the DPDK, OVS and QEMU projects, as this affects in >>>> particular the openvswitch/DPDK, QEMU vhost-user setup when the >>>> guest DPDK application abruptly goes away via SIGKILL and then >>>> reconnects. > > What are the "multiple occasions"? Is there an entry in bugs.dpdk.org? > > [...] >>> I'm going to try to reproduce the issue, but I'm not sure I will >>> succeed. Could you please share the Vhost logs when the issue is >>> reproduced and you face the crash? >> >> With vacations and lab work it's unlikely anything can be done from my side for the next 2-3 weeks. > > We can probably wait 3 more weeks. Yes please, because I fail to reproduce it (Fc35 on host, Ubuntu 18.05 in guest). What I can see is that on guest testpmd crash, the host backend receives VHOST_USER_GET_VRING_BASE requests that stop the vring processing. on reconnect, the rings start to be processed only when it received all the configuration requests from QEMU. Note that I have tested it with VFIO in the guest because I could not find the uio_pci_generic module in Ubuntu 18.04 cloud image. >> This issue has been reported multiple times from multiple telco customers for about a year, it's all over the mailing lists >> between ovs, dpdk and qemu, with all the details. > > What was the reply on the DPDK mailing list? Any link? Please provide the links, it may help to understand the root cause if these mail threads contain logs. > >> Something in the governance of these Open Source projects is clearly not working right, probably too much inward-focus between a small number of companies, but I digress. > > Contributors to DPDK are from multiple companies, > but I agree we may need more help. > Thank you for bringing your help with this fix. > >> I think Chenbo Xia already knows the context, and I suspect this is now considered a "security issue". The problem is, the information about all of this has been public already for a year. > > OK > >> I will again repost how to reproduce here: > > Thanks it helps to have all infos in the same place. > > [...] > >>> It is a fix, so it should contains the Fixes tag, and also cc >>> stable@dpdk.org. >> >> After one year, it is time for Redhat and Intel or whatever the governance of this project is, > > The DPDK governance is not owned by any company. > If you think there is an issue in a decision, > you can alert the Technical Board at techboard@dpdk.org. > >> to mention if there is any intention to fix this or not, >> before I or anyone else at SUSE will invest any more of our time and efforts here. > > I don't understand why we would not fix any issue. > I think the project is quite dynamic and fixing issues, > I am sorry if you have a different opinion. > >> Any tags you need you can add as required. > > It would be nice to add the tags as suggested in the next version. > The most important would be to know where the issue comes from. > If you can identify the original commit introducing the bug, > you can mark it with: > Fixes: ("") > This way, maintainers and users know where it should be backported. > > If any question, feel free to ask, we are here to help. > Thanks for the effort > >