From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754502AbcETQVB (ORCPT ); Fri, 20 May 2016 12:21:01 -0400 Received: from mx2.suse.de ([195.135.220.15]:58408 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751643AbcETQVA (ORCPT ); Fri, 20 May 2016 12:21:00 -0400 Date: Fri, 20 May 2016 09:20:40 -0700 From: Davidlohr Bueso To: Peter Zijlstra Cc: manfred@colorfullife.com, Waiman.Long@hpe.com, mingo@kernel.org, torvalds@linux-foundation.org, ggherdovich@suse.com, mgorman@techsingularity.net, linux-kernel@vger.kernel.org, Paul McKenney , Will Deacon Subject: Re: sem_lock() vs qspinlocks Message-ID: <20160520162040.GD7086@linux-uzut.site> References: <20160520053926.GC31084@linux-uzut.site> <20160520115819.GF3193@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20160520115819.GF3193@twins.programming.kicks-ass.net> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 20 May 2016, Peter Zijlstra wrote: >The problem is that the clear_pending_set_locked() is an unordered >store, therefore this store can be delayed until no later than >spin_unlock() (which orders against it due to the address dependency). > >This opens numerous races; for example: > > ipc_lock_object(&sma->sem_perm); > sem_wait_array(sma); > > false -> spin_is_locked(&sma->sem_perm.lock) > >is entirely possible, because sem_wait_array() consists of pure reads, >so the store can pass all that, even on x86. I had pondered at the unordered stores in clear_pending_set_locked() for arm, for example, but I _certainly_ missed this for x86 inside the ACQUIRE region. Thanks, Davidlohr