linux-kernel - Re: [patch 16/52] fs: dcache RCU for multi-step operaitons

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1277400397.15264.34.camel@work-vm>
Date:	Thu, 24 Jun 2010 10:26:37 -0700
From:	john stultz <johnstul@...ibm.com>
To:	npiggin@...e.de
Cc:	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	Frank Mayhar <fmayhar@...gle.com>,
	Peter Zijlstra <peterz@...radead.org>
Subject: Re: [patch 16/52] fs: dcache RCU for multi-step operaitons

On Thu, 2010-06-24 at 13:02 +1000, npiggin@...e.de wrote:
> plain text document attachment (fs-dcache_lock-multi-step.patch)
> The remaining usages for dcache_lock is to allow atomic, multi-step read-side
> operations over the directory tree by excluding modifications to the tree.
> Also, to walk in the leaf->root direction in the tree where we don't have
> a natural d_lock ordering.
> 
> This could be accomplished by taking every d_lock, but this would mean a
> huge number of locks and actually gets very tricky.
> 
> Solve this instead by using the rename seqlock for multi-step read-side
> operations. Insert operations are not serialised. Delete operations are
> tricky when walking up the directory our parent might have been deleted
> when dropping locks so also need to check and retry for that.
> 
> XXX: hmm, we could of course just take the rename lock if there is any worry
> about livelock. Most of these are slow paths.

I'll try to point out exactly the spot I think we were hitting in the
-rt tree (once the dcache_lock is removed).


> @@ -1030,9 +1056,15 @@ EXPORT_SYMBOL(have_submounts);
>   */
>  static int select_parent(struct dentry * parent)
>  {
> -	struct dentry *this_parent = parent;
> +	struct dentry *this_parent;
>  	struct list_head *next;
> -	int found = 0;
> +	unsigned seq;
> +	int found;
> +
> +rename_retry:
> +	found = 0;
> +	this_parent = parent;
> +	seq = read_seqbegin(&rename_lock);
> 
>  	spin_lock(&dcache_lock);
>  	spin_lock(&this_parent->d_lock);
> @@ -1043,7 +1075,6 @@ resume:
>  		struct list_head *tmp = next;
>  		struct dentry *dentry = list_entry(tmp, struct dentry, d_u.d_child);
>  		next = tmp->next;
> -		BUG_ON(this_parent == dentry);
> 
>  		spin_lock_nested(&dentry->d_lock, DENTRY_D_LOCK_NESTED);
>  		dentry_lru_del_init(dentry);
> @@ -1084,17 +1115,33 @@ resume:
>  	 */
>  	if (this_parent != parent) {
>  		struct dentry *tmp;
> -		next = this_parent->d_u.d_child.next;
> +		struct dentry *child;
> +
>  		tmp = this_parent->d_parent;
> +		rcu_read_lock();
>  		spin_unlock(&this_parent->d_lock);
> -		BUG_ON(tmp == this_parent);
> +		child = this_parent;
>  		this_parent = tmp;

Ok. So right here, we get preempted, or dput() is called by another cpu
on the child dentry, or the child->d_u.d_child.next dentry and its
d_kill'ed.

>  		spin_lock(&this_parent->d_lock);
> +		/* might go back up the wrong parent if we have had a rename
> +		 * or deletion */
> +		if (this_parent != child->d_parent ||
> +				// d_unlinked(this_parent) || XXX
> +				read_seqretry(&rename_lock, seq)) {
> +			spin_unlock(&this_parent->d_lock);
> +			spin_unlock(&dcache_lock);
> +			rcu_read_unlock();
> +			goto rename_retry;
> +		}
> +		rcu_read_unlock();
> +		next = child->d_u.d_child.next;

Then at this point, next may point to junk. 

>  		goto resume;
>  	}
>  out:
>  	spin_unlock(&this_parent->d_lock);
>  	spin_unlock(&dcache_lock);
> +	if (read_seqretry(&rename_lock, seq))
> +		goto rename_retry;
>  	return found;
>  }


thanks
-john


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/