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 EAFD3A00C5; Tue, 2 Aug 2022 19:20:39 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B2D6B40A84; Tue, 2 Aug 2022 19:20:39 +0200 (CEST) Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by mails.dpdk.org (Postfix) with ESMTP id CF98540141 for ; Tue, 2 Aug 2022 19:20:38 +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 CE7AF20A78; Tue, 2 Aug 2022 17:20:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1659460837; 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=EXN41zOemRPHK1c0B7FSUVb04vUday/rk52ukt7wdrk=; b=wvGn/6YyuFnycMz7hiV68DCl0lTYYm5QmHY7JWRPJco9kntoEJqbnXc4B7t0pe9S22nj9h YnctCzAEN03N6xlgRLLvd46UEfF95aqAiKjHEq6UZOcFGy8YBk4JpggZ0Lohpgcen9/k66 whMGoJsBbQHIrsaOLdNNU8KryJ7tjJs= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1659460837; 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=EXN41zOemRPHK1c0B7FSUVb04vUday/rk52ukt7wdrk=; b=UwwXYHyij12rOukDw/KYpLvf6RbbjfKDjYkS2h3o0ku0EQ1Im80CHtJKTrRMJSxYaclK4n H79qO1vGjEGI3YBg== 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 A2F9D13A8E; Tue, 2 Aug 2022 17:20:37 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id iscDJuVc6WIwPQAAMHmgww (envelope-from ); Tue, 02 Aug 2022 17:20:37 +0000 Message-ID: <25754484-a44b-65a1-8504-7d268d47c984@suse.de> Date: Tue, 2 Aug 2022 19:20:37 +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 To: Stephen Hemminger Cc: Maxime Coquelin , Chenbo Xia , dev@dpdk.org References: <20220802004938.23670-1-cfontana@suse.de> <20220801183637.23f4add6@hermes.local> From: Claudio Fontana In-Reply-To: <20220801183637.23f4add6@hermes.local> 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 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