From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (xvm-189-124.dc0.ghst.net [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id E81F5A0524; Fri, 8 Jan 2021 09:48:46 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 3AC07140EBB; Fri, 8 Jan 2021 09:48:46 +0100 (CET) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by mails.dpdk.org (Postfix) with ESMTP id 461BF140EAE for ; Fri, 8 Jan 2021 09:48:45 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1610095724; 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: in-reply-to:in-reply-to:references:references; bh=tMtow1GLVZINDCiLyeibp7ypSxPj6bRemRlxabOAsD8=; b=Hw1CtiSxfxXtq/LkeE7TfcPOwhu1lHKSpsCVZYXdFh+G2B0vK3ItW/nW79rPBp6ZNR20im B+sUCOHMRurfaPqNadL3G+Ay/D71nRPTrLvbfkY9NW7TnmPyyKHBytWDLMOVSIvdbitiGl Tq9t3YnGO95HlfXOtVxLODAlWWEhXmo= Received: from mail-vk1-f199.google.com (mail-vk1-f199.google.com [209.85.221.199]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-168-hFUSyi2POviN3muMIsyR0w-1; Fri, 08 Jan 2021 03:48:43 -0500 X-MC-Unique: hFUSyi2POviN3muMIsyR0w-1 Received: by mail-vk1-f199.google.com with SMTP id s127so5187163vka.11 for ; Fri, 08 Jan 2021 00:48:43 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tMtow1GLVZINDCiLyeibp7ypSxPj6bRemRlxabOAsD8=; b=EjnIJsDOYwKSesczgeJ6LNRBStqE5ekVZ75Tb4PyRo2bzG0PeLXr9tBhl0Rc38q8mY F+qYS8sBLgK0T7/vbuVrBW1Tm97Cn4eKtiCjivCd+q2sinEwOuOo5BS1X2kfHqnjIqdi EtvrK4S18pSyLL84vduSNSi2edRcb8fuptTL1YClvV4HuPew1b1aH4Krps1RcHOhYSin RHD61umzVaA1oTI9b8ixZq05KgSurBTBl85cgvXqPtd2i+3q9w8FFkRIx6UX4ZqJwjVh bVqZmFgYDSF3AYa7pCAt46MLfpZHDosJnPVNDaeIwTHP7RI2WbqCcpIMs1056tP5iMLT i7qQ== X-Gm-Message-State: AOAM531ELqbpU4FO12p0Vbdfae2iQSnXZsrY8By2l9b0z0U9X7wslTfX G42Og/A/Yoc2Jb2Zk4420IjQamN+NN2w9QYEATeZif7BBYnfOJSZ/BTBjxzht7H1Q0n1MYnyTiP ZVym73hIZX83GZ7Ida7g= X-Received: by 2002:a1f:9e83:: with SMTP id h125mr5072153vke.18.1610095722784; Fri, 08 Jan 2021 00:48:42 -0800 (PST) X-Google-Smtp-Source: ABdhPJy6fGMKjv/WZX+4c/eyhDhkiRAx/QqRmwlEQc9Wda3ILHpgVOs7ok4zKOt3xXcpXLucoN2fb9zDOCRrQDs4xPE= X-Received: by 2002:a1f:9e83:: with SMTP id h125mr5072149vke.18.1610095722599; Fri, 08 Jan 2021 00:48:42 -0800 (PST) MIME-Version: 1.0 References: <1609915409-272126-1-git-send-email-matan@nvidia.com> <746e905a-c394-44df-2c49-2afd59c05d9f@redhat.com> In-Reply-To: <746e905a-c394-44df-2c49-2afd59c05d9f@redhat.com> From: David Marchand Date: Fri, 8 Jan 2021 09:48:31 +0100 Message-ID: To: Maxime Coquelin , Matan Azrad Cc: dev , dpdk stable Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dmarchan@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [dpdk-stable] [PATCH] vdpa/mlx5: fix configuration mutex 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 Thu, Jan 7, 2021 at 7:09 PM Maxime Coquelin wrote: > On 1/6/21 7:43 AM, Matan Azrad wrote: > > When the vDPA device is closed, the driver polling thread is canceled. > > The polling thread locks the configuration mutex while it polls the CQs. > > > > When the cancellation happens, it may terminate the thread inside the > > critical section what remains the configuration mutex locked. > > > > After device close, the driver may be configured again, in this case, > > for example, when the first queue state is updated, the driver tries to > > lock the mutex again and deadlock appears. > > > > Initialize the mutex after the polling thread cancellation. > > > > Fixes: 99abbd62c272 ("vdpa/mlx5: fix queue update synchronization") > > Cc: stable@dpdk.org > > > > Signed-off-by: Matan Azrad > > Acked-by: Xueming Li > > --- > > drivers/vdpa/mlx5/mlx5_vdpa.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/drivers/vdpa/mlx5/mlx5_vdpa.c b/drivers/vdpa/mlx5/mlx5_vdpa.c > > index b64f364..0b2f1ab 100644 > > --- a/drivers/vdpa/mlx5/mlx5_vdpa.c > > +++ b/drivers/vdpa/mlx5/mlx5_vdpa.c > > @@ -295,6 +295,8 @@ > > } > > priv->configured = 0; > > priv->vid = 0; > > + /* The mutex may stay locked after event thread cancel - initiate it. */ > > + pthread_mutex_init(&priv->vq_config_lock, NULL); > > DRV_LOG(INFO, "vDPA device %d was closed.", vid); > > return ret; > > } > > > > I wonder if it would be possible and cleaner to disable cancellation on > the thread while the mutex is held? +1 -- David Marchand