Message ID | 20231129222132.2331261-2-david.e.box@linux.intel.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:6359:296:b0:164:83eb:24d7 with SMTP id ek22csp15911rwb; Wed, 29 Nov 2023 14:22:17 -0800 (PST) X-Google-Smtp-Source: AGHT+IHhHhvAuNJcyUZqTzpx9NLAMbMVha3IWiSqEBjGrk9dc0KxH6xhFQN4hhKac9xNL0NdhB6L X-Received: by 2002:a9d:6944:0:b0:6d8:11f1:de4d with SMTP id p4-20020a9d6944000000b006d811f1de4dmr16298787oto.32.1701296537525; Wed, 29 Nov 2023 14:22:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1701296537; cv=none; d=google.com; s=arc-20160816; b=ZtXoQm41WIuamFx/sjGWjf2xZvhtt6JvicT9F3t0UzEePCid18zkXTZAFuWh4TeYlD 3UXKbkAsHbtG5naIuD4JHdlhZqRZ/JJLKoYFpBckss+JMOnqANvVtwTqnpabcsx/yZVp lbR51aSZu8VVtwMyu4gkygcSrukJbsEuuXeW6s5AILo8++t8wQ+mM34R0tWGFBJtbaFY ++HyIFS4xq/Z247NNbED7J8yT5404FbCaEbiZL0wUVMXL2ZDwAmuaOhYMrhhsnhw8rX6 DbSUG9VfV7O2CKVTghOhcj8puOZQZR4ukmBB/nj7DSjllX1jztOS6ykB8oW63Vfo0qHD 3d/w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:to:from :dkim-signature; bh=pmtO/fwM6eGEILtqqEp1XK6hsK6Cb7U85c0jAj2+mZY=; fh=d9G4dsZtlI8UONIvGKwhW94hCYEPGxy6CqYeKEG646A=; b=wfyAfe1De/0h1aZ66p8VItrh0J8lida9kG8/7vtE7LLEadnIMv/L+acbytQqc1ojv9 Drzl1bML0b0yA6q6THtupUmA3w/dfQ6vvpkQC5qBOnudjPknLj9OXP77W9CUF2qDbksG t0r7PERIhh/Ve1wJB7LMBtX2/fcLy+5KkJRn+b+hfh2mZmrFD1JdMkVnh7lCCNDzXHeV xfqyjlsD5JiVB2I9T1iqJDFWO9kq4puZ5QkjF4rqW5PIiiVgZEtDqdQoTg6ENzaChNIq 2PoC/UJ5oPvStlOqy2xY+fiN58CJvtxsWzbnfTubNfvsg4PdjVLcwrrIU18OpL5db2lk YaTA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=bI+BVPTi; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from lipwig.vger.email (lipwig.vger.email. [2620:137:e000::3:3]) by mx.google.com with ESMTPS id bi5-20020a056a02024500b005c203ad2343si16830829pgb.94.2023.11.29.14.22.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 Nov 2023 14:22:17 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) client-ip=2620:137:e000::3:3; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=bI+BVPTi; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by lipwig.vger.email (Postfix) with ESMTP id DD66C803110A; Wed, 29 Nov 2023 14:22:08 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at lipwig.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234937AbjK2WVo (ORCPT <rfc822;realc9580@gmail.com> + 99 others); Wed, 29 Nov 2023 17:21:44 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38966 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234861AbjK2WVe (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 29 Nov 2023 17:21:34 -0500 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.9]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6A3D5C1; Wed, 29 Nov 2023 14:21:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1701296500; x=1732832500; h=from:to:subject:date:message-id:in-reply-to:references: mime-version:content-transfer-encoding; bh=/oyzykdSt+VTIrV0ILfyr4YDLUq4rAc6Mhdr6VxDMvw=; b=bI+BVPTi03S0ruJulXVDE7POVOktWBXYEOrEdVWuXvqjcn6cYPjbl1nJ Oi/Wc7VkOyJBhXJbnbZFa4HbBwWw3f3HZKi2Zd2uv9uvqNGsdJaFpakpr 1D1JORkiBpIMA+eHMhs1qvZakpI1qgv3W+wK5dwkYqDFPGNtYiAqDGzEC u3WmF9KvdXWAFStNUYjEQyUmJOV/VezdeGtJUo8a2dxAZHIH/DYgPpjSe VY5F16oY21+zZFf/hRt68+42nYTO7u61mDQ2lO5HltAChluqAc8ajxpWz jymMkpN5nH0xLeYWLySLSngG6bosEdi7qRM9NoFsYMw5+I0sDRRdggp8r g==; X-IronPort-AV: E=McAfee;i="6600,9927,10909"; a="11936990" X-IronPort-AV: E=Sophos;i="6.04,237,1695711600"; d="scan'208";a="11936990" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orvoesa101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Nov 2023 14:21:35 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10909"; a="798070410" X-IronPort-AV: E=Sophos;i="6.04,237,1695711600"; d="scan'208";a="798070410" Received: from linux.intel.com ([10.54.29.200]) by orsmga008.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Nov 2023 14:21:32 -0800 Received: from debox1-desk4.lan (unknown [10.209.108.167]) by linux.intel.com (Postfix) with ESMTP id B8254580BF8; Wed, 29 Nov 2023 14:21:32 -0800 (PST) From: "David E. Box" <david.e.box@linux.intel.com> To: linux-kernel@vger.kernel.org, platform-driver-x86@vger.kernel.org, ilpo.jarvinen@linux.intel.com, rajvi.jingar@linux.intel.com Subject: [PATCH V6 01/20] platform/x86/intel/vsec: Fix xa_alloc memory leak Date: Wed, 29 Nov 2023 14:21:13 -0800 Message-Id: <20231129222132.2331261-2-david.e.box@linux.intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20231129222132.2331261-1-david.e.box@linux.intel.com> References: <20231129222132.2331261-1-david.e.box@linux.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lipwig.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (lipwig.vger.email [0.0.0.0]); Wed, 29 Nov 2023 14:22:09 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1783938718067281158 X-GMAIL-MSGID: 1783938718067281158 |
Series |
intel_pmc: Add telemetry API to read counters
|
|
Commit Message
David E. Box
Nov. 29, 2023, 10:21 p.m. UTC
Commit 936874b77dd0 ("platform/x86/intel/vsec: Add PCI error recovery
support to Intel PMT") added an xarray to track the list of vsec devices to
be recovered after a PCI error. But it did not provide cleanup for the list
leading to a memory leak that was caught by kmemleak. Do xa_alloc() before
devm_add_action_or_reset() so that the list may be cleaned up with
xa_erase() in the release function.
Fixes: 936874b77dd0 ("platform/x86/intel/vsec: Add PCI error recovery support to Intel PMT")
Signed-off-by: David E. Box <david.e.box@linux.intel.com>
---
V6 - Move xa_alloc() before ida_alloc() to reduce mutex use during error
recovery.
- Fix return value after id_alloc() fail
- Add Fixes tag
- Add more detail to changelog
V5 - New patch
drivers/platform/x86/intel/vsec.c | 24 ++++++++++++++----------
drivers/platform/x86/intel/vsec.h | 1 +
2 files changed, 15 insertions(+), 10 deletions(-)
Comments
On Wed, 29 Nov 2023, David E. Box wrote: > Commit 936874b77dd0 ("platform/x86/intel/vsec: Add PCI error recovery > support to Intel PMT") added an xarray to track the list of vsec devices to > be recovered after a PCI error. But it did not provide cleanup for the list > leading to a memory leak that was caught by kmemleak. Do xa_alloc() before > devm_add_action_or_reset() so that the list may be cleaned up with > xa_erase() in the release function. > > Fixes: 936874b77dd0 ("platform/x86/intel/vsec: Add PCI error recovery support to Intel PMT") > Signed-off-by: David E. Box <david.e.box@linux.intel.com> > --- > > V6 - Move xa_alloc() before ida_alloc() to reduce mutex use during error > recovery. > - Fix return value after id_alloc() fail > - Add Fixes tag > - Add more detail to changelog > > V5 - New patch > > drivers/platform/x86/intel/vsec.c | 24 ++++++++++++++---------- > drivers/platform/x86/intel/vsec.h | 1 + > 2 files changed, 15 insertions(+), 10 deletions(-) > > diff --git a/drivers/platform/x86/intel/vsec.c b/drivers/platform/x86/intel/vsec.c > index c1f9e4471b28..2d568466b4e2 100644 > --- a/drivers/platform/x86/intel/vsec.c > +++ b/drivers/platform/x86/intel/vsec.c > @@ -120,6 +120,8 @@ static void intel_vsec_dev_release(struct device *dev) > { > struct intel_vsec_device *intel_vsec_dev = dev_to_ivdev(dev); > > + xa_erase(&auxdev_array, intel_vsec_dev->id); > + > mutex_lock(&vsec_ida_lock); > ida_free(intel_vsec_dev->ida, intel_vsec_dev->auxdev.id); > mutex_unlock(&vsec_ida_lock); > @@ -135,19 +137,27 @@ int intel_vsec_add_aux(struct pci_dev *pdev, struct device *parent, > struct auxiliary_device *auxdev = &intel_vsec_dev->auxdev; > int ret, id; > > - mutex_lock(&vsec_ida_lock); > - ret = ida_alloc(intel_vsec_dev->ida, GFP_KERNEL); > - mutex_unlock(&vsec_ida_lock); > + ret = xa_alloc(&auxdev_array, &intel_vsec_dev->id, intel_vsec_dev, > + PMT_XA_LIMIT, GFP_KERNEL); > if (ret < 0) { > kfree(intel_vsec_dev->resource); > kfree(intel_vsec_dev); > return ret; > } > > + mutex_lock(&vsec_ida_lock); > + id = ida_alloc(intel_vsec_dev->ida, GFP_KERNEL); > + mutex_unlock(&vsec_ida_lock); > + if (id < 0) { > + kfree(intel_vsec_dev->resource); > + kfree(intel_vsec_dev); > + return id; Thanks, this looks much better this way around but it is missing xa_alloc() rollback now that the order is reversed. Once that is fixed, Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Hi, On 11/30/23 12:02, Ilpo Järvinen wrote: > On Wed, 29 Nov 2023, David E. Box wrote: > >> Commit 936874b77dd0 ("platform/x86/intel/vsec: Add PCI error recovery >> support to Intel PMT") added an xarray to track the list of vsec devices to >> be recovered after a PCI error. But it did not provide cleanup for the list >> leading to a memory leak that was caught by kmemleak. Do xa_alloc() before >> devm_add_action_or_reset() so that the list may be cleaned up with >> xa_erase() in the release function. >> >> Fixes: 936874b77dd0 ("platform/x86/intel/vsec: Add PCI error recovery support to Intel PMT") >> Signed-off-by: David E. Box <david.e.box@linux.intel.com> >> --- >> >> V6 - Move xa_alloc() before ida_alloc() to reduce mutex use during error >> recovery. >> - Fix return value after id_alloc() fail >> - Add Fixes tag >> - Add more detail to changelog >> >> V5 - New patch >> >> drivers/platform/x86/intel/vsec.c | 24 ++++++++++++++---------- >> drivers/platform/x86/intel/vsec.h | 1 + >> 2 files changed, 15 insertions(+), 10 deletions(-) >> >> diff --git a/drivers/platform/x86/intel/vsec.c b/drivers/platform/x86/intel/vsec.c >> index c1f9e4471b28..2d568466b4e2 100644 >> --- a/drivers/platform/x86/intel/vsec.c >> +++ b/drivers/platform/x86/intel/vsec.c >> @@ -120,6 +120,8 @@ static void intel_vsec_dev_release(struct device *dev) >> { >> struct intel_vsec_device *intel_vsec_dev = dev_to_ivdev(dev); >> >> + xa_erase(&auxdev_array, intel_vsec_dev->id); >> + >> mutex_lock(&vsec_ida_lock); >> ida_free(intel_vsec_dev->ida, intel_vsec_dev->auxdev.id); >> mutex_unlock(&vsec_ida_lock); >> @@ -135,19 +137,27 @@ int intel_vsec_add_aux(struct pci_dev *pdev, struct device *parent, >> struct auxiliary_device *auxdev = &intel_vsec_dev->auxdev; >> int ret, id; >> >> - mutex_lock(&vsec_ida_lock); >> - ret = ida_alloc(intel_vsec_dev->ida, GFP_KERNEL); >> - mutex_unlock(&vsec_ida_lock); >> + ret = xa_alloc(&auxdev_array, &intel_vsec_dev->id, intel_vsec_dev, >> + PMT_XA_LIMIT, GFP_KERNEL); >> if (ret < 0) { >> kfree(intel_vsec_dev->resource); >> kfree(intel_vsec_dev); >> return ret; >> } >> >> + mutex_lock(&vsec_ida_lock); >> + id = ida_alloc(intel_vsec_dev->ida, GFP_KERNEL); >> + mutex_unlock(&vsec_ida_lock); >> + if (id < 0) { >> + kfree(intel_vsec_dev->resource); >> + kfree(intel_vsec_dev); >> + return id; > > Thanks, this looks much better this way around but it is missing > xa_alloc() rollback now that the order is reversed. > > Once that is fixed, > > Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> I have fixed this up, adding the missing: xa_erase(&auxdev_array, intel_vsec_dev->id); to this error-exit path while merging this. While looking into this I did find one other thing which worries me (different issue, needs a separate fix): intel_vsec_pci_slot_reset() uses devm_release_action(&pdev->dev, intel_vsec_remove_aux, &intel_vsec_dev->auxdev); and seems to assume that after this intel_vsec_remove_aux() has run for the auxdev-s. *But this is not the case* devm_release_action() only removes the action from the list of devres resources tied to the parent PCI device. It does *NOT* call the registered action function, so intel_vsec_remove_aux() is NOT called here. And then on re-probing the device as is done in intel_vsec_pci_slot_reset() a second set of aux devices with the same parent will be created AFAICT. So it seems that this also needs an explicit intel_vsec_remove_aux() call for each auxdev! ### This makes me wonder if the PCI error handling here and specifically the reset code was ever tested ? ### Note that simply forcing a reprobe using device_reprobe() will cause all the aux-devices to also get removed through the action on driver-unbind without ever needing the auxdev_array at all! I guess that you want the removal to happen before the pci_restore_state(pdev) state though, so that simply relying on the removal on driver unbind is not an option ? Regards, Hans
Hi Hans, On Mon, 2023-12-04 at 14:51 +0100, Hans de Goede wrote: > Hi, > > On 11/30/23 12:02, Ilpo Järvinen wrote: > > On Wed, 29 Nov 2023, David E. Box wrote: > > > > > Commit 936874b77dd0 ("platform/x86/intel/vsec: Add PCI error recovery > > > support to Intel PMT") added an xarray to track the list of vsec devices > > > to > > > be recovered after a PCI error. But it did not provide cleanup for the > > > list > > > leading to a memory leak that was caught by kmemleak. Do xa_alloc() > > > before > > > devm_add_action_or_reset() so that the list may be cleaned up with > > > xa_erase() in the release function. > > > > > > Fixes: 936874b77dd0 ("platform/x86/intel/vsec: Add PCI error recovery > > > support to Intel PMT") > > > Signed-off-by: David E. Box <david.e.box@linux.intel.com> > > > --- > > > > > > V6 - Move xa_alloc() before ida_alloc() to reduce mutex use during error > > > recovery. > > > - Fix return value after id_alloc() fail > > > - Add Fixes tag > > > - Add more detail to changelog > > > > > > V5 - New patch > > > > > > drivers/platform/x86/intel/vsec.c | 24 ++++++++++++++---------- > > > drivers/platform/x86/intel/vsec.h | 1 + > > > 2 files changed, 15 insertions(+), 10 deletions(-) > > > > > > diff --git a/drivers/platform/x86/intel/vsec.c > > > b/drivers/platform/x86/intel/vsec.c > > > index c1f9e4471b28..2d568466b4e2 100644 > > > --- a/drivers/platform/x86/intel/vsec.c > > > +++ b/drivers/platform/x86/intel/vsec.c > > > @@ -120,6 +120,8 @@ static void intel_vsec_dev_release(struct device *dev) > > > { > > > struct intel_vsec_device *intel_vsec_dev = dev_to_ivdev(dev); > > > > > > + xa_erase(&auxdev_array, intel_vsec_dev->id); > > > + > > > mutex_lock(&vsec_ida_lock); > > > ida_free(intel_vsec_dev->ida, intel_vsec_dev->auxdev.id); > > > mutex_unlock(&vsec_ida_lock); > > > @@ -135,19 +137,27 @@ int intel_vsec_add_aux(struct pci_dev *pdev, struct > > > device *parent, > > > struct auxiliary_device *auxdev = &intel_vsec_dev->auxdev; > > > int ret, id; > > > > > > - mutex_lock(&vsec_ida_lock); > > > - ret = ida_alloc(intel_vsec_dev->ida, GFP_KERNEL); > > > - mutex_unlock(&vsec_ida_lock); > > > + ret = xa_alloc(&auxdev_array, &intel_vsec_dev->id, intel_vsec_dev, > > > + PMT_XA_LIMIT, GFP_KERNEL); > > > if (ret < 0) { > > > kfree(intel_vsec_dev->resource); > > > kfree(intel_vsec_dev); > > > return ret; > > > } > > > > > > + mutex_lock(&vsec_ida_lock); > > > + id = ida_alloc(intel_vsec_dev->ida, GFP_KERNEL); > > > + mutex_unlock(&vsec_ida_lock); > > > + if (id < 0) { > > > + kfree(intel_vsec_dev->resource); > > > + kfree(intel_vsec_dev); > > > + return id; > > > > Thanks, this looks much better this way around but it is missing > > xa_alloc() rollback now that the order is reversed. > > > > Once that is fixed, > > > > Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> > > I have fixed this up, adding the missing: > > xa_erase(&auxdev_array, intel_vsec_dev->id); > > to this error-exit path while merging this. Thanks. Does that include the rest of the series which was all reviewed by Ilpo? > > While looking into this I did find one other thing which > worries me (different issue, needs a separate fix): > > intel_vsec_pci_slot_reset() uses > > devm_release_action(&pdev->dev, intel_vsec_remove_aux, > &intel_vsec_dev->auxdev); > > and seems to assume that after this intel_vsec_remove_aux() > has run for the auxdev-s. *But this is not the case* > > devm_release_action() only removes the action from the list > of devres resources tied to the parent PCI device. > > It does *NOT* call the registered action function, > so intel_vsec_remove_aux() is NOT called here. > > And then on re-probing the device as is done in > intel_vsec_pci_slot_reset() a second set of aux > devices with the same parent will be created AFAICT. > > So it seems that this also needs an explicit > intel_vsec_remove_aux() call for each auxdev! > > ### > > This makes me wonder if the PCI error handling here > and specifically the reset code was ever tested ? I recall the code was tested using error injection to cause the slot reset to occur and reprobe was confirmed. I'll have to find out the specific test so that we can check it again with the proposed fix and ensure no leaks. > > ### > > Note that simply forcing a reprobe using device_reprobe() > will cause all the aux-devices to also get removed through > the action on driver-unbind without ever needing > the auxdev_array at all! Okay. That would be a lot simpler. > > I guess that you want the removal to happen before > the pci_restore_state(pdev) state though, so that > simply relying on the removal on driver unbind > is not an option ? I'm not sure this is needed given the simplicity of the device. The array was added only to track the list of devices and reprobe the one that was reset. We'll look at changing this to do driver_reprobe() instead. Thanks. David
Hi, On 12/4/23 20:57, David E. Box wrote: > Hi Hans, > > On Mon, 2023-12-04 at 14:51 +0100, Hans de Goede wrote: >> Hi, >> >> On 11/30/23 12:02, Ilpo Järvinen wrote: >>> On Wed, 29 Nov 2023, David E. Box wrote: >>> >>>> Commit 936874b77dd0 ("platform/x86/intel/vsec: Add PCI error recovery >>>> support to Intel PMT") added an xarray to track the list of vsec devices >>>> to >>>> be recovered after a PCI error. But it did not provide cleanup for the >>>> list >>>> leading to a memory leak that was caught by kmemleak. Do xa_alloc() >>>> before >>>> devm_add_action_or_reset() so that the list may be cleaned up with >>>> xa_erase() in the release function. >>>> >>>> Fixes: 936874b77dd0 ("platform/x86/intel/vsec: Add PCI error recovery >>>> support to Intel PMT") >>>> Signed-off-by: David E. Box <david.e.box@linux.intel.com> >>>> --- >>>> >>>> V6 - Move xa_alloc() before ida_alloc() to reduce mutex use during error >>>> recovery. >>>> - Fix return value after id_alloc() fail >>>> - Add Fixes tag >>>> - Add more detail to changelog >>>> >>>> V5 - New patch >>>> >>>> drivers/platform/x86/intel/vsec.c | 24 ++++++++++++++---------- >>>> drivers/platform/x86/intel/vsec.h | 1 + >>>> 2 files changed, 15 insertions(+), 10 deletions(-) >>>> >>>> diff --git a/drivers/platform/x86/intel/vsec.c >>>> b/drivers/platform/x86/intel/vsec.c >>>> index c1f9e4471b28..2d568466b4e2 100644 >>>> --- a/drivers/platform/x86/intel/vsec.c >>>> +++ b/drivers/platform/x86/intel/vsec.c >>>> @@ -120,6 +120,8 @@ static void intel_vsec_dev_release(struct device *dev) >>>> { >>>> struct intel_vsec_device *intel_vsec_dev = dev_to_ivdev(dev); >>>> >>>> + xa_erase(&auxdev_array, intel_vsec_dev->id); >>>> + >>>> mutex_lock(&vsec_ida_lock); >>>> ida_free(intel_vsec_dev->ida, intel_vsec_dev->auxdev.id); >>>> mutex_unlock(&vsec_ida_lock); >>>> @@ -135,19 +137,27 @@ int intel_vsec_add_aux(struct pci_dev *pdev, struct >>>> device *parent, >>>> struct auxiliary_device *auxdev = &intel_vsec_dev->auxdev; >>>> int ret, id; >>>> >>>> - mutex_lock(&vsec_ida_lock); >>>> - ret = ida_alloc(intel_vsec_dev->ida, GFP_KERNEL); >>>> - mutex_unlock(&vsec_ida_lock); >>>> + ret = xa_alloc(&auxdev_array, &intel_vsec_dev->id, intel_vsec_dev, >>>> + PMT_XA_LIMIT, GFP_KERNEL); >>>> if (ret < 0) { >>>> kfree(intel_vsec_dev->resource); >>>> kfree(intel_vsec_dev); >>>> return ret; >>>> } >>>> >>>> + mutex_lock(&vsec_ida_lock); >>>> + id = ida_alloc(intel_vsec_dev->ida, GFP_KERNEL); >>>> + mutex_unlock(&vsec_ida_lock); >>>> + if (id < 0) { >>>> + kfree(intel_vsec_dev->resource); >>>> + kfree(intel_vsec_dev); >>>> + return id; >>> >>> Thanks, this looks much better this way around but it is missing >>> xa_alloc() rollback now that the order is reversed. >>> >>> Once that is fixed, >>> >>> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> >> >> I have fixed this up, adding the missing: >> >> xa_erase(&auxdev_array, intel_vsec_dev->id); >> >> to this error-exit path while merging this. > > Thanks. Does that include the rest of the series which was all reviewed by Ilpo? Yes the entire series has been merged into the pdx86/review-hans branch now. Regards, Hans
diff --git a/drivers/platform/x86/intel/vsec.c b/drivers/platform/x86/intel/vsec.c index c1f9e4471b28..2d568466b4e2 100644 --- a/drivers/platform/x86/intel/vsec.c +++ b/drivers/platform/x86/intel/vsec.c @@ -120,6 +120,8 @@ static void intel_vsec_dev_release(struct device *dev) { struct intel_vsec_device *intel_vsec_dev = dev_to_ivdev(dev); + xa_erase(&auxdev_array, intel_vsec_dev->id); + mutex_lock(&vsec_ida_lock); ida_free(intel_vsec_dev->ida, intel_vsec_dev->auxdev.id); mutex_unlock(&vsec_ida_lock); @@ -135,19 +137,27 @@ int intel_vsec_add_aux(struct pci_dev *pdev, struct device *parent, struct auxiliary_device *auxdev = &intel_vsec_dev->auxdev; int ret, id; - mutex_lock(&vsec_ida_lock); - ret = ida_alloc(intel_vsec_dev->ida, GFP_KERNEL); - mutex_unlock(&vsec_ida_lock); + ret = xa_alloc(&auxdev_array, &intel_vsec_dev->id, intel_vsec_dev, + PMT_XA_LIMIT, GFP_KERNEL); if (ret < 0) { kfree(intel_vsec_dev->resource); kfree(intel_vsec_dev); return ret; } + mutex_lock(&vsec_ida_lock); + id = ida_alloc(intel_vsec_dev->ida, GFP_KERNEL); + mutex_unlock(&vsec_ida_lock); + if (id < 0) { + kfree(intel_vsec_dev->resource); + kfree(intel_vsec_dev); + return id; + } + if (!parent) parent = &pdev->dev; - auxdev->id = ret; + auxdev->id = id; auxdev->name = name; auxdev->dev.parent = parent; auxdev->dev.release = intel_vsec_dev_release; @@ -169,12 +179,6 @@ int intel_vsec_add_aux(struct pci_dev *pdev, struct device *parent, if (ret < 0) return ret; - /* Add auxdev to list */ - ret = xa_alloc(&auxdev_array, &id, intel_vsec_dev, PMT_XA_LIMIT, - GFP_KERNEL); - if (ret) - return ret; - return 0; } EXPORT_SYMBOL_NS_GPL(intel_vsec_add_aux, INTEL_VSEC); diff --git a/drivers/platform/x86/intel/vsec.h b/drivers/platform/x86/intel/vsec.h index 0fd042c171ba..0a6201b4a0e9 100644 --- a/drivers/platform/x86/intel/vsec.h +++ b/drivers/platform/x86/intel/vsec.h @@ -45,6 +45,7 @@ struct intel_vsec_device { struct ida *ida; struct intel_vsec_platform_info *info; int num_resources; + int id; /* xa */ void *priv_data; size_t priv_data_size; };