From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6C553CDB47E for ; Thu, 12 Oct 2023 13:50:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1379078AbjJLNuX (ORCPT ); Thu, 12 Oct 2023 09:50:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55460 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347293AbjJLNuU (ORCPT ); Thu, 12 Oct 2023 09:50:20 -0400 Received: from mail-qv1-xf36.google.com (mail-qv1-xf36.google.com [IPv6:2607:f8b0:4864:20::f36]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E964091 for ; Thu, 12 Oct 2023 06:50:18 -0700 (PDT) Received: by mail-qv1-xf36.google.com with SMTP id 6a1803df08f44-66d190a8f87so2856576d6.0 for ; Thu, 12 Oct 2023 06:50:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1697118618; x=1697723418; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=LnL6Hnef2NasdmdBgZGxwmWpqimetY/l8WjQZjAdJ28=; b=DABMWPwpBXw305KNDg6onlTw9KiIz6scYsOiVXwH2xVhZTlRTsdpKakbofMh9ZO0iI ejtleNRwNqMTIfefvtysEgj4vxZ5cJZ1BkOVmD2CWdTBNgB6+lm2hFDGwjlzSWEoMMfM 0MmBOcFyeSso9tJaVIEN2Z1kmJb6BoVNBdnjoaubNxUIHgqx9jLY1gAz8yBNOQ2uD2BA oiZl/DmwtxjaGrQGtEsb50BEINQNeEMz92bCh4joXaq5s43kANk85STEXjwajQ1rly89 1IskapWXKgsq9Gf9F2x2GdFWQif9VwiTkx2+ZMzDlUbVj22gaK8Tmsz5C/66GE2cTRBe 1QRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697118618; x=1697723418; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=LnL6Hnef2NasdmdBgZGxwmWpqimetY/l8WjQZjAdJ28=; b=juc16J3qTkZpQJHUGadPcmu39yviitJTBasmn/BsYn2Zpr9bUI8gVt1TvGZ91shts5 f3GjjkVBC4eeNnYCNny8YJjlaRmwoGrMPIffFT6n+S7zQ5Xf3GAuOQkOUnB5i0eVQK73 7KG2uGibJ9jDP9Ih2mnk4TE+OtvEhEMVfQi1ljIptWGCcNoJfA7tRVIeVz7OBqQlZE8Y TmjhMI5h3zLHcYL5+Hm9ABwUw3WFs8uq3qN58NLi18E+E0yyXiUfFVFCJf75fKarNMBU 2HN7r0ogmCgxCQMLtJwOaXx4HKqDEYKH+Hn/pfRE4C+VgKCPrf6h6kzSbBd9zcKuccOQ 1pwQ== X-Gm-Message-State: AOJu0YzMctykFhVJO5RrZ1K1IL11txi0Mjp+K4YPOug8AvCDzpbrXN/W 6imhki0IN9xkuMF+kbE9H4v5Tw== X-Google-Smtp-Source: AGHT+IHRiGoFwFv2FYMS1d7JQeLsjrqR5yecWQjBMOOK2SnAreo0qN3NXTS57EzrnG/Mal6+CvR4sg== X-Received: by 2002:a05:6214:240e:b0:66d:1edd:1d4c with SMTP id fv14-20020a056214240e00b0066d1edd1d4cmr406180qvb.14.1697118618028; Thu, 12 Oct 2023 06:50:18 -0700 (PDT) Received: from ziepe.ca (hlfxns017vw-142-68-26-201.dhcp-dynamic.fibreop.ns.bellaliant.net. [142.68.26.201]) by smtp.gmail.com with ESMTPSA id p9-20020a0cf549000000b0065b17ec4b49sm6654706qvm.46.2023.10.12.06.50.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 12 Oct 2023 06:50:17 -0700 (PDT) Received: from jgg by wakko with local (Exim 4.95) (envelope-from ) id 1qqw4u-0018jt-UD; Thu, 12 Oct 2023 10:50:16 -0300 Date: Thu, 12 Oct 2023 10:50:16 -0300 From: Jason Gunthorpe To: Shameerali Kolothum Thodi Cc: Brett Creeley , "yishaih@nvidia.com" , "kevin.tian@intel.com" , "alex.williamson@redhat.com" , "dan.carpenter@linaro.org" , "kvm@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "shannon.nelson@amd.com" Subject: Re: [PATCH v2 vfio 2/3] pds/vfio: Fix mutex lock->magic != lock warning Message-ID: <20231012135016.GJ55194@ziepe.ca> References: <20231011230115.35719-1-brett.creeley@amd.com> <20231011230115.35719-3-brett.creeley@amd.com> <591f90f071454dcd82d8de1178241e3c@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <591f90f071454dcd82d8de1178241e3c@huawei.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Oct 12, 2023 at 09:00:09AM +0000, Shameerali Kolothum Thodi wrote: > > Also, don't destroy the mutex on close because the device may > > be re-opened, which would cause mutex to be uninitialized. Fix this by > > implementing a driver specific vfio_device_ops.release callback that > > destroys the mutex before calling vfio_pci_core_release_dev(). > > > > Signed-off-by: Brett Creeley > > Reviewed-by: Shannon Nelson > > Reviewed-by: Shameer Kolothum > > Looks like mutex destruction logic needs to be added to HiSilicon driver as well. > From a quick look mlx5 also doesn't destroy the state_mutex. FWIW, mutex_destroy is a debugging feature, it is nice if you can do it, but not a bug if it is missing.. Jason