From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753971AbcGUTrq (ORCPT ); Thu, 21 Jul 2016 15:47:46 -0400 Received: from mx2.suse.de ([195.135.220.15]:56948 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752077AbcGUTro (ORCPT ); Thu, 21 Jul 2016 15:47:44 -0400 Date: Thu, 21 Jul 2016 12:47:35 -0700 From: Davidlohr Bueso To: Sebastian Andrzej Siewior Cc: linux-kernel@vger.kernel.org, Peter Zijlstra , tglx@linutronix.de, Manfred Spraul , Andrew Morton Subject: Re: [PATCH v4] ipc/msg: Implement lockless pipelined wakeups Message-ID: <20160721194735.GA1881@linux-80c1.suse> References: <1469029517-18577-1-git-send-email-bigeasy@linutronix.de> <20160721001612.GA3066@linux-80c1.suse> <20160721102356.GB6323@linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20160721102356.GB6323@linutronix.de> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 21 Jul 2016, Sebastian Andrzej Siewior wrote: >* Davidlohr Bueso | 2016-07-20 17:16:12 [-0700]: > >>Just as with expunge_all and the E2BIG case, could you remove that explicit >>barrier (B) and just rely on wake_q_add? > >Just did. So we have just a smp_rmb() on the reader side and the >comment talks about smb_wmb() and at the spot where we should have the >smb_wmb we have a comment why we don't have one :) >For my understanding: we need that smp_rmb() to ensure that everything >past that cmpxchg() is visible on all other CPUs so we don't have the >wakeup before we r_msg reads != -EAGAIN, right? Hmm I'm having second thoughts about the need for barrier (A). As you know, originally we had it to prevent races with do_exit() from the receiver thread if the r_msg was set before doing the wakeup, we could face a use-after-free scenario. Now, by delaying the wakeup, the receiver task should always see whatever r_msg is set to by the waker, even if we get reordered with wake_q_add() as the actual wakeup_process() does not occur yet, and hence the receiver is still blocked while this is going on -- iow, we avoid entirely the need to explicitly wait until pipelined_send/expunge_all are done. Similarly, "barrier (B)" simply serves to pair with wake_up_q() such that we don't miss wakeups, but that's always handled by the wake_q machinery anyway. So if this is the case (which is how you had it in some previous version of this patch), we can get rid of the pair diagram altogether as well. Manfred, Peter, does all this make sense to you guys? Thanks, Davidlohr