lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 8 May 2019 12:26:35 -0400 From: Joel Fernandes <joel@...lfernandes.org> To: "Paul E. McKenney" <paulmck@...ux.ibm.com> Cc: linux-kernel@...r.kernel.org, rcu@...r.kernel.org, Josh Triplett <josh@...htriplett.org>, Steven Rostedt <rostedt@...dmis.org>, Mathieu Desnoyers <mathieu.desnoyers@...icios.com>, Lai Jiangshan <jiangshanlai@...il.com>, Jonathan Corbet <corbet@....net>, linux-doc@...r.kernel.org Subject: Re: [PATCH] doc/rcu: Correct field_count field naming in examples 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) <joel@...lfernandes.org> > > 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 > > >
Powered by blists - more mailing lists