All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lokesh Vutla <lokeshvutla@ti.com>
To: Marc Zyngier <marc.zyngier@arm.com>,
	Santosh Shilimkar <ssantosh@kernel.org>,
	Rob Herring <robh+dt@kernel.org>, Nishanth Menon <nm@ti.com>,
	<tglx@linutronix.de>, <jason@lakedaemon.net>
Cc: Linux ARM Mailing List <linux-arm-kernel@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>, Tero Kristo <t-kristo@ti.com>,
	Sekhar Nori <nsekhar@ti.com>, Tony Lindgren <tony@atomide.com>,
	<linus.walleij@linaro.org>,
	Peter Ujfalusi <peter.ujfalusi@ti.com>,
	Grygorii Strashko <grygorii.strashko@ti.com>,
	Device Tree Mailing List <devicetree@vger.kernel.org>
Subject: Re: [PATCH v7 11/14] irqchip: ti-sci-inta: Add support for Interrupt Aggregator driver
Date: Tue, 30 Apr 2019 11:31:13 +0530	[thread overview]
Message-ID: <a0f2a359-7139-18b3-6cb7-3e6445705bbd@ti.com> (raw)
In-Reply-To: <36b8bc62-fff2-c015-8140-cda625efdabc@arm.com>



On 29/04/19 6:41 PM, Marc Zyngier wrote:
> On 20/04/2019 11:09, Lokesh Vutla wrote:
>> Texas Instruments' K3 generation SoCs has an IP Interrupt Aggregator
>> which is an interrupt controller that does the following:
>> - Converts events to interrupts that can be understood by
>>   an interrupt router.
>> - Allows for multiplexing of events to interrupts.
>>
>> Configuration of the interrupt aggregator registers can only be done by
>> a system co-processor and the driver needs to send a message to this
>> co processor over TISCI protocol. This patch adds support for Interrupt
>> Aggregator irqdomain.
>>
>> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
>> ---
>> Changes since v6:
>> - Updated commit message.
>> - Arranged header files in alphabetical order
>> - Included vint_bit in struct ti_sci_inta_event_desc
>> - With the above change now the chip_data is event_desc instead of vint_desc
>> - No loops are used in atomic contexts.
>> - Fixed locking issue while freeing parent virq
>> - Fixed few other cosmetic changes.
>>
>>  MAINTAINERS                       |   1 +
>>  drivers/irqchip/Kconfig           |  11 +
>>  drivers/irqchip/Makefile          |   1 +
>>  drivers/irqchip/irq-ti-sci-inta.c | 589 ++++++++++++++++++++++++++++++
>>  4 files changed, 602 insertions(+)
>>  create mode 100644 drivers/irqchip/irq-ti-sci-inta.c
>>
> 
> [...]
> 
>> +/**
>> + * ti_sci_inta_alloc_irq() -  Allocate an irq within INTA domain
>> + * @domain:	irq_domain pointer corresponding to INTA
>> + * @hwirq:	hwirq of the input event
>> + *
>> + * Note: Allocation happens in the following manner:
>> + *	- Find a free bit available in any of the vints available in the list.
>> + *	- If not found, allocate a vint from the vint pool
>> + *	- Attach the free bit to input hwirq.
>> + * Return event_desc if all went ok else appropriate error value.
>> + */
>> +static struct ti_sci_inta_event_desc *ti_sci_inta_alloc_irq(struct irq_domain *domain,
>> +							    u32 hwirq)
>> +{
>> +	struct ti_sci_inta_irq_domain *inta = domain->host_data;
>> +	struct ti_sci_inta_vint_desc *vint_desc = NULL;
>> +	u16 free_bit;
>> +
>> +	mutex_lock(&inta->vint_mutex);
>> +	list_for_each_entry(vint_desc, &inta->vint_list, list) {
>> +		mutex_lock(&vint_desc->event_mutex);
>> +		free_bit = find_first_zero_bit(vint_desc->event_map,
>> +					       MAX_EVENTS_PER_VINT);
>> +		if (free_bit != MAX_EVENTS_PER_VINT) {
>> +			set_bit(free_bit, vint_desc->event_map);
>> +			mutex_unlock(&vint_desc->event_mutex);
>> +			mutex_unlock(&inta->vint_mutex);
>> +			goto alloc_event;
>> +		}
>> +		mutex_unlock(&vint_desc->event_mutex);
>> +	}
>> +	mutex_unlock(&inta->vint_mutex);
>> +
>> +	/* No free bits available. Allocate a new vint */
>> +	vint_desc = ti_sci_inta_alloc_parent_irq(domain);
>> +	if (IS_ERR(vint_desc))
>> +		return ERR_PTR(PTR_ERR(vint_desc));
>> +
>> +	mutex_lock(&vint_desc->event_mutex);
>> +	free_bit = find_first_zero_bit(vint_desc->event_map,
>> +				       MAX_EVENTS_PER_VINT);
>> +	set_bit(free_bit, vint_desc->event_map);
>> +	mutex_unlock(&vint_desc->event_mutex);
> 
> This code is still quite racy: you can have two parallel allocations
> failing to get a free bit in any of the already allocated vint_desc, and
> then both allocating a new vint_desc. If there was only one left, one of
> the allocation will fail despite having at least 63 free interrupts.

Good point. After thinking a bit more, I saw similar issue when two parallel
frees happens on a vint with only 2 bits allocated. First free when freeing
parent_irq might see all the bits cleared and does kfree(vint). Then second free
will crash when freeing parent irq.

Ill guard the entire allocation and freeing with vint_mutex and drop the
event_mutex altogether.

Thanks and regards,
Lokesh

> 
> 	M.
> 

WARNING: multiple messages have this Message-ID (diff)
From: Lokesh Vutla <lokeshvutla@ti.com>
To: Marc Zyngier <marc.zyngier@arm.com>,
	Santosh Shilimkar <ssantosh@kernel.org>,
	Rob Herring <robh+dt@kernel.org>, Nishanth Menon <nm@ti.com>,
	tglx@linutronix.de, jason@lakedaemon.net
Cc: Linux ARM Mailing List <linux-arm-kernel@lists.infradead.org>,
	linux-kernel@vger.kernel.org, Tero Kristo <t-kristo@ti.com>,
	Sekhar Nori <nsekhar@ti.com>, Tony Lindgren <tony@atomide.com>,
	linus.walleij@linaro.org, Peter Ujfalusi <peter.ujfalusi@ti.com>,
	Grygorii Strashko <grygorii.strashko@ti.com>,
	Device Tree Mailing List <devicetree@vger.kernel.org>
Subject: Re: [PATCH v7 11/14] irqchip: ti-sci-inta: Add support for Interrupt Aggregator driver
Date: Tue, 30 Apr 2019 11:31:13 +0530	[thread overview]
Message-ID: <a0f2a359-7139-18b3-6cb7-3e6445705bbd@ti.com> (raw)
In-Reply-To: <36b8bc62-fff2-c015-8140-cda625efdabc@arm.com>



On 29/04/19 6:41 PM, Marc Zyngier wrote:
> On 20/04/2019 11:09, Lokesh Vutla wrote:
>> Texas Instruments' K3 generation SoCs has an IP Interrupt Aggregator
>> which is an interrupt controller that does the following:
>> - Converts events to interrupts that can be understood by
>>   an interrupt router.
>> - Allows for multiplexing of events to interrupts.
>>
>> Configuration of the interrupt aggregator registers can only be done by
>> a system co-processor and the driver needs to send a message to this
>> co processor over TISCI protocol. This patch adds support for Interrupt
>> Aggregator irqdomain.
>>
>> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
>> ---
>> Changes since v6:
>> - Updated commit message.
>> - Arranged header files in alphabetical order
>> - Included vint_bit in struct ti_sci_inta_event_desc
>> - With the above change now the chip_data is event_desc instead of vint_desc
>> - No loops are used in atomic contexts.
>> - Fixed locking issue while freeing parent virq
>> - Fixed few other cosmetic changes.
>>
>>  MAINTAINERS                       |   1 +
>>  drivers/irqchip/Kconfig           |  11 +
>>  drivers/irqchip/Makefile          |   1 +
>>  drivers/irqchip/irq-ti-sci-inta.c | 589 ++++++++++++++++++++++++++++++
>>  4 files changed, 602 insertions(+)
>>  create mode 100644 drivers/irqchip/irq-ti-sci-inta.c
>>
> 
> [...]
> 
>> +/**
>> + * ti_sci_inta_alloc_irq() -  Allocate an irq within INTA domain
>> + * @domain:	irq_domain pointer corresponding to INTA
>> + * @hwirq:	hwirq of the input event
>> + *
>> + * Note: Allocation happens in the following manner:
>> + *	- Find a free bit available in any of the vints available in the list.
>> + *	- If not found, allocate a vint from the vint pool
>> + *	- Attach the free bit to input hwirq.
>> + * Return event_desc if all went ok else appropriate error value.
>> + */
>> +static struct ti_sci_inta_event_desc *ti_sci_inta_alloc_irq(struct irq_domain *domain,
>> +							    u32 hwirq)
>> +{
>> +	struct ti_sci_inta_irq_domain *inta = domain->host_data;
>> +	struct ti_sci_inta_vint_desc *vint_desc = NULL;
>> +	u16 free_bit;
>> +
>> +	mutex_lock(&inta->vint_mutex);
>> +	list_for_each_entry(vint_desc, &inta->vint_list, list) {
>> +		mutex_lock(&vint_desc->event_mutex);
>> +		free_bit = find_first_zero_bit(vint_desc->event_map,
>> +					       MAX_EVENTS_PER_VINT);
>> +		if (free_bit != MAX_EVENTS_PER_VINT) {
>> +			set_bit(free_bit, vint_desc->event_map);
>> +			mutex_unlock(&vint_desc->event_mutex);
>> +			mutex_unlock(&inta->vint_mutex);
>> +			goto alloc_event;
>> +		}
>> +		mutex_unlock(&vint_desc->event_mutex);
>> +	}
>> +	mutex_unlock(&inta->vint_mutex);
>> +
>> +	/* No free bits available. Allocate a new vint */
>> +	vint_desc = ti_sci_inta_alloc_parent_irq(domain);
>> +	if (IS_ERR(vint_desc))
>> +		return ERR_PTR(PTR_ERR(vint_desc));
>> +
>> +	mutex_lock(&vint_desc->event_mutex);
>> +	free_bit = find_first_zero_bit(vint_desc->event_map,
>> +				       MAX_EVENTS_PER_VINT);
>> +	set_bit(free_bit, vint_desc->event_map);
>> +	mutex_unlock(&vint_desc->event_mutex);
> 
> This code is still quite racy: you can have two parallel allocations
> failing to get a free bit in any of the already allocated vint_desc, and
> then both allocating a new vint_desc. If there was only one left, one of
> the allocation will fail despite having at least 63 free interrupts.

Good point. After thinking a bit more, I saw similar issue when two parallel
frees happens on a vint with only 2 bits allocated. First free when freeing
parent_irq might see all the bits cleared and does kfree(vint). Then second free
will crash when freeing parent irq.

Ill guard the entire allocation and freeing with vint_mutex and drop the
event_mutex altogether.

Thanks and regards,
Lokesh

> 
> 	M.
> 

WARNING: multiple messages have this Message-ID (diff)
From: Lokesh Vutla <lokeshvutla@ti.com>
To: Marc Zyngier <marc.zyngier@arm.com>,
	Santosh Shilimkar <ssantosh@kernel.org>,
	Rob Herring <robh+dt@kernel.org>, Nishanth Menon <nm@ti.com>,
	<tglx@linutronix.de>, <jason@lakedaemon.net>
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>,
	Grygorii Strashko <grygorii.strashko@ti.com>,
	Device Tree Mailing List <devicetree@vger.kernel.org>,
	Tony Lindgren <tony@atomide.com>,
	linus.walleij@linaro.org, Sekhar Nori <nsekhar@ti.com>,
	linux-kernel@vger.kernel.org, Tero Kristo <t-kristo@ti.com>,
	Linux ARM Mailing List <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v7 11/14] irqchip: ti-sci-inta: Add support for Interrupt Aggregator driver
Date: Tue, 30 Apr 2019 11:31:13 +0530	[thread overview]
Message-ID: <a0f2a359-7139-18b3-6cb7-3e6445705bbd@ti.com> (raw)
In-Reply-To: <36b8bc62-fff2-c015-8140-cda625efdabc@arm.com>



On 29/04/19 6:41 PM, Marc Zyngier wrote:
> On 20/04/2019 11:09, Lokesh Vutla wrote:
>> Texas Instruments' K3 generation SoCs has an IP Interrupt Aggregator
>> which is an interrupt controller that does the following:
>> - Converts events to interrupts that can be understood by
>>   an interrupt router.
>> - Allows for multiplexing of events to interrupts.
>>
>> Configuration of the interrupt aggregator registers can only be done by
>> a system co-processor and the driver needs to send a message to this
>> co processor over TISCI protocol. This patch adds support for Interrupt
>> Aggregator irqdomain.
>>
>> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
>> ---
>> Changes since v6:
>> - Updated commit message.
>> - Arranged header files in alphabetical order
>> - Included vint_bit in struct ti_sci_inta_event_desc
>> - With the above change now the chip_data is event_desc instead of vint_desc
>> - No loops are used in atomic contexts.
>> - Fixed locking issue while freeing parent virq
>> - Fixed few other cosmetic changes.
>>
>>  MAINTAINERS                       |   1 +
>>  drivers/irqchip/Kconfig           |  11 +
>>  drivers/irqchip/Makefile          |   1 +
>>  drivers/irqchip/irq-ti-sci-inta.c | 589 ++++++++++++++++++++++++++++++
>>  4 files changed, 602 insertions(+)
>>  create mode 100644 drivers/irqchip/irq-ti-sci-inta.c
>>
> 
> [...]
> 
>> +/**
>> + * ti_sci_inta_alloc_irq() -  Allocate an irq within INTA domain
>> + * @domain:	irq_domain pointer corresponding to INTA
>> + * @hwirq:	hwirq of the input event
>> + *
>> + * Note: Allocation happens in the following manner:
>> + *	- Find a free bit available in any of the vints available in the list.
>> + *	- If not found, allocate a vint from the vint pool
>> + *	- Attach the free bit to input hwirq.
>> + * Return event_desc if all went ok else appropriate error value.
>> + */
>> +static struct ti_sci_inta_event_desc *ti_sci_inta_alloc_irq(struct irq_domain *domain,
>> +							    u32 hwirq)
>> +{
>> +	struct ti_sci_inta_irq_domain *inta = domain->host_data;
>> +	struct ti_sci_inta_vint_desc *vint_desc = NULL;
>> +	u16 free_bit;
>> +
>> +	mutex_lock(&inta->vint_mutex);
>> +	list_for_each_entry(vint_desc, &inta->vint_list, list) {
>> +		mutex_lock(&vint_desc->event_mutex);
>> +		free_bit = find_first_zero_bit(vint_desc->event_map,
>> +					       MAX_EVENTS_PER_VINT);
>> +		if (free_bit != MAX_EVENTS_PER_VINT) {
>> +			set_bit(free_bit, vint_desc->event_map);
>> +			mutex_unlock(&vint_desc->event_mutex);
>> +			mutex_unlock(&inta->vint_mutex);
>> +			goto alloc_event;
>> +		}
>> +		mutex_unlock(&vint_desc->event_mutex);
>> +	}
>> +	mutex_unlock(&inta->vint_mutex);
>> +
>> +	/* No free bits available. Allocate a new vint */
>> +	vint_desc = ti_sci_inta_alloc_parent_irq(domain);
>> +	if (IS_ERR(vint_desc))
>> +		return ERR_PTR(PTR_ERR(vint_desc));
>> +
>> +	mutex_lock(&vint_desc->event_mutex);
>> +	free_bit = find_first_zero_bit(vint_desc->event_map,
>> +				       MAX_EVENTS_PER_VINT);
>> +	set_bit(free_bit, vint_desc->event_map);
>> +	mutex_unlock(&vint_desc->event_mutex);
> 
> This code is still quite racy: you can have two parallel allocations
> failing to get a free bit in any of the already allocated vint_desc, and
> then both allocating a new vint_desc. If there was only one left, one of
> the allocation will fail despite having at least 63 free interrupts.

Good point. After thinking a bit more, I saw similar issue when two parallel
frees happens on a vint with only 2 bits allocated. First free when freeing
parent_irq might see all the bits cleared and does kfree(vint). Then second free
will crash when freeing parent irq.

Ill guard the entire allocation and freeing with vint_mutex and drop the
event_mutex altogether.

Thanks and regards,
Lokesh

> 
> 	M.
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2019-04-30  6:02 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-20 10:09 [PATCH v7 00/14] Add support for TISCI Interrupt controller drivers Lokesh Vutla
2019-04-20 10:09 ` Lokesh Vutla
2019-04-20 10:09 ` Lokesh Vutla
2019-04-20 10:09 ` [PATCH v7 01/14] firmware: ti_sci: Add support to get TISCI handle using of_phandle Lokesh Vutla
2019-04-20 10:09   ` Lokesh Vutla
2019-04-20 10:09   ` Lokesh Vutla
2019-04-20 10:09 ` [PATCH v7 02/14] firmware: ti_sci: Add support for RM core ops Lokesh Vutla
2019-04-20 10:09   ` Lokesh Vutla
2019-04-20 10:09   ` Lokesh Vutla
2019-04-20 10:09 ` [PATCH v7 03/14] firmware: ti_sci: Add support for IRQ management Lokesh Vutla
2019-04-20 10:09   ` Lokesh Vutla
2019-04-20 10:09   ` Lokesh Vutla
2019-04-20 10:09 ` [PATCH v7 04/14] firmware: ti_sci: Add RM mapping table for am654 Lokesh Vutla
2019-04-20 10:09   ` Lokesh Vutla
2019-04-20 10:09   ` Lokesh Vutla
2019-04-20 10:09 ` [PATCH v7 05/14] firmware: ti_sci: Add helper apis to manage resources Lokesh Vutla
2019-04-20 10:09   ` Lokesh Vutla
2019-04-20 10:09   ` Lokesh Vutla
2019-04-20 10:09 ` [PATCH v7 06/14] genirq: Introduce irq_chip_{request,release}_resource_parent() apis Lokesh Vutla
2019-04-20 10:09   ` [PATCH v7 06/14] genirq: Introduce irq_chip_{request, release}_resource_parent() apis Lokesh Vutla
2019-04-20 10:09   ` [PATCH v7 06/14] genirq: Introduce irq_chip_{request,release}_resource_parent() apis Lokesh Vutla
2019-04-20 10:09 ` [PATCH v7 07/14] gpio: thunderx: Use the default parent apis for {request,release}_resources Lokesh Vutla
2019-04-20 10:09   ` [PATCH v7 07/14] gpio: thunderx: Use the default parent apis for {request, release}_resources Lokesh Vutla
2019-04-20 10:09   ` [PATCH v7 07/14] gpio: thunderx: Use the default parent apis for {request,release}_resources Lokesh Vutla
2019-04-23 11:18   ` Linus Walleij
2019-04-23 11:18     ` [PATCH v7 07/14] gpio: thunderx: Use the default parent apis for {request, release}_resources Linus Walleij
2019-04-20 10:09 ` [PATCH v7 08/14] dt-bindings: irqchip: Introduce TISCI Interrupt router bindings Lokesh Vutla
2019-04-20 10:09   ` Lokesh Vutla
2019-04-20 10:09   ` Lokesh Vutla
2019-04-20 10:09 ` [PATCH v7 09/14] irqchip: ti-sci-intr: Add support for Interrupt Router driver Lokesh Vutla
2019-04-20 10:09   ` Lokesh Vutla
2019-04-20 10:09   ` Lokesh Vutla
2019-04-20 10:09 ` [PATCH v7 10/14] dt-bindings: irqchip: Introduce TISCI Interrupt Aggregator bindings Lokesh Vutla
2019-04-20 10:09   ` Lokesh Vutla
2019-04-20 10:09   ` Lokesh Vutla
2019-04-20 10:09 ` [PATCH v7 11/14] irqchip: ti-sci-inta: Add support for Interrupt Aggregator driver Lokesh Vutla
2019-04-20 10:09   ` Lokesh Vutla
2019-04-20 10:09   ` Lokesh Vutla
2019-04-23 10:00   ` Lokesh Vutla
2019-04-23 10:00     ` Lokesh Vutla
2019-04-23 10:00     ` Lokesh Vutla
2019-04-29  8:47     ` Marc Zyngier
2019-04-29  8:47       ` Marc Zyngier
2019-04-29  8:59       ` Lokesh Vutla
2019-04-29  8:59         ` Lokesh Vutla
2019-04-29  8:59         ` Lokesh Vutla
2019-04-29 10:13         ` Marc Zyngier
2019-04-29 10:13           ` Marc Zyngier
2019-04-29 13:11   ` Marc Zyngier
2019-04-29 13:11     ` Marc Zyngier
2019-04-30  6:01     ` Lokesh Vutla [this message]
2019-04-30  6:01       ` Lokesh Vutla
2019-04-30  6:01       ` Lokesh Vutla
2019-04-20 10:09 ` [PATCH v7 12/14] soc: ti: Add MSI domain bus support for Interrupt Aggregator Lokesh Vutla
2019-04-20 10:09   ` Lokesh Vutla
2019-04-20 10:09   ` Lokesh Vutla
2019-04-20 10:09 ` [PATCH v7 13/14] irqchip: ti-sci-inta: Add msi domain support Lokesh Vutla
2019-04-20 10:09   ` Lokesh Vutla
2019-04-20 10:09   ` Lokesh Vutla
2019-04-20 10:09 ` [PATCH v7 14/14] arm64: arch_k3: Enable interrupt controller drivers Lokesh Vutla
2019-04-20 10:09   ` Lokesh Vutla
2019-04-20 10:09   ` Lokesh Vutla

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a0f2a359-7139-18b3-6cb7-3e6445705bbd@ti.com \
    --to=lokeshvutla@ti.com \
    --cc=devicetree@vger.kernel.org \
    --cc=grygorii.strashko@ti.com \
    --cc=jason@lakedaemon.net \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marc.zyngier@arm.com \
    --cc=nm@ti.com \
    --cc=nsekhar@ti.com \
    --cc=peter.ujfalusi@ti.com \
    --cc=robh+dt@kernel.org \
    --cc=ssantosh@kernel.org \
    --cc=t-kristo@ti.com \
    --cc=tglx@linutronix.de \
    --cc=tony@atomide.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.