Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp5294061yba; Wed, 8 May 2019 10:49:48 -0700 (PDT) X-Google-Smtp-Source: APXvYqyQdQ8nG3C9FPP4xoGwkUHUmUYXkXgGKiBPUuBmiIujylCyQGbfQWpVNI+iIWcrYQ0vpVua X-Received: by 2002:a17:902:6842:: with SMTP id f2mr49519102pln.189.1557337788523; Wed, 08 May 2019 10:49:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557337788; cv=none; d=google.com; s=arc-20160816; b=WkoADyhoEeLocsjpA0CgcZAksuyxBVjtSIrr+8VsV9iH9Wl3CDIhT1J7SZxZ4DzydT iS6HhtVe/UPWmrts9e/v0Clk7bPKMgC7O9rgqIlY4YdZHvOR0ddtY7Aiun7MGlpGMHDo blaQUjXmphCbgQgbZUQfDQdkhSfp3fe8il7NFHTFPRw6gl4RU6nYUcocnDcmkTcle7dn XI0cs+COXoKxvF6x1lC9bLAernEpHrl+tBoPmEvHmAxQranXZuzH+4zeg4s7c8Q7Nfs2 wbhkJIPqFKFoVyGiXmoTBSCKhxgQePwHKfEOZGrCGOae7Cpevw3rFVcHcsm7m0Rr2HPS AyaA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=q0oFZG4f7HJO+ERWWpCdCvMECN1hBHKXTqijgUivnq8=; b=MEUz9urTs6UPtsxM7ax2VoJruCYfajP3qSyZkA1WSRaL47KDgoV4GPG45zGEUyPvDB zbjV6H//t/Mjac/d3eYOmkBUu5awq2lsVAFuhFltKp2T09NIab+L6Y5wjJ7OYbLo0HWK CijA7Y6Lp6kbbnbilZVH6by1v0jSHb/UevSjejeNry/z2vk2qSjpIdsHhl42m2LO3H6e u2z7Ar+klblK5692bSKdz5KGaZ+C0/BrE9UYvcQ5RFxUDNU3pHMKtrcfJzP+P8Ru+rdK 6mx6Mclyg0L88In7FcZwWfoaGHeAop6gvAbSjD5VONbFUcennSnlccT1H8DKk6DgFake mnHg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@joelfernandes.org header.s=google header.b=c5i0CndM; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z6si20912618pgp.35.2019.05.08.10.49.32; Wed, 08 May 2019 10:49:48 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@joelfernandes.org header.s=google header.b=c5i0CndM; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728079AbfEHQ0j (ORCPT + 99 others); Wed, 8 May 2019 12:26:39 -0400 Received: from mail-pf1-f196.google.com ([209.85.210.196]:34353 "EHLO mail-pf1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728050AbfEHQ0j (ORCPT ); Wed, 8 May 2019 12:26:39 -0400 Received: by mail-pf1-f196.google.com with SMTP id n19so2210276pfa.1 for ; Wed, 08 May 2019 09:26:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelfernandes.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=q0oFZG4f7HJO+ERWWpCdCvMECN1hBHKXTqijgUivnq8=; b=c5i0CndMjmSXAkq3RkmPjkKSY6wap+HLlQqr8phD0UrE2QvaciXJkTSMJaTN2xNSzN iWZQlovltuZrUDfxEexT0ycYd1QBFbFTdLIDi1cSEbIyFMlZqm6uaC0cCm+RiXrEmcdA TchzuiDHvE9PyPLOHlVP6eOZ4GjmrJ25w5WX4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=q0oFZG4f7HJO+ERWWpCdCvMECN1hBHKXTqijgUivnq8=; b=mA2vUuWrR4IWbRmqxN/NBtR0ClxcEixVHcZpr7rEY64GeARR5wrFCkwjYXJKN0losp V/YCPqfV8dGMnTjhuVDYvunQE5UyFWnUJRT+Ponkyl+1ysXSQKRuGXnzBZ8Q8JPlx6D9 KKXiY+e1oP1LzCjC4ssD2NpuXqkevJyPyUF5r56NyZ2zQF6W+EWaxfkMySxS0YooyGnl 3nm9HlaoUqdBCG2ggm4bQzZxK1nX496qUif6d6P5I9RVYZ/jy5JFePddrYBBVk5Gi2c0 mm7BRtvqppq0PBwiLcpqfs3ulZBqAWXxCKsVEFmoG4D2eGdj4MdV7+1gWytsci2++wpq u+lA== X-Gm-Message-State: APjAAAWCcE05S7DEEy8V+oH7wU5LxF2UAwHWFnZoYbD1/9D4rElBnH8M cbX/CkFbOCzA1YsUkXejKSm+HQ== X-Received: by 2002:a63:3746:: with SMTP id g6mr48049952pgn.422.1557332798078; Wed, 08 May 2019 09:26:38 -0700 (PDT) Received: from localhost ([2620:15c:6:12:9c46:e0da:efbf:69cc]) by smtp.gmail.com with ESMTPSA id g24sm26535910pfi.126.2019.05.08.09.26.36 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 08 May 2019 09:26:36 -0700 (PDT) Date: Wed, 8 May 2019 12:26:35 -0400 From: Joel Fernandes To: "Paul E. McKenney" Cc: linux-kernel@vger.kernel.org, rcu@vger.kernel.org, Josh Triplett , Steven Rostedt , Mathieu Desnoyers , Lai Jiangshan , Jonathan Corbet , linux-doc@vger.kernel.org Subject: Re: [PATCH] doc/rcu: Correct field_count field naming in examples Message-ID: <20190508162635.GD187505@google.com> References: <20190505020328.165839-1-joel@joelfernandes.org> <20190507000453.GB3923@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190507000453.GB3923@linux.ibm.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 06, 2019 at 05:04:53PM -0700, Paul E. McKenney wrote: > On Sat, May 04, 2019 at 10:03:10PM -0400, Joel Fernandes (Google) wrote: > > I believe this field should be called field_count instead of file_count. > > Correct the doc with the same. > > > > Signed-off-by: Joel Fernandes (Google) > > But if we are going to update this, why not update it with the current > audit_filter_task(), audit_del_rule(), and audit_add_rule() code? > > Hmmm... One reason is that some of them have changed beyond recognition. It seems to me that these 3 functions are just structured differently but is conceptually the same. There is now an array of lists stored in audit_filter_list. Each list is a set of rules. Versus in the listRCU.txt, there is only one global. The other difference is there is a mutex held &audit_filter_mutex audit_{add,del}_rule. Where as in listRCU, it says that is not needed since another mutex is already held. > And this example code predates v2.6.12. ;-) > > So good eyes, but I believe that this really does reflect the ancient > code... > > On the other hand, would you have ideas for more modern replacement > examples? There are 3 cases I can see in listRCU.txt: (1) action taken outside of read_lock (can tolerate stale data), no in-place update. this is the best possible usage of RCU. (2) action taken outside of read_lock, in-place updates this is good as long as not too many in-place updates. involves copying creating new list node and replacing the node being updated with it. (3) cannot tolerate stale data: here a deleted or obsolete flag can be used protected by a per-entry lock. reader aborts if object is stale. Any replacement example must make satisfy (3) too? The only example for (3) that I know of is sysvipc sempahores which you also mentioned in the paper. Looking through this code, it hasn't changed conceptually and it could be a fit for an example (ipc_valid_object() checks for whether the object is stale). The other example could be dentry look up which uses seqlocks for the RCU-walk case? But that could be too complex. This is also something I first learnt from the paper and then the excellent path-lookup.rst document in kernel sources. I will keep any eye out for other examples in the kernel code as well. Let me know what you think, thanks! - Joel > > --- > > Documentation/RCU/listRCU.txt | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/Documentation/RCU/listRCU.txt b/Documentation/RCU/listRCU.txt > > index adb5a3782846..190e666fc359 100644 > > --- a/Documentation/RCU/listRCU.txt > > +++ b/Documentation/RCU/listRCU.txt > > @@ -175,7 +175,7 @@ otherwise, the added fields would need to be filled in): > > list_for_each_entry(e, list, list) { > > if (!audit_compare_rule(rule, &e->rule)) { > > e->rule.action = newaction; > > - e->rule.file_count = newfield_count; > > + e->rule.field_count = newfield_count; > > write_unlock(&auditsc_lock); > > return 0; > > } > > @@ -204,7 +204,7 @@ RCU ("read-copy update") its name. The RCU code is as follows: > > return -ENOMEM; > > audit_copy_rule(&ne->rule, &e->rule); > > ne->rule.action = newaction; > > - ne->rule.file_count = newfield_count; > > + ne->rule.field_count = newfield_count; > > list_replace_rcu(&e->list, &ne->list); > > call_rcu(&e->rcu, audit_free_rule); > > return 0; > > -- > > 2.21.0.1020.gf2820cf01a-goog > > >