Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755542AbbLEAev (ORCPT ); Fri, 4 Dec 2015 19:34:51 -0500 Received: from relay4-d.mail.gandi.net ([217.70.183.196]:40164 "EHLO relay4-d.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754353AbbLEAet (ORCPT ); Fri, 4 Dec 2015 19:34:49 -0500 Date: Fri, 4 Dec 2015 16:34:43 -0800 From: Josh Triplett To: "Paul E. McKenney" Cc: linux-kernel@vger.kernel.org, mingo@kernel.org, jiangshanlai@gmail.com, dipankar@in.ibm.com, akpm@linux-foundation.org, mathieu.desnoyers@efficios.com, tglx@linutronix.de, peterz@infradead.org, rostedt@goodmis.org, dhowells@redhat.com, edumazet@google.com, dvhart@linux.intel.com, fweisbec@gmail.com, oleg@redhat.com, bobby.prani@gmail.com Subject: Re: [PATCH tip/core/rcu 1/8] documentation: Record RCU requirements Message-ID: <20151205003443.GC26663@cloud> References: <20151204234952.GA22805@linux.vnet.ibm.com> <1449273026-23633-1-git-send-email-paulmck@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1449273026-23633-1-git-send-email-paulmck@linux.vnet.ibm.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5370 Lines: 154 The content of the document seems fine; a few comments below on meta-issues. On Fri, Dec 04, 2015 at 03:50:19PM -0800, Paul E. McKenney wrote: > --- /dev/null > +++ b/Documentation/RCU/Design/Requirements/Requirements.html > @@ -0,0 +1,2799 @@ > + > + > + + "http://www.w3.org/TR/html4/loose.dtd"> Nit: these days, this should just be: > + > + A Tour Through RCU's Requirements [LWN.net] > + Is there a good reason to not use charset=utf-8 here? > + > +

A Tour Through RCU's Requirements

> + > +

Copyright IBM Corporation, 2015

If you're aiming for a properly formatted copyright notice, the year typically comes first, followed by the copyright holder. That said, your corporate guidelines presumably have a specific format; is this that format? > +

Author: Paul E. McKenney

> +

The initial version of this document appeared in the > +LWN articles > +here, > +here, and > +here.

s/http/https/g > +

> +All that aside, here are the categories of currently known RCU requirements: > +

> + > +
    > +
  1. Anchors don't typically have spaces in them. This may work in some browsers, but it doesn't validate. You should either use %20 or (better) use a '-'. > +

    > +This is followed by a summary, > +which is in turn followed by the inevitable > +answers to the quick quizzes. (Note: when editing anchors, don't forget to handle the target of this in the generation script.) > +

    > +This scenario resembles one of the first uses of RCU in > +DYNIX/ptx, s/http/https/ > +

    > +However, this temptation must be resisted because there are a > +surprisingly large number of ways that the compiler > +(to say nothing of > +DEC Alpha CPUs) This link sadly doesn't seem to work anymore; it redirects to HP's general page on OpenVMS, not a copy of that specific article.o Use this instead, assuming no current live version exists: https://web.archive.org/web/20120720095054/http://www.openvms.compaq.com/wizard/wiz_2637.html > +

  2. It is also easy to forget to use rcu_assign_pointer() > + and rcu_dereference(), perhaps (incorrectly) > + substituting a simple assignment. > + To catch this sort of error, a given RCU-protected pointer may be > + tagged with __rcu, after which running sparse > + with CONFIG_SPARSE_RCU_POINTER=y will complain > + about simple-assignment accesses to that pointer. > + Arnd Bergmann made me aware of this requirement, and also > + supplied the needed > + patch series. s/http/https/ > +
  3. Open-coded use of rcu_assign_pointer() and > + rcu_dereference() to create typical linked > + data structures can be surprisingly error-prone. > + Therefore, RCU-protected > + linked lists s/http/https/ > +

    > +This all should be quite obvious, but the fact remains that > +Linus Torvalds recently had to > +remind > +me of this requirement. I'd suggest using the lkml.kernel.org redirector for this link, along with a Message-Id. > +

    > +The name notwithstanding, some Linux-kernel architectures > +can have nested NMIs, which RCU must handle correctly. > +Andy Lutomirski > +surprised me > +with this requirement; > +he also kindly surprised me with > +an algorithm > +that meets this requirement. These links should both use lkml.kernel.org as well. Doubly important because lkml.org is often down or has broken messages in its archive. > +

    > +RCU therefore provides > +rcu_barrier(), s/http/https/ > +

    > +This pair of mutual scheduler-RCU requirements came as a > +complete surprise. s/http/https/ > +This requirement made its presence known after users made it > +clear that an earlier > +real-time patch s/http/https/ > +did not meet their needs, in conjunction with some > +RCU issues lkml.kernel.org > +

    > +The > +RCU-bh API s/http/https/ (and the same for all later lwn links in the document) - Josh Triplett -- 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/