All of lore.kernel.org
 help / color / mirror / Atom feed
From: "J. R. Okajima" <hooanon05g@gmail.com>
To: viro@ZenIV.linux.org.uk, linux-fsdevel@vger.kernel.org
Subject: Q. hlist_bl_add_head_rcu() in d_alloc_parallel()
Date: Sat, 18 Jun 2016 05:50:30 +0900	[thread overview]
Message-ID: <13136.1466196630@jrobl> (raw)


I am afraid there may exist another violation of "no lookups on the same
name in parallel" rule, but I am not sure.

Roughly d_alloc_parallel() behaves like this.

struct dentry *d_alloc_parallel()
{
	new = d_alloc(parent, name);

	rcu_read_lock();
	hlist_bl_lock(b);
	rcu_read_unlock();
	hlist_bl_for_each_entry(dentry, node, b, d_u.d_in_lookup_hash) {
		if (!matched_dentry_found)
			continue;
		dget(dentry);
		hlist_bl_unlock(b);
		return dentry;
	}
	hlist_bl_add_head_rcu(&new->d_u.d_in_lookup_hash, b);
	hlist_bl_unlock(b);
	return new;
}

When two processes try opening a single existing file and enters
d_alloc_parallel() at the same time, only one process wins and should
succeeds hlist_bl_add_head_rcu(). The other process should find the
dentry in d_u.d_in_lookup_hash and return 'dentry' (instead of
'new'). Am I right?

My question is when will 'new' be added into d_u.d_in_lookup_hash?
It should be between these two lines, I guess.
	rcu_read_unlock();
	hlist_bl_for_each_entry(dentry, node, b, d_u.d_in_lookup_hash) {
But can it surely happen?
If 'new' is not added here because someone else is in rcu_read_lock
region or other reason, then both processes will add the same named but
different dentry?

Is it better to change the lock/unlock-order like this?

	rcu_read_unlock();
	rcu_barrier();
	hlist_bl_lock(b);
	hlist_bl_for_each_entry(dentry, node, b, d_u.d_in_lookup_hash) {


J. R. Okajima

             reply	other threads:[~2016-06-17 20:55 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-17 20:50 J. R. Okajima [this message]
2016-06-17 22:16 ` Q. hlist_bl_add_head_rcu() in d_alloc_parallel() Al Viro
2016-06-17 22:56   ` Al Viro
2016-06-19  5:24   ` J. R. Okajima
2016-06-19 16:55     ` Al Viro
2016-06-20  4:34       ` J. R. Okajima
2016-06-20  5:35         ` Al Viro
2016-06-20 14:51           ` Al Viro
2016-06-20 17:14             ` [git pull] vfs fixes Al Viro
2016-06-23  1:19           ` Q. hlist_bl_add_head_rcu() in d_alloc_parallel() J. R. Okajima
2016-06-23  2:58             ` Al Viro
2016-06-24  5:57               ` Linus Torvalds
2016-06-25 22:54                 ` Al Viro
2016-06-26  1:25                   ` Linus Torvalds
2016-06-29  8:17                     ` Al Viro
2016-06-29  9:22                       ` Hekuang

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=13136.1466196630@jrobl \
    --to=hooanon05g@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=viro@ZenIV.linux.org.uk \
    /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.