Messages in this thread | | | From | Bartosz Golaszewski <> | Date | Thu, 8 Nov 2018 21:55:02 +0100 | Subject | Re: [PATCH] irq/irq_sim: add locking |
| |
czw., 8 lis 2018 o 20:41 Uwe Kleine-König <u.kleine-koenig@pengutronix.de> napisał(a): > > Hello Bartosz, > > On Thu, Nov 08, 2018 at 05:47:48PM +0100, Bartosz Golaszewski wrote: > > Two threads can try to fire the irq_sim with different offsets and will > > end up fighting for the irq_work asignment. To fix it: add a mutex and > > lock it before firing. > > > > Suggested-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> > > Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl> > > --- > > include/linux/irq_sim.h | 1 + > > kernel/irq/irq_sim.c | 5 +++++ > > 2 files changed, 6 insertions(+) > > > > diff --git a/include/linux/irq_sim.h b/include/linux/irq_sim.h > > index 630a57e55db6..676bfa0c12b9 100644 > > --- a/include/linux/irq_sim.h > > +++ b/include/linux/irq_sim.h > > @@ -29,6 +29,7 @@ struct irq_sim { > > int irq_base; > > unsigned int irq_count; > > struct irq_sim_irq_ctx *irqs; > > + struct mutex lock; > > }; > > > > int irq_sim_init(struct irq_sim *sim, unsigned int num_irqs); > > diff --git a/kernel/irq/irq_sim.c b/kernel/irq/irq_sim.c > > index dd20d0d528d4..2f06c24b51a0 100644 > > --- a/kernel/irq/irq_sim.c > > +++ b/kernel/irq/irq_sim.c > > @@ -74,6 +74,7 @@ int irq_sim_init(struct irq_sim *sim, unsigned int num_irqs) > > } > > > > init_irq_work(&sim->work_ctx.work, irq_sim_handle_irq); > > + mutex_init(&sim->lock); > > sim->irq_count = num_irqs; > > > > return sim->irq_base; > > @@ -142,10 +143,14 @@ EXPORT_SYMBOL_GPL(devm_irq_sim_init); > > */ > > void irq_sim_fire(struct irq_sim *sim, unsigned int offset) > > { > > + mutex_lock(&sim->lock); > > + > > if (sim->irqs[offset].enabled) { > > sim->work_ctx.irq = irq_sim_irqnum(sim, offset); > > irq_work_queue(&sim->work_ctx.work); > > } > > + > > + mutex_unlock(&sim->lock); > > This doesn't fix the issue I think. irq_work_queue() only schedules the > work function. If after irq_sim_fire() returned but before the worker > runs another irq_sim_fire() is issued the value is still overwritten. >
Looking at irq_work_queue(): while there may be some arch-specific details deeper down the stack, it seems that unless the work is IRQ_WORK_LAZY, the handler should be executed immediately. I'll verify tomorrow though.
Bart
| |