[RFC PATCH] gpiolib: Move setting the flow handler and don't set it at all if there is a parent domain

[RFC PATCH] gpiolib: Move setting the flow handler and don't set it at all if there is a parent domain

[Daniel Palmer]

Calling irq_domain_set_info() before irq_domain_alloc_irqs_parent()
can cause a null pointer dereference as the parent domain isn't
ready yet.

Move irq_domain_set_info() to after irq_domain_alloc_irqs_parent().
A side effect of this is that irq_domain_set_info() will now overwrite
the flow handler from the parent domain. So if there is a parent
domain do not set the flow handler anymore.

This allows gpio-msc313.c to level it's irq domain on top of the
new irq controller in later SigmaStar SoCs without crashing.

Link: https://lore.kernel.org/linux-arm-kernel/20210914100415.1549208-1-daniel@0x0f.com/
Signed-off-by: Daniel Palmer <daniel@0x0f.com>
Suggested-by: Marc Zyngier <maz@kernel.org>
---
 drivers/gpio/gpiolib.c | 34 +++++++++++++++++++++-------------
 1 file changed, 21 insertions(+), 13 deletions(-)

diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index d1b9b721218f..993eeced6b4f 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -1103,19 +1103,6 @@ static int gpiochip_hierarchy_irq_domain_alloc(struct irq_domain *d,
 	}
 	chip_dbg(gc, "found parent hwirq %u\n", parent_hwirq);
 
-	/*
-	 * We set handle_bad_irq because the .set_type() should
-	 * always be invoked and set the right type of handler.
-	 */
-	irq_domain_set_info(d,
-			    irq,
-			    hwirq,
-			    gc->irq.chip,
-			    gc,
-			    girq->handler,
-			    NULL, NULL);
-	irq_set_probe(irq);
-
 	/* This parent only handles asserted level IRQs */
 	parent_arg = girq->populate_parent_alloc_arg(gc, parent_hwirq, parent_type);
 	if (!parent_arg)
@@ -1137,6 +1124,27 @@ static int gpiochip_hierarchy_irq_domain_alloc(struct irq_domain *d,
 			 parent_hwirq, hwirq);
 
 	kfree(parent_arg);
+
+	if (!ret) {
+		/* If there is a parent domain leave the flow handler alone */
+		if (d->parent)
+			irq_domain_set_hwirq_and_chip(d,
+						      irq,
+						      hwirq,
+						      gc->irq.chip,
+						      gc);
+		/* Otherwise set the flow handler supplied by the gpio driver */
+		else
+			irq_domain_set_info(d,
+					    irq,
+					    hwirq,
+					    gc->irq.chip,
+					    gc,
+					    girq->handler,
+					    NULL, NULL);
+		irq_set_probe(irq);
+	}
+
 	return ret;
 }
 
-- 
2.33.0

Re: [RFC PATCH] gpiolib: Move setting the flow handler and don't set it at all if there is a parent domain

[Linus Walleij]

Hi Daniel,

thanks for your patch!

On Sat, Oct 2, 2021 at 6:20 PM Daniel Palmer <daniel@0x0f.com> wrote:

> Calling irq_domain_set_info() before irq_domain_alloc_irqs_parent()
> can cause a null pointer dereference as the parent domain isn't
> ready yet.
>
> Move irq_domain_set_info() to after irq_domain_alloc_irqs_parent().
> A side effect of this is that irq_domain_set_info() will now overwrite
> the flow handler from the parent domain. So if there is a parent
> domain do not set the flow handler anymore.
>
> This allows gpio-msc313.c to level it's irq domain on top of the
> new irq controller in later SigmaStar SoCs without crashing.
>
> Link: https://lore.kernel.org/linux-arm-kernel/20210914100415.1549208-1-daniel@0x0f.com/
> Signed-off-by: Daniel Palmer <daniel@0x0f.com>
> Suggested-by: Marc Zyngier <maz@kernel.org>

If Marc says this is the way to go I think it is the way to go!

>         kfree(parent_arg);
> +
> +       if (!ret) {

Please just exit on error so invert this.

if (ret)
  return ret;

and just de-indent the below code (easier to follow)

> +               /* If there is a parent domain leave the flow handler alone */
> +               if (d->parent)
> +                       irq_domain_set_hwirq_and_chip(d,
> +                                                     irq,
> +                                                     hwirq,
> +                                                     gc->irq.chip,
> +                                                     gc);
> +               /* Otherwise set the flow handler supplied by the gpio driver */
> +               else
> +                       irq_domain_set_info(d,
> +                                           irq,
> +                                           hwirq,
> +                                           gc->irq.chip,
> +                                           gc,
> +                                           girq->handler,
> +                                           NULL, NULL);
> +               irq_set_probe(irq);
> +       }

Should we print an error if girq->handler is not NULL and we find
a parent domain, like
if (d->parent && girq->handler)
  dev_err(dev, "parent domain and flow handler both specified\n");

Yours,
Linus Walleij

Re: [RFC PATCH] gpiolib: Move setting the flow handler and don't set it at all if there is a parent domain

[Daniel Palmer]

Hi Linus,

On Mon, 4 Oct 2021 at 07:16, Linus Walleij <linus.walleij@linaro.org> wrote:
> If Marc says this is the way to go I think it is the way to go!

To be completely transparent, moving irq_domain_set_info() is from Marc.
Not setting the handler is from me.

>
> >         kfree(parent_arg);
> > +
> > +       if (!ret) {
>
> Please just exit on error so invert this.

Ok.

> if (ret)
>   return ret;
>
> and just de-indent the below code (easier to follow)
>
> > +               /* If there is a parent domain leave the flow handler alone */
> > +               if (d->parent)
>
> Should we print an error if girq->handler is not NULL and we find
> a parent domain, like
> if (d->parent && girq->handler)
>   dev_err(dev, "parent domain and flow handler both specified\n");

I think that would help catch situations where these changes would
break stuff. I want to avoid breaking other people's stuff for my
hobby project.

However, I've noticed we can't get to the "if (d->parent)" if there is
no parent as irq_domain_alloc_irqs_parent() will return -ENOSYS if
d->parent is null.
So the logic isn't right there. I think the idea is right but now I
can't figure out what we should actually check to know whether we need
to set the handler or not.
I'm hoping Marc will chip in when he has some time. :)

Cheers,

Daniel