linux-kernel - Re: [PATCH v3 3/5] gpio: gpiolib: Allow free() callback to be overridden

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 12 May 2022 17:26:10 +0100
From:   Marc Zyngier <maz@...nel.org>
To:     "Lad, Prabhakar" <prabhakar.csengg@...il.com>
Cc:     Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>,
        Geert Uytterhoeven <geert+renesas@...der.be>,
        Linus Walleij <linus.walleij@...aro.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Bartosz Golaszewski <brgl@...ev.pl>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Linux-Renesas <linux-renesas-soc@...r.kernel.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>,
        Phil Edworthy <phil.edworthy@...esas.com>,
        Biju Das <biju.das.jz@...renesas.com>
Subject: Re: [PATCH v3 3/5] gpio: gpiolib: Allow free() callback to be overridden

On Thu, 12 May 2022 14:50:05 +0100,
"Lad, Prabhakar" <prabhakar.csengg@...il.com> wrote:
> 
> Hi Marc,
> 
> On Thu, May 12, 2022 at 2:24 PM Marc Zyngier <maz@...nel.org> wrote:
> >
> > On Thu, 12 May 2022 13:48:53 +0100,
> > "Lad, Prabhakar" <prabhakar.csengg@...il.com> wrote:
> > >
> > > Hi Marc,
> > >
> > > Thank you for the review.
> > >
> > > On Thu, May 12, 2022 at 12:19 PM Marc Zyngier <maz@...nel.org> wrote:
> > > >
> > > > On Wed, 11 May 2022 19:32:08 +0100,
> > > > Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com> wrote:
> > > > >
> > > > > Allow free() callback to be overridden from irq_domain_ops for
> > > > > hierarchical chips.
> > > > >
> > > > > This allows drivers to free any resources which are allocated during
> > > > > populate_parent_alloc_arg().
> > > >
> > > > Do you mean more than the fwspec? I don't see this being used.
> > > >
> > > The free callback is used in patch 5/5 where free is overridden by
> > > rzg2l_gpio_irq_domain_free. I just gave an example there as an
> > > populate_parent_alloc_arg()  In actual in the child_to_parent_hwirq
> > > callback I am using a bitmap [0] to get a free tint slot, this bitmap
> > > needs freeing up when the GPIO interrupt is released from the driver
> > > that as when overridden free callback frees the allocated tint slot so
> > > that its available for re-use.
> >
> > Right, so that's actually a different life-cycle, and the whole
> > populate_parent_alloc_arg() is a red herring. What you want is to free
> > resources that have been allocated via some other paths. It'd be good
> Is there any other path which I have missed where I can free up resources?

No, that's the only one. It is just that usually, the alloc()
callback is where you are supposed to perform... allocations.

It'd be good if you could move your allocation there, as I would
expect calls to child_to_parent_hwirq() to be idempotent.

>
> > if your commit message actually reflected this instead of using an
> > example that doesn't actually exist.
> >
> My bad, I will update the commit message.
> 
> > >
> > > > There is also the question of why we need to have dynamic allocation
> > > > for the fwspec itself. Why isn't that a simple stack allocation in the
> > > > context of gpiochip_hierarchy_irq_domain_alloc()?
> > > >
> > > you mean gpio core itself should handle the fwspec
> > > allocation/freeing?
> >
> > Yes. The only reason we resort to dynamic allocation is because
> > ThunderX is using MSI-based GPIOs, and thus doesn't use a fwspec (no
> > firmware is involved here).
> >
> I see..
> 
> > If we had a union of the two types, we could just have a stack
> > variable, and pass that along, completely sidestepping the whole
> > dynamic allocation/freeing business.
> >
> Right agreed.

FWIW, I've just posted a PoC patch[1].

Thanks,

	M.

[1] https://lore.kernel.org/r/20220512162320.2213488-1-maz@kernel.org

-- 
Without deviation from the norm, progress is not possible.