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:   Mon, 11 Nov 2019 08:20:05 +0100
From:   Ingo Molnar <mingo@kernel.org>
To:     Frederic Weisbecker <frederic@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: <20191111072005.GA112047@gmail.com>
References: <20191108160858.31665-1-frederic@kernel.org>
 <20191108160858.31665-3-frederic@kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20191108160858.31665-3-frederic@kernel.org>
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


* 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?

Thanks,

	Ingo