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 95B9DA00C4; Thu, 4 Aug 2022 12:32:41 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 35D464282B; Thu, 4 Aug 2022 12:32:41 +0200 (CEST) Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by mails.dpdk.org (Postfix) with ESMTP id E2CEF4281B for ; Thu, 4 Aug 2022 12:32:39 +0200 (CEST) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id A72811FD05; Thu, 4 Aug 2022 10:32:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1659609159; h=from:from:reply-to: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=19gkFdiHhv/rWGMwusuxRs3C/seuOv/+SL6c+xC2Zg4=; b=1s8yul/2A1aS6nVBO3NMx/2bA5ndKK6MlCO9YvP0JwDRvhhV0lMzTrSIKxkiHt2WKStESu Y+XsvjE9fh68CmcV8XPIiCajmS4XBb4UlLDADTCyW8eTTylr+GFdv6+zG8ZRFCcxToypBg L3HaS5kE7y830KJkEeYsvOmjDqxBAgQ= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1659609159; h=from:from:reply-to: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=19gkFdiHhv/rWGMwusuxRs3C/seuOv/+SL6c+xC2Zg4=; b=UNJtF32i9Ht6yohh/9s8gi1zlL88VMdnAUF7lRbjwihDToM9bGYEEFkH6h04glvvQkS6in nNFNe+R2XLQDOXAg== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 7C77913A94; Thu, 4 Aug 2022 10:32:39 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id L3gDD0eg62J4EQAAMHmgww (envelope-from ); Thu, 04 Aug 2022 10:32:39 +0000 Message-ID: Date: Thu, 4 Aug 2022 12:32:38 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Subject: Re: [PATCH v3 0/2] vhost fixes for OVS SIGSEGV in PMD Content-Language: en-US From: Claudio Fontana To: Stephen Hemminger Cc: Maxime Coquelin , Chenbo Xia , dev@dpdk.org References: <20220802004938.23670-1-cfontana@suse.de> <20220801183637.23f4add6@hermes.local> <25754484-a44b-65a1-8504-7d268d47c984@suse.de> In-Reply-To: <25754484-a44b-65a1-8504-7d268d47c984@suse.de> Content-Type: text/plain; charset=UTF-8 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 8/2/22 19:20, Claudio Fontana wrote: > On 8/2/22 03:40, Stephen Hemminger wrote: >> On Tue, 2 Aug 2022 02:49:36 +0200 >> Claudio Fontana wrote: >> >>> This is an alternative, more general fix compared with PATCH v1, >>> and fixes style issues in v2. >>> >>> The series fixes a segmentation fault in the OVS PMD thread when >>> resynchronizing with QEMU after the guest application has been killed >>> with SIGKILL (patch 1/2), >>> >>> The segmentation fault can be caused by the guest DPDK application, >>> which is able this way to crash the OVS process on the host, >>> see the backtrace in patch 1/2. >>> >>> Patch 2/2 is an additional improvement in the current error handling. >> >> Checking for NULL and 0 is good on host side. >> But guest should probably not be sending such a useless request? > > > Right, I focused on hardening the host side, as that is what the customer required. > > This happens specifically when the guest application goes away abruptly and has no chance to signal anything (SIGKILL), > and at restart issues a virtio reset on the device, which in qemu causes also a (actually two) virtio_net set_status, which attempt to stop the queues (twice). > > DPDK seems to think at that point that it needs to drain the queue, and tries to process MAX_PKT_BURST buffers > ("about to dequeue 32 buffers"), > > then calls fill_vec_buf_split and gets absolutely nothing. > > I think this should also address the reports in this thread: > > https://inbox.dpdk.org/dev/SA1PR08MB713373B0D19329C38C7527BB839A9@SA1PR08MB7133.namprd08.prod.outlook.com/ > > in addition to my specific customer request, > > Thanks, > > Claudio anything more required from my side? Do you need a respin without the "Tested-by" tag? Thanks, Claudio