Received: by 2002:a05:7412:d8a:b0:e2:908c:2ebd with SMTP id b10csp869793rdg; Fri, 13 Oct 2023 03:54:32 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFpacleubQmnLSLzqqOLTHGizAiKKxs1JtFBuqAog/P7KVV3t0wW8Y3D2kTRXiM2uLAd7nk X-Received: by 2002:a17:90b:257:b0:27d:2e39:25da with SMTP id fz23-20020a17090b025700b0027d2e3925damr2262534pjb.39.1697194471999; Fri, 13 Oct 2023 03:54:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1697194471; cv=none; d=google.com; s=arc-20160816; b=wo25kUtxHXyB3pS78QqppgUcDHzhXU4dI73AqULk7QhaGpg3sEbde/Xk/Cusnw3oTX 6zSVnrBjDe2Q15BywsoA48Gpa5TLE6QlUpY69RpoVm2UC/fde7Aw25SaLVOwwmy+iX13 PGSjU3y7/7IN+CnmJ4MRfFY2UrYArR7NPEyFZyKQ+1OIG2ZhApioYTHNfxUGvi2wkTYC cUZHohOXZUnpqCqJBalewKGShuAwhQwN5McDQokOkwlo2Z7oFCNvjOL7Zhkzuss6cEIe InMlOayl32b9GksM5cEDcmjPh0IB5Pa/+A0PWw8MF6niPAq88pq4apfhdCiz5pbPpARQ GejQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:references:message-id:in-reply-to :subject:cc:to:from:date:dkim-signature; bh=7dexIapdAeacq5jtigIzSxRIPeLSCH1N4/qF8m5f+Kw=; fh=mOqrdtzLxfRdhx+JUcCLIFZwj5ZpRA4B+MTwRGfrWMA=; b=euvxOcLsLWs8b2d28izr6b+gixzhjO4LMOM9/aX/mZvx3TGRO2u2fz4I6VDv0cg633 tufHmy5nXZbXHcWyXNPPh7KtQXnKRXUg3bsTXYO6G2RubVcnksHo/z4DrE9BQ8ERxmPc u5VIIrLndbP4n5KSz5DVoH3IxnngaIVh9/ZsfspMj9v8K0mX6sDeecUyc1jmxYSmLUzE ai4tvTHo5tSBzVfcAXkg9f7pJZA75jnkuUtsBKToo5vlZlmOPzdQurOEk8P7cu0vcfXQ nx+v6nQBiuzsdC0tRXY3efsNGjORv1odNXQabslm41fOyrnxufCGX/jtNpqjPBJuM2Wc ljuw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=Wt6KgWWx; 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 Return-Path: Received: from lipwig.vger.email (lipwig.vger.email. [2620:137:e000::3:3]) by mx.google.com with ESMTPS id 16-20020a17090a019000b0025c1d114af0si3954910pjc.93.2023.10.13.03.54.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 13 Oct 2023 03:54:31 -0700 (PDT) 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=Wt6KgWWx; 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 CD74E806083A; Fri, 13 Oct 2023 03:54:28 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at lipwig.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230255AbjJMKyW (ORCPT + 99 others); Fri, 13 Oct 2023 06:54:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55694 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230088AbjJMKyU (ORCPT ); Fri, 13 Oct 2023 06:54:20 -0400 Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.43]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 80E5FBE; Fri, 13 Oct 2023 03:54:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1697194458; x=1728730458; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=5eWUjBqPlnFCsnz+FrbWxqesd3yAFBdea7r8Bx04azc=; b=Wt6KgWWxo7R4oyqR99fpka6WwjLn/v+2JEUVSxnYDQCzMeqh/5EFHxMb 3VXnqwyU29hsct/q0TSdlofPg1iq3Fe0NFeKtTHdEOejc9yocJlfEGCZ2 pjj1KFqvf0i/U5dPRF2gMSkIO1Asii5YcFpCWRxcJckqJAOZuBVMq9UcV fh6qddMVtoqf5lu9FJdJeLBSRuT5ZJf5XR9u2YxOUraYzcEMQ4eyU9ymV LhOOs4QRewotnlY9rG0pwr1tZchoZGpe6uAkmFSj7PySTp0gnX19vt3Kd GIV1tHwjwhWqPHx9QFPHp2RFxaPjJ2iudZaSYfS0S0ioZKCwLc0rJzFwS A==; X-IronPort-AV: E=McAfee;i="6600,9927,10861"; a="471388848" X-IronPort-AV: E=Sophos;i="6.03,221,1694761200"; d="scan'208";a="471388848" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Oct 2023 03:54:18 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10861"; a="871026449" X-IronPort-AV: E=Sophos;i="6.03,221,1694761200"; d="scan'208";a="871026449" Received: from ttmerile-mobl1.ger.corp.intel.com (HELO rploss-MOBL.ger.corp.intel.com) ([10.249.37.202]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Oct 2023 03:54:16 -0700 Date: Fri, 13 Oct 2023 13:54:14 +0300 (EEST) From: =?ISO-8859-15?Q?Ilpo_J=E4rvinen?= To: "David E. Box" cc: LKML , platform-driver-x86@vger.kernel.org, rajvi.jingar@linux.intel.com Subject: Re: [PATCH V3 03/16] platform/x86/intel/vsec: Use cleanup.h In-Reply-To: Message-ID: <4315a8db-16fe-7421-c482-5aede4d5cdd@linux.intel.com> References: <20231012023840.3845703-1-david.e.box@linux.intel.com> <20231012023840.3845703-4-david.e.box@linux.intel.com> <114e1cc4-f129-b6cd-a83b-7d822cde178@linux.intel.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8323329-971062823-1697194458=:2026" 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 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: 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]); Fri, 13 Oct 2023 03:54:28 -0700 (PDT) This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-971062823-1697194458=:2026 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT On Thu, 12 Oct 2023, David E. Box wrote: > On Thu, 2023-10-12 at 17:46 +0300, Ilpo Järvinen wrote: > > On Wed, 11 Oct 2023, David E. Box wrote: > > > > > Use cleanup.h helpers to handle cleanup of resources in > > > intel_vsec_add_dev() after failures. > > > > > > Signed-off-by: David E. Box > > > --- > > > V3 - New patch. > > > > > >  drivers/platform/x86/intel/vsec.c | 17 ++++++++++------- > > >  1 file changed, 10 insertions(+), 7 deletions(-) > > > > > > diff --git a/drivers/platform/x86/intel/vsec.c > > > b/drivers/platform/x86/intel/vsec.c > > > index 15866b7d3117..f03ab89ab7c0 100644 > > > --- a/drivers/platform/x86/intel/vsec.c > > > +++ b/drivers/platform/x86/intel/vsec.c > > > @@ -15,6 +15,7 @@ > > >   > > >  #include > > >  #include > > > +#include > > >  #include > > >  #include > > >  #include > > > @@ -155,10 +156,10 @@ EXPORT_SYMBOL_NS_GPL(intel_vsec_add_aux, INTEL_VSEC); > > >  static int intel_vsec_add_dev(struct pci_dev *pdev, struct > > > intel_vsec_header *header, > > >                               struct intel_vsec_platform_info *info) > > >  { > > > -       struct intel_vsec_device *intel_vsec_dev; > > > +       struct intel_vsec_device __free(kfree) *intel_vsec_dev = NULL; > > >         struct resource *res, *tmp; > > >         unsigned long quirks = info->quirks; > > > -       int i; > > > +       int ret, i; > > >   > > >         if (!intel_vsec_supported(header->id, info->caps)) > > >                 return -EINVAL; > > > @@ -178,10 +179,8 @@ static int intel_vsec_add_dev(struct pci_dev *pdev, > > > struct intel_vsec_header *he > > >                 return -ENOMEM; > > >   > > >         res = kcalloc(header->num_entries, sizeof(*res), GFP_KERNEL); > > > -       if (!res) { > > > -               kfree(intel_vsec_dev); > > > +       if (!res) > > >                 return -ENOMEM; > > > -       } > > >   > > >         if (quirks & VSEC_QUIRK_TABLE_SHIFT) > > >                 header->offset >>= TABLE_OFFSET_SHIFT; > > > @@ -208,8 +207,12 @@ static int intel_vsec_add_dev(struct pci_dev *pdev, > > > struct intel_vsec_header *he > > >         else > > >                 intel_vsec_dev->ida = &intel_vsec_ida; > > >   > > > -       return intel_vsec_add_aux(pdev, NULL, intel_vsec_dev, > > > -                                 intel_vsec_name(header->id)); > > > +       ret = intel_vsec_add_aux(pdev, NULL, intel_vsec_dev, > > > +                                intel_vsec_name(header->id)); > > > + > > > +       no_free_ptr(intel_vsec_dev); > > > + > > > +       return ret; > > > > So if intel_vsec_add_aux() returned an error, intel_vsec_dev won't be > > freed because of the call call to no_free_ptr() before return. I that's > > not what you intended? > > It will have been freed if intel_vsec_add_aux() fails. It's a little messy. That > function creates the auxdev and assigns the release function which will free > intel_vsec_dev when the device is removed. But there are failure points that > will also invoke the release function. Because of this, for all the failure > points in that function we free intel_vsec_dev so that it's state doesn't need > to be questioned here. This happens explicitly if the failure is before > auxiliary_device_init(), or through the release function invoked by > auxiliary_device_uninit() if after. Oh, that's really convoluted and no wonder I missed it completely. It might even be that using cleanup.h here isn't really worth it. I know I pushed you into that direction but I didn't realize all the complexity at that point. If you still want to keep using cleanup.h, it would perhaps be less dangerous if you change the code such that no_free_ptr() for intel_vsec_dev and the resource (in 4/16, that's a similar case, isn't it?) are before the intel_vsec_add_aux() call (and I'd also add a comment to explain that freeing them is now responsability of intel_vsec_add_aux()). That way, we don't leave a trap into there where somebody happily adds another no_free_ptr() to the same group and it causes a mem leak. -- i. --8323329-971062823-1697194458=:2026--