All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.ibm.com>
To: Joel Fernandes <joel@joelfernandes.org>
Cc: linux-kernel@vger.kernel.org, rcu@vger.kernel.org,
	Josh Triplett <josh@joshtriplett.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	Jonathan Corbet <corbet@lwn.net>,
	linux-doc@vger.kernel.org
Subject: Re: [PATCH] doc/rcu: Correct field_count field naming in examples
Date: Wed, 8 May 2019 11:16:38 -0700	[thread overview]
Message-ID: <20190508181638.GY3923@linux.ibm.com> (raw)
In-Reply-To: <20190508162635.GD187505@google.com>

On Wed, May 08, 2019 at 12:26:35PM -0400, Joel Fernandes wrote:
> 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@joelfernandes.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.

Agreed.

> > 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?

It would be OK to have a separate example for (3).  It would of course
be nicer to have one example for all three, but not all -that- important.

> 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).

That is indeed the classic canonical example.  ;-)

> 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.

This is a great example, but it would need serious simplification for
use in the Documentation/RCU directory.  Note that dcache uses it to
gain very limited and targeted consistency -- only a few types of updates
acquire the write-side of that seqlock.

Might be quite worthwhile to have a simplified example, though!
Perhaps a trivial hash table where write-side sequence lock is acquired
only when moving an element from one chain to another?

> I will keep any eye out for other examples in the kernel code as well.

Very good!

							Thanx, Paul

> 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
> > > 
> > 
> 


  reply	other threads:[~2019-05-08 18:16 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-05  2:03 [PATCH] doc/rcu: Correct field_count field naming in examples Joel Fernandes (Google)
2019-05-07  0:04 ` Paul E. McKenney
2019-05-08 16:26   ` Joel Fernandes
2019-05-08 18:16     ` Paul E. McKenney [this message]
2019-05-11 22:11       ` Andrea Parri
2019-05-12  0:41         ` Paul E. McKenney
2019-05-12  1:09           ` Andrea Parri
2019-05-13  3:43       ` Joel Fernandes
2019-05-14 22:13         ` Paul E. McKenney
2019-05-25 10:07       ` Joel Fernandes

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190508181638.GY3923@linux.ibm.com \
    --to=paulmck@linux.ibm.com \
    --cc=corbet@lwn.net \
    --cc=jiangshanlai@gmail.com \
    --cc=joel@joelfernandes.org \
    --cc=josh@joshtriplett.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=rcu@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.