Messages in this thread | | | Date | Tue, 12 Nov 2019 00:17:06 +0100 | From | Frederic Weisbecker <> | Subject | Re: [PATCH 2/4] irq_work: Fix irq_work_claim() ordering |
| |
On Mon, Nov 11, 2019 at 08:20:05AM +0100, Ingo Molnar wrote: > > * Frederic Weisbecker <frederic@kernel.org> wrote: > > > When irq_work_claim() finds IRQ_WORK_PENDING flag already set, we just > > return and don't raise a new IPI. We expect the destination to see > > and handle our latest updades thanks to the pairing atomic_xchg() > > in irq_work_run_list(). > > > > But cmpxchg() doesn't guarantee a full memory barrier upon failure. So > > it's possible that the destination misses our latest updates. > > > > So use atomic_fetch_or() instead that is unconditionally fully ordered > > and also performs exactly what we want here and simplify the code. > > Just curious, how was this bug found - in the wild, or via code review?
Well, I wanted to make sure the nohz kcpustat patches are safe and I had a last minute doubt about that irq work scenario. So I would say code review :)
| |