From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751496AbbCBIdj (ORCPT ); Mon, 2 Mar 2015 03:33:39 -0500 Received: from bombadil.infradead.org ([198.137.202.9]:53904 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750870AbbCBIdi (ORCPT ); Mon, 2 Mar 2015 03:33:38 -0500 Date: Mon, 2 Mar 2015 09:33:20 +0100 From: Peter Zijlstra To: Mathieu Desnoyers Cc: mingo@kernel.org, rusty@rustcorp.com.au, oleg@redhat.com, paulmck@linux.vnet.ibm.com, linux-kernel@vger.kernel.org, andi@firstfloor.org, rostedt@goodmis.org, tglx@linutronix.de, Michel Lespinasse , Andrea Arcangeli , David Woodhouse , Rik van Riel Subject: Re: [RFC][PATCH 6/9] seqlock: Better document raw_write_seqcount_latch() Message-ID: <20150302083320.GC5029@twins.programming.kicks-ass.net> References: <20150228212447.381543289@infradead.org> <20150228213110.188801887@infradead.org> <1524903258.193820.1425218543344.JavaMail.zimbra@efficios.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1524903258.193820.1425218543344.JavaMail.zimbra@efficios.com> User-Agent: Mutt/1.5.21 (2012-12-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Mar 01, 2015 at 02:02:23PM +0000, Mathieu Desnoyers wrote: > > + * So during the modification, queries are first redirected to data[1]. Then we > > + * modify data[0]. When that is complete, we redirect queries back to data[0] > > + * and we can modify data[1]. > > + * > > + * NOTE: The non-requirement for atomic modifications does _NOT_ include > > + * the publishing of new entries in the case where data is a dynamic > > + * data structure. > > + * > > + * An iteration might start in data[0] and get suspended long enough > > + * to miss an entire modification sequence, once it resumes it might > > + * observe the new entry. > > We might want to hint that in the case of dynamic data structures, > RCU read-side C.S. and grace period should be used together with the > latch to handle the object teardown. Can do. > The latch, AFAIU, takes care of making sure the new objects are > initialized before being published into the data structure, so there > would be no need to use RCU assign pointer. However, we really need > RCU around reads, along with a grace period between removal of an object > and its teardown. So I do need the rcu_assign_pointer for the RB link because that also initializes the rb_node itself. Or put differently, be _very_ _VERY_ sure your entire object is initialized before the latch. Secondly, note that the latch does a WMB and rcu_assign_pointer does a RELEASE, these are not equivalent. So I don't think I will highlight this particular point. If you're sure enough to know the difference you can get away with it, sure. But in general I think people should still use rcu_assign_pointer; if only to make Paul sleep better at night ;-)