Re: [PATCH V3 03/16] platform/x86/intel/vsec: Use cleanup.h

Ilpo Järvinen
2023-10-16T12:02:48Z

[-- Attachment #1: Type: text/plain, Size: 3668 bytes --]

On Fri, 13 Oct 2023, David E. Box wrote:

> On Fri, 2023-10-13 at 13:54 +0300, Ilpo Järvinen wrote:
> > 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 <david.e.box@linux.intel.com>
> > > > > ---

> > > > > @@ -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.

...
> > 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.
>
> Sure. After the comment I'd just do this then still the value is still needed,
>
> ret = intel_vsec_add_aux(pdev, NULL, no_free_ptr(intel_vsec_dev),
> intel_vsec_name(header->id));

True, I realized later that the variable gets NULLed because of how
no_free_ptr() works so no_free_ptr() has to be within the call itself, but
that's actually much better than my initial suggestion!

So I think the best we can get out of this is along the lines of (with the
subsequent change with res too):

/* Pass the ownership of intel_vsec_dev and resource within it to intel_vsec_add_aux() */
no_free_ptr(res);
return intel_vsec_add_aux(pdev, info->parent, no_free_ptr(intel_vsec_dev),
intel_vsec_name(header->id));

That seems the least trappiest and actually nicely documents who is
responsible for what. To contrast the earlier, this feels very elegant,
the perceived complexity related to intel_vsec_add_aux() no longer feels
tricky at all so we end up solving also that problem better than the
original.

--
i.