From: Aniruddha Banerjee <anirudd...@nvidia.com>
The kernel documentation states that the locking of the irq-chip
registers should be handled by the irq-chip driver. In the irq-gic,
the accesses to the irqchip are seemingly not protected and multiple
writes to SPIs from different irq descr
From: Aniruddha Banerjee
The kernel documentation states that the locking of the irq-chip
registers should be handled by the irq-chip driver. In the irq-gic,
the accesses to the irqchip are seemingly not protected and multiple
writes to SPIs from different irq descriptors do RMW requests without
. When multiple irqs call the request_irq at
the same time, there can be a simultaneous write at the gic
distributor, leading to a race. Acquire the gic_lock when the
irq_type is updated.
Signed-off-by: Aniruddha Banerjee <anirudd...@nvidia.com>
---
Changes from V1:
* Moved the spinlock from i
. When multiple irqs call the request_irq at
the same time, there can be a simultaneous write at the gic
distributor, leading to a race. Acquire the gic_lock when the
irq_type is updated.
Signed-off-by: Aniruddha Banerjee
---
Changes from V1:
* Moved the spinlock from irq-gic to irq-gic common, so
. When multiple irqs call the request_irq at
the same time, there can be a simultaneous write at the gic
distributor, leading to a race. Acquire the gic_lock when the
irq_type is updated.
Signed-off-by: Aniruddha Banerjee <aniruddha.n...@gmail.com>
---
drivers/irqchip/irq-gic-common
. When multiple irqs call the request_irq at
the same time, there can be a simultaneous write at the gic
distributor, leading to a race. Acquire the gic_lock when the
irq_type is updated.
Signed-off-by: Aniruddha Banerjee
---
drivers/irqchip/irq-gic-common.c | 8 +++-
1 file changed, 7
as an RFC in case I am
missing anything.
Signed-off-by: Aniruddha Banerjee <anirudd...@nvidia.com>
---
drivers/irqchip/irq-gic.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index 4c797b43614d..61380f5a2254
as an RFC in case I am
missing anything.
Signed-off-by: Aniruddha Banerjee
---
drivers/irqchip/irq-gic.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index 4c797b43614d..61380f5a2254 100644
--- a/drivers/irqchip
The interrupt flag for PPI should not be set to any value, since the
register is read-only. Fix the flags for the PPI interrupts to
IRQ_TYPE_NONE, so that there is no write to the read-only register.
Signed-off-by: Aniruddha Banerjee <anirudd...@nvidia.com>
---
arch/arm64/boot/dts/
The interrupt flag for PPI should not be set to any value, since the
register is read-only. Fix the flags for the PPI interrupts to
IRQ_TYPE_NONE, so that there is no write to the read-only register.
Signed-off-by: Aniruddha Banerjee
---
arch/arm64/boot/dts/nvidia/tegra132.dtsi | 8
> On 31/03/17 , Marc Zyngier wrote:
> On 31/03/17 09:01, Thomas Gleixner wrote:
> > On Thu, 30 Mar 2017, Aniruddha Banerjee wrote:
> >
> >> add IRQF_TRIGGER_MASK on PPI by default so that the PPIs are not
> >> configured as edge-triggered, which may be wrong
> On 31/03/17 , Marc Zyngier wrote:
> On 31/03/17 09:01, Thomas Gleixner wrote:
> > On Thu, 30 Mar 2017, Aniruddha Banerjee wrote:
> >
> >> add IRQF_TRIGGER_MASK on PPI by default so that the PPIs are not
> >> configured as edge-triggered, which may be wrong
add IRQF_TRIGGER_MASK on PPI by default so that the PPIs are
not configured as edge-triggered, which may be wrong for certain GIC
implementations such as the GIC-400
Signed-off-by: Aniruddha Banerjee <anirudd...@nvidia.com>
---
kernel/irq/manage.c | 2 +-
1 file changed, 1 insertion
add IRQF_TRIGGER_MASK on PPI by default so that the PPIs are
not configured as edge-triggered, which may be wrong for certain GIC
implementations such as the GIC-400
Signed-off-by: Aniruddha Banerjee
---
kernel/irq/manage.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Hello,
In the current hung_task framework, there is no way to white-list tasks for
which a higher hang time out might be acceptable and expected even:
Usecase: I want to keep a low hung_task timeout to catch more tasks which are
hung-up. However, certain tasks (like sync, which flushes to a
Hello,
In the current hung_task framework, there is no way to white-list tasks for
which a higher hang time out might be acceptable and expected even:
Usecase: I want to keep a low hung_task timeout to catch more tasks which are
hung-up. However, certain tasks (like sync, which flushes to a
16 matches
Mail list logo
