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 4AC49A0C4A; Thu, 8 Jul 2021 09:23:34 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1608E4069C; Thu, 8 Jul 2021 09:23:34 +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 DE5AC40687 for ; Thu, 8 Jul 2021 09:23:32 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1625729012; 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=Uqfs3hb5KoZjbauzX4C34CExaGN06jwLRR3slHHDYfU=; b=Fmfev2gvIjFA+puBtfoAvPZNYmj3hp3X39tsvu6jWlihtNVXSHjLaSbvZetSOCEJXVR46b rIld3z1wEx1rarKX1B0kkdIK273ayqSU4fXJ+5NUoLvDm9QulSqikO3VGNoaaSDhzwGkrD 92vxHSQWgXTmKFhlDK5JuDCicr6QL8k= 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-262-FvoFQLRqMV29L9gYNw5GNA-1; Thu, 08 Jul 2021 03:23:31 -0400 X-MC-Unique: FvoFQLRqMV29L9gYNw5GNA-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id EC6265075C; Thu, 8 Jul 2021 07:23:29 +0000 (UTC) Received: from [10.36.110.10] (unknown [10.36.110.10]) by smtp.corp.redhat.com (Postfix) with ESMTPS id BE32360CC9; Thu, 8 Jul 2021 07:23:18 +0000 (UTC) To: David Marchand , dev@dpdk.org, anatoly.burakov@intel.com Cc: ohilyard@iol.unh.edu, stable@dpdk.org, Qi Zhang References: <20210614091213.3953-1-david.marchand@redhat.com> <20210707110230.8695-1-david.marchand@redhat.com> From: Maxime Coquelin Message-ID: Date: Thu, 8 Jul 2021 09:23:16 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <20210707110230.8695-1-david.marchand@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 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-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v2] ipc: stop mp control thread on cleanup 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 7/7/21 1:02 PM, David Marchand wrote: > When calling rte_eal_cleanup, the mp channel cleanup routine only sets > mp_fd to -1 leaving the rte_mp_handle control thread running. > This control thread can spew warnings on reading on an invalid fd. > This is especially noticed with ASAN enabled. > > To handle this situation, set mp_fd to -1 to signal the control thread > it should exit, but since this thread might be sleeping on the socket, > cancel the thread too. > > Fixes: 85d6815fa6d0 ("eal: close multi-process socket during cleanup") > Cc: stable@dpdk.org > > Reported-by: Owen Hilyard > Signed-off-by: David Marchand > --- > Changes since v1: > - no functional change, but left close_socket_fd() helper to keep > symmetry with rte_mp_channel_init()/open_socket_fd(), > > --- > lib/eal/common/eal_common_proc.c | 22 ++++++++++++++-------- > 1 file changed, 14 insertions(+), 8 deletions(-) > Reviewed-by: Maxime Coquelin Thanks, Maxime