From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 80A773A1E7F for ; Thu, 25 Dec 2025 15:04:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=18.9.28.11 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766675072; cv=none; b=t87ZLBuLatJC+aazIFembgQPLIiPFfZREMrWOGhRoKLcM6S1qT7/mEHOmRm6WHj3YptNqoOCRpAAZwrI8dbODv5w3LulCd6Uh7Iwq8qTuadl0HRoXe+jSB46aOGpns7AzFnne42/o7i3CSpuZYaTw3/KPv4EqOLG6CUezK5aotU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766675072; c=relaxed/simple; bh=JbvoItepSA5VUF5c0G10/+CxheQc2YH4PbOEDLhOOAw=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=JNLBTXr7Z2/wKh2aqZPz+/luaIPrGdoMRne7o5VgC9wo2aCd3p3MSGwZyp6eESESWsR2U/cieSMU+RpW3xD+NeYmxq5cSH4Fz8ou5gKEURMOnaewhSJTk01IJ41SAj7wlsPmNdzdQnY8iM/kMDW6unyIT+Ac362S7Uj45tOyRyc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=mit.edu; spf=pass smtp.mailfrom=mit.edu; dkim=pass (2048-bit key) header.d=mit.edu header.i=@mit.edu header.b=QZPCDH9I; arc=none smtp.client-ip=18.9.28.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=mit.edu Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=mit.edu Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=mit.edu header.i=@mit.edu header.b="QZPCDH9I" Received: from macsyma.thunk.org (99-196-133-178.cust.exede.net [99.196.133.178] (may be forged)) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 5BPF3XVd001261 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 25 Dec 2025 10:03:43 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing; t=1766675031; bh=k7S4V8aeo01OTZf/0Y2/8z2NyX4vgPtmsFn9Ue73A5E=; h=Date:From:Subject:Message-ID:MIME-Version:Content-Type; b=QZPCDH9IHRT5NFUoHb1D0gOMeg542Y+fyaq06Vvs0j92mgnv8puOLMWS+bFkUbcgG VHlReHsEt7ratBaRue1QpBTphxRZtTNMfSxCAsPzEsRaUKyuHFNNVbpALikwmTxjc1 dHpPwtqxzPMPbOmquZaWDTeUNM4/oIBSAuIrTvldT0aF2VpbXXg0GNGBx30ZXVvyoV ekm54/sguG+xloqvp57UF505Al3J3Ug6X1z9LsLNDwe7RZxWwmBNRZX0RclyHXox6a 2NkDwgehJ76/sAD0Yt9lhBwyQH9JiCmOvfSqT9rmtO6FGM68X/OAGZu1tKhJ2A+n/a rnpGMqpKBQrDg== Received: by macsyma.thunk.org (Postfix, from userid 15806) id 3325A51D24AD; Thu, 25 Dec 2025 10:03:31 -0500 (EST) Date: Thu, 25 Dec 2025 10:03:31 -0500 From: "Theodore Tso" To: Steven Rostedt Cc: "Paul E. McKenney" , Sasha Levin , Julia Lawall , Gabriele Paoloni , Kate Stewart , Chuck Wolber , Dmitry Vyukov , Mark Rutland , Thomas Gleixner , Lorenzo Stoakes , Shuah Khan , Chris Mason , linux-kernel@vger.kernel.org Subject: Re: Follow-up on Linux-kernel code accessibility Message-ID: <20251225150331.GB15088@macsyma.lan> References: <90d56d30-232d-4930-ad9f-5aebade7cdf2@paulmck-laptop> <636d1798-3b37-293a-51b2-55d2ecc6d2d@inria.fr> <20251219170945.GA32430@macsyma.lan> <20251219132812.2a3516df@gandalf.local.home> <20251222104209.15e98861@gandalf.local.home> <89457d2d-153e-4274-b485-2ace983cec4f@paulmck-laptop> <20251224091158.6ab443cb@gandalf.local.home> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20251224091158.6ab443cb@gandalf.local.home> On Wed, Dec 24, 2025 at 09:11:58AM -0500, Steven Rostedt wrote: > /* > * Loop doing repeated quiescent-state forcing until the grace period ends. > */ > static noinline_for_stack void rcu_gp_fqs_loop(void) > { > bool first_gp_fqs = true; > int gf = 0; > unsigned long j; > int ret; > struct rcu_node *rnp = rcu_get_root(); > > j = READ_ONCE(jiffies_till_first_fqs); > if (rcu_state.cbovld) > gf = RCU_GP_FLAG_OVLD; > ret = 0; > for (;;) { > if (rcu_state.cbovld) { > j = (j + 2) / 3; > if (j <= 0) > j = 1; > } > if (!ret || time_before(jiffies + j, rcu_state.jiffies_force_qs)) { > WRITE_ONCE(rcu_state.jiffies_force_qs, jiffies + j); > /* > * jiffies_force_qs before RCU_GP_WAIT_FQS state > * update; required for stall checks. > */ > smp_wmb(); > WRITE_ONCE(rcu_state.jiffies_kick_kthreads, > jiffies + (j ? 3 * j : 2)); > } > > There's a bit of magical manipulation of "j" that I have no idea why it's > doing that. ;-) > > I would love if Julia or Gabriele came up with some specification for that > function. I think we need to separate out two different things. The first is <> the function is doing, and the other is <> the function is doing it. The first is the specification, or the interface contract. The second is the implementation details that are important if you need to modify the function, or want to verify its corrections. I'm reminded of the ancient Unix documentation of how context switching was implemented on a PDP-11, "You are not expected to understand this". But as long as you understood what it was doing, the fact the magic wasn't described in the source code might be OK. OTOH, it's what inspired the Lion's Commentary on the Unix Source Code book. :-) - Ted