From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jordi Pujol <jordipujolp@gmail.com>
Subject: Re: overlayfs patches for ovl_copy_up & ovl_rename
Date: Wed, 18 May 2011 09:44:34 +0200
Message-ID: <201105180944.35027.jordipujolp@gmail.com>
References: <201105041659.38427.jordipujolp@gmail.com> <201105171918.03433.jordipujolp@gmail.com> <87vcx9cib2.fsf@tucsk.pomaz.szeredi.hu>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: QUOTED-PRINTABLE
Cc: linux-fsdevel@vger.kernel.org
To: Miklos Szeredi <miklos@szeredi.hu>
Return-path: <linux-fsdevel-owner@vger.kernel.org>
Received: from mail-ew0-f46.google.com ([209.85.215.46]:33211 "EHLO
	mail-ew0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1754806Ab1ERHoj convert rfc822-to-8bit (ORCPT
	<rfc822;linux-fsdevel@vger.kernel.org>);
	Wed, 18 May 2011 03:44:39 -0400
Received: by ewy4 with SMTP id 4so357296ewy.19
        for <linux-fsdevel@vger.kernel.org>; Wed, 18 May 2011 00:44:38 -0700 (PDT)
In-Reply-To: <87vcx9cib2.fsf@tucsk.pomaz.szeredi.hu>
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

A Dimarts 17 Maig 2011 20:07:13, v=C3=A0reu escriure:
> Jordi, what about the original bug you reported:
> >>>- a few days ago we talked about an error when repetitive sed
> >>>instructions were executed, also it happens in other processes, li=
ke
> >>>mantaining list of installed files for actual packages,
> >>>that is solved in ovl_rename issuing a dget for the old-dentry and
> >>>parent dentries. (This code is inspired on rename.c from unionfs)
>=20
> Is this still happening?  Does the debug patch make any difference?

my patch adds some dget/dput operations that minimize the problem, it o=
ccurs=20
less times, but it happens.
I suppose that those extra operations add an execution delay before pro=
cessing=20
the main routine;
a deduction is that locking dentries is required to synchronize a renam=
e to=20
not be executed until another rename operation has finished.

As an example of code that looks like that of unionfs, (this is not tes=
ted)=20

struct ovl_entry {
	struct dentry *__upperdentry;
	struct dentry *lowerdentry;
+	struct mutex d_mutex;
	union {
		struct {
			u64 version;
			bool opaque;
		};
		struct rcu_head rcu;
	};
};

static struct ovl_entry *ovl_alloc_entry(void)
{
	struct ovl_entry *oe;

	oe =3D kzalloc(sizeof(struct ovl_entry), GFP_KERNEL);
	mutex_init(&oe->d_mutex);

	return oe;
}

void ovl_lock_dentry(struct dentry *dentry)
{
	struct ovl_entry *oe =3D dentry->d_fsdata;

	mutex_lock(&oe->d_mutex);
}

void ovl_unlock_dentry(struct dentry *dentry)
{
	struct ovl_entry *oe =3D dentry->d_fsdata;

	mutex_unlock(&oe->d_mutex);
}

static int ovl_rename(struct inode *olddir, struct dentry *old,
			struct inode *newdir, struct dentry *new)
{
	int err;
=2E..........
+	ovl_lock_dentry(old);

	err =3D ovl_copy_up(old);
=2E..........
+	ovl_unlock_dentry(old);
	return err;
}

consider this idea,

Thanks,

Jordi Pujol

Live never ending Tale
GNU/Linux Live forever!
http://livenet.selfip.com
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel=
" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html