Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Tue, 12 Nov 2019 00:17:06 +0100
From:   Frederic Weisbecker <frederic@kernel.org>
To:     Ingo Molnar <mingo@kernel.org>
Cc:     Peter Zijlstra <peterz@infradead.org>,
        LKML <linux-kernel@vger.kernel.org>,
        "Paul E . McKenney" <paulmck@linux.vnet.ibm.com>,
        Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH 2/4] irq_work: Fix irq_work_claim() ordering
Message-ID: <20191111231705.GC27917@lenoir>
References: <20191108160858.31665-1-frederic@kernel.org>
 <20191108160858.31665-3-frederic@kernel.org>
 <20191111072005.GA112047@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20191111072005.GA112047@gmail.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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 :)