LKML Archive on 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
Subject: Re: [RFC] rcu: doc: update example about stale data
Date: Tue, 30 Oct 2018 16:50:39 -0700	[thread overview]
Message-ID: <20181030235039.GX4170@linux.ibm.com> (raw)
In-Reply-To: <20181029011631.GA261737@joelaf.mtv.corp.google.com>

On Sun, Oct 28, 2018 at 06:16:31PM -0700, Joel Fernandes wrote:
> On Sun, Oct 28, 2018 at 10:21:42AM -0700, Paul E. McKenney wrote:
> > On Sat, Oct 27, 2018 at 07:16:53PM -0700, Joel Fernandes (Google) wrote:
> > > The RCU example for 'rejecting stale data' on system-call auditting
> > > stops iterating through the rules if a deleted one is found. It makes
> > > more sense to continue looking at other rules once a deleted one is
> > > rejected. Although the original example is fine, this makes it more
> > > meaningful.
> > > 
> > > Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org>
> > 
> > Does the actual audit code that this was copied from now include the
> > continue statement?  If so, please update the commit log to state that
> > and then I will take the resulting patch.  (This example was inspired
> > by a long-ago version of the actual audit code.)
> 
> The document talks of a situation that could be but is not really in the
> implementation. It says "If the system-call audit module were to ever need to
> reject stale data". So its not really something implemented. I was just
> correcting the example you had there since it made more sense to me to
> continue looking for other rules in the list once a rule was shown to be
> stale. It just makes the example more correct.
> 
> But I'm Ok if you want to leave that alone ;-) Hence, the RFC tag to this
> patch ;-)

Well, I do agree that there are situations where you need to keep
going.  But in the common case where only one instance of a given key
is allowed, and where the list is either (1) sorted and/or (2) added
to at the beginning, if you find a deleted element with a given key,
you are guaranteed that you won't find another with that key even if
you continue scanning the list.  After all, if you did find a deleted
element, the duplicate either is not on the list in the sorted case
or is behind you in the add-at-front case.

And in the more complex cases where persistent searching is required,
you usually have to restart the search instead of continuing it.  Besides,
things like the Issaquah Challenge don't seem to belong in introductory
documentation on RCU.  ;-)

							Thanx, Paul


  reply	other threads:[~2018-10-30 23:50 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-28  2:16 Joel Fernandes (Google)
2018-10-28  4:44 ` Joel Fernandes
2018-10-28 17:29   ` Paul E. McKenney
2018-10-28 17:21 ` Paul E. McKenney
2018-10-29  1:16   ` Joel Fernandes
2018-10-30 23:50     ` Paul E. McKenney [this message]
2018-10-31  0:58       ` 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=20181030235039.GX4170@linux.ibm.com \
    --to=paulmck@linux.ibm.com \
    --cc=joel@joelfernandes.org \
    --cc=linux-kernel@vger.kernel.org \
    --subject='Re: [RFC] rcu: doc: update example about stale data' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).