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 4392AA0A02 for ; Thu, 14 Jan 2021 15:28:11 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 103C81412C8; Thu, 14 Jan 2021 15:28:11 +0100 (CET) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by mails.dpdk.org (Postfix) with ESMTP id AECED1412C8 for ; Thu, 14 Jan 2021 15:28:09 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1610634488; 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=wCAkvPKA/RCyGkVj5uYANdipLOJA6TuVYMVUd8/Vaio=; b=Fz36k0e84zVo+vr89p8cSqZ7FcfhzKK+qjdrgCcLGWU6z2sQamcZN50P+hNJCCT01yUbwc oPNCQrwMq08vU86k4+rfK+COv5ofieMKsiI77Ryk5NG+LoFg4Lajcnfw2HtdmurSznd645 B2kz1DVRVsq6wEVTBaU7jKyWCGxxYfM= 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-153-WMFXtv_8PxKtfaYJwQgdtQ-1; Thu, 14 Jan 2021 09:28:07 -0500 X-MC-Unique: WMFXtv_8PxKtfaYJwQgdtQ-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id C6BC8A0CAF; Thu, 14 Jan 2021 14:28:05 +0000 (UTC) Received: from [10.36.110.24] (unknown [10.36.110.24]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 955A91992D; Thu, 14 Jan 2021 14:28:00 +0000 (UTC) To: Matan Azrad , David Marchand Cc: dev , dpdk stable References: <1609915409-272126-1-git-send-email-matan@nvidia.com> <746e905a-c394-44df-2c49-2afd59c05d9f@redhat.com> <1052520c-61e9-2135-bbad-9d009f52ce4b@redhat.com> From: Maxime Coquelin Message-ID: <1c1fdabf-2588-2fd7-f5c4-dcb4e029ac35@redhat.com> Date: Thu, 14 Jan 2021 15:27:58 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 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-stable] [PATCH] vdpa/mlx5: fix configuration mutex cleanup X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org Sender: "stable" On 1/14/21 2:09 PM, Matan Azrad wrote: > > > From: Maxime Coquelin >> Hi Matan, >> >> On 1/14/21 12:49 PM, Matan Azrad wrote: >>> Hi Maxime and David >>> >>> Thank you for Review. >>> >>> From: David Marchand >>>> On Fri, Jan 8, 2021 at 9:48 AM David Marchand >>>> wrote: >>>>>> I wonder if it would be possible and cleaner to disable >>>>>> cancellation on the thread while the mutex is held? >>> >>> Yes, we can cause thread to return by some global variable sync. >>> It is the same logic. >> >> No, that was not my suggestion. My suggestion is to block the thread >> cancellation while in the critical section, using pthread_setcancelstate(). > > Yes, Generally it is better to let the thread control his cancellation, either cancel itself or enabling\disabling cancellations. > > I don't see a reason to wait for the thread in current logic - the critical section is not important to be completed here. The reason I see is there are quite a few things done in this critical section. And if tomorrow someone add new things in it, he may not know the thread can be cancelled at any time, which could cause hard to debug issues. > We just want to close the thread and to clean the mutex. > >>>>> +1 >>>> >>>> IEEE Std 1003.1-2001/Cor 2-2004, item XBD/TC2/D6/26 is applied, >>>> adding pthread_t to the list of types that are not required to be >>>> arithmetic types, thus allowing pthread_t to be defined as a structure. >>>> >>>> It would be better to leave pthread_t alone and not interpret it: >>>> >>>> if (priv->timer_tid) { >>>> pthread_cancel(priv->timer_tid); >>>> pthread_join(priv->timer_tid, &status); } >>>> priv->timer_tid = 0; >>> >>> >>> I'm not sure why you think it is better in this specific case. >>> The cancellation will close the thread in faster way, no need to wait for the >> thread to close itself. >>> >>> >>>> >>>> -- >>>> David Marchand >>> >