Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932233AbbBZTqZ (ORCPT ); Thu, 26 Feb 2015 14:46:25 -0500 Received: from mail-wg0-f47.google.com ([74.125.82.47]:34014 "EHLO mail-wg0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932105AbbBZTqY (ORCPT ); Thu, 26 Feb 2015 14:46:24 -0500 Message-ID: <54EF780B.4060702@colorfullife.com> Date: Thu, 26 Feb 2015 20:46:19 +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 CC: "Paul E. McKenney" , LKML , 1vier1@web.de, Peter Zijlstra , Kirill Tkhai , Ingo Molnar , Josh Poimboeuf Subject: Re: [RFC PATCH] ipc/sem.c: Add one more memory barrier to sem_lock(). References: <1424893009-27191-1-git-send-email-manfred@colorfullife.com> <20150226192929.GA975@redhat.com> In-Reply-To: <20150226192929.GA975@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 Content-Length: 1516 Lines: 52 Hi Oleg, On 02/26/2015 08:29 PM, Oleg Nesterov wrote: >> @@ -341,7 +359,13 @@ static inline int sem_lock(struct sem_array *sma, struct sembuf *sops, >> * Thus: if is now 0, then it will stay 0. >> */ >> if (sma->complex_count == 0) { >> - /* fast path successful! */ >> + /* >> + * Fast path successful! >> + * We only need a final memory barrier. >> + * (see sem_wait_array() for details). >> + */ >> + smp_rmb(); >> + > I'll try to read this again tomorrow, but so far I am confused. > > Most probably I missed something, but this looks unneeded at first glance. No, my fault: I thought long about sem_wait_array() and then I did copy&paste without thinking properly. The sequence is: thread A: spin_lock(&local) thread B: complex_count=??; spin_unlock(&global); <<< release_mb thread A: spin_unlock_wait(&global); <<< control_mb smb_mb__after_control_barrier(); <<< acquire_mb <<< now everything from thread B is visible. <<< and: thread B has dropped the lock, it can't change any protected var <<< and: a new thread C can't acquire a lock, we hold &local. if (complex_count == 0) goto success; I'll update the patch. (cc stable, starting from 3.10...) -- Manfred -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/