Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932174AbcKQTww (ORCPT ); Thu, 17 Nov 2016 14:52:52 -0500 Received: from mail-pf0-f194.google.com ([209.85.192.194]:35506 "EHLO mail-pf0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752905AbcKQTwv (ORCPT ); Thu, 17 Nov 2016 14:52:51 -0500 Date: Thu, 17 Nov 2016 11:53:04 -0800 From: Lance Roy To: Lai Jiangshan Cc: "Paul E. McKenney" , LKML , Ingo Molnar , dipankar@in.ibm.com, akpm@linux-foundation.org, Mathieu Desnoyers , Josh Triplett , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , David Howells , Eric Dumazet , dvhart@linux.intel.com, =?UTF-8?B?RnLDqWTDqXJpYw==?= Weisbecker , oleg@redhat.com, pranith kumar Subject: Re: [PATCH RFC tip/core/rcu] SRCU rewrite Message-ID: <20161117115304.0ff3f84e@gmail.com> In-Reply-To: References: <20161114183636.GA28589@linux.vnet.ibm.com> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1892 Lines: 36 On Thu, 17 Nov 2016 21:58:34 +0800 Lai Jiangshan wrote: > from the changelog, it sounds like that "ULONG_MAX - NR_CPUS" is the limit > of the implements(old or this one). but actually the real max number of > active readers is much smaller, I think ULONG_MAX/4 can be used here instead > and that part of the changelog can be removed. In the old version, there are two separate limits. There first is that there are no more than ULONG_MAX nested or parallel readers, as otherwise ->c[] would overflow. The other limit is to prevent ->seq[] from overflowing during srcu_readers_active_idx_check(). For this to happen, there must be ULONG_MAX+1 readers that loaded ->completed before srcu_flip() was run which then increment ->seq[]. The ->seq[] array is supposed to prevent srcu_readers_active_idx_check() from completing successfully if any such readers increment ->seq[], because otherwise they could decrement ->c[] while it is being read, which could cause it to incorrectly report that there are no active readers. If ->seq[] overflows then there is nothing (except how improbable it is) to prevent this from happening. I used to think (because of the previous comment) that there could be at most one such increment of ->seq[] per CPU, as they would have to be using to old value of ->completed and preemption would be disabled. This is not the case because there are no barriers around srcu_flip(), so the processor is not required to increment ->completed before reading ->seq[] the first time, nor is it required to wait until it is done reading ->seq[] the second time before incrementing. This means that the following code could cause ->seq[] to increment an arbitrarily large number of times between the two ->seq[] loads in srcu_readers_active_idx_check(). while (true) { int idx = srcu_read_lock(sp); srcu_read_unlock(sp, idx); } Thanks, Lance