From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752173AbbCAQHy (ORCPT ); Sun, 1 Mar 2015 11:07:54 -0500 Received: from mail-wg0-f48.google.com ([74.125.82.48]:43890 "EHLO mail-wg0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752564AbbCAQHu (ORCPT ); Sun, 1 Mar 2015 11:07:50 -0500 Message-ID: <54F33950.1090801@colorfullife.com> Date: Sun, 01 Mar 2015 17:07:44 +0100 From: Manfred Spraul User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 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: X-Mailing-List: linux-kernel@vger.kernel.org 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