netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
To: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-fsdevel@vger.kernel.org
Subject: Re: Distributed storage. Security attributes and ducumentation update.
Date: Thu, 13 Sep 2007 16:22:59 +0400	[thread overview]
Message-ID: <20070913122259.GA20714@2ka.mipt.ru> (raw)
In-Reply-To: <20070910221445.GL11801@linux.vnet.ibm.com>

Hi Paul.

On Mon, Sep 10, 2007 at 03:14:45PM -0700, Paul E. McKenney (paulmck@linux.vnet.ibm.com) wrote:
> > Further TODO list includes:
> > * implement optional saving of mirroring/linear information on the remote
> > 	nodes (simple)
> > * implement netlink based setup (simple)
> > * new redundancy algorithm (complex)
> > 
> > Homepage:
> > http://tservice.net.ru/~s0mbre/old/?section=projects&item=dst
> 
> A couple questions below, but otherwise looks good from an RCU viewpoint.
> 
> 							Thanx, Paul

Thanks for your comments, and sorry for late reply I was at KS/London
trip.
> > +	if (--num) {
> > +		list_for_each_entry_rcu(n, &node->shared, shared) {
> 
> This function is called under rcu_read_lock() or similar, right?
> (Can't tell from this patch.)  It is also OK to call it from under the
> update-side mutex, of course.

Actually not, but it does not require it, since entry can not be removed
during this operations since appropriate reference counter for given node is
being held. It should not be RCU at all.

> > +static int dst_mirror_read(struct dst_request *req)
> > +{
> > +	struct dst_node *node = req->node, *n, *min_dist_node;
> > +	struct dst_mirror_priv *priv = node->priv;
> > +	u64 dist, d;
> > +	int err;
> > +
> > +	req->bio_endio = &dst_mirror_read_endio;
> > +
> > +	do {
> > +		err = -ENODEV;
> > +		min_dist_node = NULL;
> > +		dist = -1ULL;
> > + 
> > +		/*
> > +		 * Reading is never performed from the node under resync.
> > +		 * If this will cause any troubles (like all nodes must be
> > +		 * resynced between each other), this check can be removed
> > +		 * and per-chunk dirty bit can be tested instead.
> > +		 */
> > +
> > +		if (!test_bit(DST_NODE_NOTSYNC, &node->flags)) {
> > +			priv = node->priv;
> > +			if (req->start > priv->last_start)
> > +				dist = req->start - priv->last_start;
> > +			else
> > +				dist = priv->last_start - req->start;
> > +			min_dist_node = req->node;
> > +		}
> > +
> > +		list_for_each_entry_rcu(n, &node->shared, shared) {
> 
> I see one call to this function that appears to be under the update-side
> mutex, but I cannot tell if the other calls are safe.  (Safe as in either
> under the update-side mutex or under rcu_read_lock() and friends.)

The same here - those processing function are called from
generic_make_request() from any lock on top of them. Each node is linked
into the list of the first added node, which reference counter is
increased in higher layer. Right now there is no way to add or remove
nodes after array was started, such functionality requires storage tree
lock to be taken and RCU can not be used (since it requires sleeping and
I did not investigate sleepable RCU for this purpose).

So, essentially RCU is not used in DST :)

Thanks for review, Paul.

-- 
	Evgeniy Polyakov

  reply	other threads:[~2007-09-13 12:22 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-31 16:06 Distributed storage. Security attributes and ducumentation update Evgeniy Polyakov
2007-09-10 22:14 ` Paul E. McKenney
2007-09-13 12:22   ` Evgeniy Polyakov [this message]
2007-09-13 15:03     ` Paul E. McKenney
2007-09-17 18:22 ` Pavel Machek
2007-09-22 11:31   ` Evgeniy Polyakov

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=20070913122259.GA20714@2ka.mipt.ru \
    --to=johnpol@2ka.mipt.ru \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=paulmck@linux.vnet.ibm.com \
    /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 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).