From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <54F33950.1090801@colorfullife.com> Date: Sun, 01 Mar 2015 17:07:44 +0100 From: Manfred Spraul MIME-Version: 1.0 To: Oleg Nesterov , Peter Zijlstra CC: "Paul E. McKenney" , LKML , 1vier1@web.de, Kirill Tkhai , Ingo Molnar , Josh Poimboeuf , stable@vger.kernel.org Subject: Re: [PATCH] ipc/sem.c: Update/correct memory barriers. References: <1425155775-23909-1-git-send-email-manfred@colorfullife.com> <20150228214533.GY5029@twins.programming.kicks-ass.net> <20150301132232.GA20691@redhat.com> In-Reply-To: <20150301132232.GA20691@redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: Hi Oleg, On 03/01/2015 02:22 PM, Oleg Nesterov wrote: > On 02/28, Peter Zijlstra wrote: >> On Sat, Feb 28, 2015 at 09:36:15PM +0100, Manfred Spraul wrote: >>> +/* >>> + * Place this after a control barrier (such as e.g. a spin_unlock_wait()) >>> + * to ensure that reads cannot be moved ahead of the control_barrier. >>> + * Writes do not need a barrier, they are not speculated and thus cannot >>> + * pass the control barrier. >>> + */ >>> +#ifndef smp_mb__after_control_barrier >>> +#define smp_mb__after_control_barrier() smp_rmb() >>> +#endif >> Sorry to go bike shedding again; but should we call this: >> >> smp_acquire__after_control_barrier() ? >> >> The thing is; its not a full MB because: >> >> - stores might actually creep into it; while the control dependency >> guarantees stores will not creep out, nothing is stopping them from >> getting in; >> >> - its not transitive, and our MB is defined to be so. > I agree, so perhaps it should be named smp_acquire_after_unlock_wait ? > even if it is actually stronger than "acquire"... > > To me "control_barrier" looks a bit confusing. I think this helper should > be only used after spin_unlock_wait() or spin_is_locked/unlocked(). Then lets make two helpers: smp_acquire__after_spin_unlock_wait() and smp_acquire__after_spin_is_unlocked(). I'll send a new proposal. Oleg: I would leave the update of task_work_run() to you: The current code is not buggy, doing an docu update immediately and risk that the patch might collide with other changes is probably not worth it. -- Manfred