All of lore.kernel.org
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@fieldses.org>
To: Jan Kara <jack@suse.cz>
Cc: "Toralf Förster" <toralf.foerster@gmx.de>,
	"Linux NFS mailing list" <linux-nfs@vger.kernel.org>,
	"user-mode-linux-devel@lists.sourceforge.net"
	<user-mode-linux-devel@lists.sourceforge.net>,
	linux-ext4@vger.kernel.org,
	"Linux Kernel" <linux-kernel@vger.kernel.org>,
	"J. Bruce Fields" <bfields@redhat.com>
Subject: Re: Issues with a rather unusual configured NFS server
Date: Tue, 27 Aug 2013 14:06:55 -0400	[thread overview]
Message-ID: <20130827180655.GE14809@fieldses.org> (raw)
In-Reply-To: <20130813215313.GH17781@fieldses.org>

On Tue, Aug 13, 2013 at 05:53:14PM -0400, bfields wrote:
> On Mon, Aug 12, 2013 at 04:36:40PM +0200, Jan Kara wrote:
> > On Sun 11-08-13 11:48:49, Toralf Förster wrote:
> > > so that the server either crashes (if it is a user mode linux image) or at least its reboot functionality got broken
> > > - if the NFS server is hammered with scary NFS calls using a fuzzy tool running at a remote NFS client under a non-privileged user id.
> > > 
> > > It can re reproduced, if
> > > 	- the NFS share is an EXT3 or EXT4 directory
> > > 	- and it is created at file located at tempfs and mounted via loop device
> > > 	- and the NFS server is forced to umount the NFS share
> > > 	- and the server forced to restart the NSF service afterwards
> > > 	- and trinity is used
> > > 
> > > I could find a scenario for an automated bisect. 2 times it brought this commit 
> > > commit 68a3396178e6688ad7367202cdf0af8ed03c8727
> > > Author: J. Bruce Fields <bfields@redhat.com>
> > > Date:   Thu Mar 21 11:21:50 2013 -0400
> > > 
> > >     nfsd4: shut down more of delegation earlier
> 
> Thanks for the report.  I think I see the problem--after this commit
> nfs4_set_delegation() failures result in nfs4_put_delegation being
> called, but nfs4_put_delegation doesn't free the nfs4_file that has
> already been set by alloc_init_deleg().
> 
> Let me think about how to fix that....

Sorry for the slow response--can you check whether this fixes the
problem?

--b.

commit 624a0ee0375940ce4aa36330b0b5a70af6d2b6f5
Author: J. Bruce Fields <bfields@redhat.com>
Date:   Thu Aug 15 16:55:26 2013 -0400

    nfsd4: fix leak of inode reference on delegation failure
    
    This fixes a regression from 68a3396178e6688ad7367202cdf0af8ed03c8727
    "nfsd4: shut down more of delegation earlier".
    
    After that commit, nfs4_set_delegation() failures result in
    nfs4_put_delegation being called, but nfs4_put_delegation doesn't free
    the nfs4_file that has already been set by alloc_init_deleg().
    
    This can result in an oops on later unmounting the exported filesystem.
    
    Note also delaying the fi_had_conflict check we're able to return a
    better error (hence give 4.1 clients a better idea why the delegation
    failed; though note CONFLICT isn't an exact match here, as that's
    supposed to indicate a current conflict, but all we know here is that
    there was one recently).
    
    Reported-by: Toralf Förster <toralf.foerster@gmx.de>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>

diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
index eb9cf81..0874998 100644
--- a/fs/nfsd/nfs4state.c
+++ b/fs/nfsd/nfs4state.c
@@ -368,11 +368,8 @@ static struct nfs4_delegation *
 alloc_init_deleg(struct nfs4_client *clp, struct nfs4_ol_stateid *stp, struct svc_fh *current_fh)
 {
 	struct nfs4_delegation *dp;
-	struct nfs4_file *fp = stp->st_file;
 
 	dprintk("NFSD alloc_init_deleg\n");
-	if (fp->fi_had_conflict)
-		return NULL;
 	if (num_delegations > max_delegations)
 		return NULL;
 	dp = delegstateid(nfs4_alloc_stid(clp, deleg_slab));
@@ -389,8 +386,7 @@ alloc_init_deleg(struct nfs4_client *clp, struct nfs4_ol_stateid *stp, struct sv
 	INIT_LIST_HEAD(&dp->dl_perfile);
 	INIT_LIST_HEAD(&dp->dl_perclnt);
 	INIT_LIST_HEAD(&dp->dl_recall_lru);
-	get_nfs4_file(fp);
-	dp->dl_file = fp;
+	dp->dl_file = NULL;
 	dp->dl_type = NFS4_OPEN_DELEGATE_READ;
 	fh_copy_shallow(&dp->dl_fh, &current_fh->fh_handle);
 	dp->dl_time = 0;
@@ -3044,22 +3040,35 @@ static int nfs4_setlease(struct nfs4_delegation *dp)
 	return 0;
 }
 
-static int nfs4_set_delegation(struct nfs4_delegation *dp)
+static int nfs4_set_delegation(struct nfs4_delegation *dp, struct nfs4_file *fp)
 {
-	struct nfs4_file *fp = dp->dl_file;
+	int status;
 
-	if (!fp->fi_lease)
-		return nfs4_setlease(dp);
+	if (fp->fi_had_conflict)
+		return -EAGAIN;
+	get_nfs4_file(fp);
+	dp->dl_file = fp;
+	if (!fp->fi_lease) {
+		status = nfs4_setlease(dp);
+		if (status)
+			goto out_free;
+		return 0;
+	}
 	spin_lock(&recall_lock);
 	if (fp->fi_had_conflict) {
 		spin_unlock(&recall_lock);
-		return -EAGAIN;
+		status = -EAGAIN;
+		goto out_free;
 	}
 	atomic_inc(&fp->fi_delegees);
 	list_add(&dp->dl_perfile, &fp->fi_delegations);
 	spin_unlock(&recall_lock);
 	list_add(&dp->dl_perclnt, &dp->dl_stid.sc_client->cl_delegations);
 	return 0;
+out_free:
+	put_nfs4_file(fp);
+	dp->dl_file = fp;
+	return status;
 }
 
 static void nfsd4_open_deleg_none_ext(struct nfsd4_open *open, int status)
@@ -3134,7 +3143,7 @@ nfs4_open_delegation(struct net *net, struct svc_fh *fh,
 	dp = alloc_init_deleg(oo->oo_owner.so_client, stp, fh);
 	if (dp == NULL)
 		goto out_no_deleg;
-	status = nfs4_set_delegation(dp);
+	status = nfs4_set_delegation(dp, stp->st_file);
 	if (status)
 		goto out_free;
 
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: "J. Bruce Fields" <bfields@fieldses.org>
To: Jan Kara <jack@suse.cz>
Cc: "Toralf Förster" <toralf.foerster@gmx.de>,
	"Linux NFS mailing list" <linux-nfs@vger.kernel.org>,
	"user-mode-linux-devel@lists.sourceforge.net"
	<user-mode-linux-devel@lists.sourceforge.net>,
	linux-ext4@vger.kernel.org,
	"Linux Kernel" <linux-kernel@vger.kernel.org>,
	"J. Bruce Fields" <bfields@redhat.com>
Subject: Re: Issues with a rather unusual configured NFS server
Date: Tue, 27 Aug 2013 14:06:55 -0400	[thread overview]
Message-ID: <20130827180655.GE14809@fieldses.org> (raw)
In-Reply-To: <20130813215313.GH17781@fieldses.org>

On Tue, Aug 13, 2013 at 05:53:14PM -0400, bfields wrote:
> On Mon, Aug 12, 2013 at 04:36:40PM +0200, Jan Kara wrote:
> > On Sun 11-08-13 11:48:49, Toralf Förster wrote:
> > > so that the server either crashes (if it is a user mode linux image) or at least its reboot functionality got broken
> > > - if the NFS server is hammered with scary NFS calls using a fuzzy tool running at a remote NFS client under a non-privileged user id.
> > > 
> > > It can re reproduced, if
> > > 	- the NFS share is an EXT3 or EXT4 directory
> > > 	- and it is created at file located at tempfs and mounted via loop device
> > > 	- and the NFS server is forced to umount the NFS share
> > > 	- and the server forced to restart the NSF service afterwards
> > > 	- and trinity is used
> > > 
> > > I could find a scenario for an automated bisect. 2 times it brought this commit 
> > > commit 68a3396178e6688ad7367202cdf0af8ed03c8727
> > > Author: J. Bruce Fields <bfields@redhat.com>
> > > Date:   Thu Mar 21 11:21:50 2013 -0400
> > > 
> > >     nfsd4: shut down more of delegation earlier
> 
> Thanks for the report.  I think I see the problem--after this commit
> nfs4_set_delegation() failures result in nfs4_put_delegation being
> called, but nfs4_put_delegation doesn't free the nfs4_file that has
> already been set by alloc_init_deleg().
> 
> Let me think about how to fix that....

Sorry for the slow response--can you check whether this fixes the
problem?

--b.

commit 624a0ee0375940ce4aa36330b0b5a70af6d2b6f5
Author: J. Bruce Fields <bfields@redhat.com>
Date:   Thu Aug 15 16:55:26 2013 -0400

    nfsd4: fix leak of inode reference on delegation failure
    
    This fixes a regression from 68a3396178e6688ad7367202cdf0af8ed03c8727
    "nfsd4: shut down more of delegation earlier".
    
    After that commit, nfs4_set_delegation() failures result in
    nfs4_put_delegation being called, but nfs4_put_delegation doesn't free
    the nfs4_file that has already been set by alloc_init_deleg().
    
    This can result in an oops on later unmounting the exported filesystem.
    
    Note also delaying the fi_had_conflict check we're able to return a
    better error (hence give 4.1 clients a better idea why the delegation
    failed; though note CONFLICT isn't an exact match here, as that's
    supposed to indicate a current conflict, but all we know here is that
    there was one recently).
    
    Reported-by: Toralf Förster <toralf.foerster@gmx.de>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>

diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
index eb9cf81..0874998 100644
--- a/fs/nfsd/nfs4state.c
+++ b/fs/nfsd/nfs4state.c
@@ -368,11 +368,8 @@ static struct nfs4_delegation *
 alloc_init_deleg(struct nfs4_client *clp, struct nfs4_ol_stateid *stp, struct svc_fh *current_fh)
 {
 	struct nfs4_delegation *dp;
-	struct nfs4_file *fp = stp->st_file;
 
 	dprintk("NFSD alloc_init_deleg\n");
-	if (fp->fi_had_conflict)
-		return NULL;
 	if (num_delegations > max_delegations)
 		return NULL;
 	dp = delegstateid(nfs4_alloc_stid(clp, deleg_slab));
@@ -389,8 +386,7 @@ alloc_init_deleg(struct nfs4_client *clp, struct nfs4_ol_stateid *stp, struct sv
 	INIT_LIST_HEAD(&dp->dl_perfile);
 	INIT_LIST_HEAD(&dp->dl_perclnt);
 	INIT_LIST_HEAD(&dp->dl_recall_lru);
-	get_nfs4_file(fp);
-	dp->dl_file = fp;
+	dp->dl_file = NULL;
 	dp->dl_type = NFS4_OPEN_DELEGATE_READ;
 	fh_copy_shallow(&dp->dl_fh, &current_fh->fh_handle);
 	dp->dl_time = 0;
@@ -3044,22 +3040,35 @@ static int nfs4_setlease(struct nfs4_delegation *dp)
 	return 0;
 }
 
-static int nfs4_set_delegation(struct nfs4_delegation *dp)
+static int nfs4_set_delegation(struct nfs4_delegation *dp, struct nfs4_file *fp)
 {
-	struct nfs4_file *fp = dp->dl_file;
+	int status;
 
-	if (!fp->fi_lease)
-		return nfs4_setlease(dp);
+	if (fp->fi_had_conflict)
+		return -EAGAIN;
+	get_nfs4_file(fp);
+	dp->dl_file = fp;
+	if (!fp->fi_lease) {
+		status = nfs4_setlease(dp);
+		if (status)
+			goto out_free;
+		return 0;
+	}
 	spin_lock(&recall_lock);
 	if (fp->fi_had_conflict) {
 		spin_unlock(&recall_lock);
-		return -EAGAIN;
+		status = -EAGAIN;
+		goto out_free;
 	}
 	atomic_inc(&fp->fi_delegees);
 	list_add(&dp->dl_perfile, &fp->fi_delegations);
 	spin_unlock(&recall_lock);
 	list_add(&dp->dl_perclnt, &dp->dl_stid.sc_client->cl_delegations);
 	return 0;
+out_free:
+	put_nfs4_file(fp);
+	dp->dl_file = fp;
+	return status;
 }
 
 static void nfsd4_open_deleg_none_ext(struct nfsd4_open *open, int status)
@@ -3134,7 +3143,7 @@ nfs4_open_delegation(struct net *net, struct svc_fh *fh,
 	dp = alloc_init_deleg(oo->oo_owner.so_client, stp, fh);
 	if (dp == NULL)
 		goto out_no_deleg;
-	status = nfs4_set_delegation(dp);
+	status = nfs4_set_delegation(dp, stp->st_file);
 	if (status)
 		goto out_free;
 

WARNING: multiple messages have this Message-ID (diff)
From: "J. Bruce Fields" <bfields@fieldses.org>
To: Jan Kara <jack@suse.cz>
Cc: "Toralf Förster" <toralf.foerster@gmx.de>,
	"Linux NFS mailing list" <linux-nfs@vger.kernel.org>,
	"user-mode-linux-devel@lists.sourceforge.net"
	<user-mode-linux-devel@lists.sourceforge.net>,
	linux-ext4@vger.kernel.org,
	"Linux Kernel" <linux-kernel@vger.kernel.org>,
	"J. Bruce Fields" <bfields@redhat.com>
Subject: Re: Issues with a rather unusual configured NFS server
Date: Tue, 27 Aug 2013 14:06:55 -0400	[thread overview]
Message-ID: <20130827180655.GE14809@fieldses.org> (raw)
In-Reply-To: <20130813215313.GH17781@fieldses.org>

On Tue, Aug 13, 2013 at 05:53:14PM -0400, bfields wrote:
> On Mon, Aug 12, 2013 at 04:36:40PM +0200, Jan Kara wrote:
> > On Sun 11-08-13 11:48:49, Toralf Förster wrote:
> > > so that the server either crashes (if it is a user mode linux image) or at least its reboot functionality got broken
> > > - if the NFS server is hammered with scary NFS calls using a fuzzy tool running at a remote NFS client under a non-privileged user id.
> > > 
> > > It can re reproduced, if
> > > 	- the NFS share is an EXT3 or EXT4 directory
> > > 	- and it is created at file located at tempfs and mounted via loop device
> > > 	- and the NFS server is forced to umount the NFS share
> > > 	- and the server forced to restart the NSF service afterwards
> > > 	- and trinity is used
> > > 
> > > I could find a scenario for an automated bisect. 2 times it brought this commit 
> > > commit 68a3396178e6688ad7367202cdf0af8ed03c8727
> > > Author: J. Bruce Fields <bfields@redhat.com>
> > > Date:   Thu Mar 21 11:21:50 2013 -0400
> > > 
> > >     nfsd4: shut down more of delegation earlier
> 
> Thanks for the report.  I think I see the problem--after this commit
> nfs4_set_delegation() failures result in nfs4_put_delegation being
> called, but nfs4_put_delegation doesn't free the nfs4_file that has
> already been set by alloc_init_deleg().
> 
> Let me think about how to fix that....

Sorry for the slow response--can you check whether this fixes the
problem?

--b.

commit 624a0ee0375940ce4aa36330b0b5a70af6d2b6f5
Author: J. Bruce Fields <bfields@redhat.com>
Date:   Thu Aug 15 16:55:26 2013 -0400

    nfsd4: fix leak of inode reference on delegation failure
    
    This fixes a regression from 68a3396178e6688ad7367202cdf0af8ed03c8727
    "nfsd4: shut down more of delegation earlier".
    
    After that commit, nfs4_set_delegation() failures result in
    nfs4_put_delegation being called, but nfs4_put_delegation doesn't free
    the nfs4_file that has already been set by alloc_init_deleg().
    
    This can result in an oops on later unmounting the exported filesystem.
    
    Note also delaying the fi_had_conflict check we're able to return a
    better error (hence give 4.1 clients a better idea why the delegation
    failed; though note CONFLICT isn't an exact match here, as that's
    supposed to indicate a current conflict, but all we know here is that
    there was one recently).
    
    Reported-by: Toralf Förster <toralf.foerster@gmx.de>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>

diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
index eb9cf81..0874998 100644
--- a/fs/nfsd/nfs4state.c
+++ b/fs/nfsd/nfs4state.c
@@ -368,11 +368,8 @@ static struct nfs4_delegation *
 alloc_init_deleg(struct nfs4_client *clp, struct nfs4_ol_stateid *stp, struct svc_fh *current_fh)
 {
 	struct nfs4_delegation *dp;
-	struct nfs4_file *fp = stp->st_file;
 
 	dprintk("NFSD alloc_init_deleg\n");
-	if (fp->fi_had_conflict)
-		return NULL;
 	if (num_delegations > max_delegations)
 		return NULL;
 	dp = delegstateid(nfs4_alloc_stid(clp, deleg_slab));
@@ -389,8 +386,7 @@ alloc_init_deleg(struct nfs4_client *clp, struct nfs4_ol_stateid *stp, struct sv
 	INIT_LIST_HEAD(&dp->dl_perfile);
 	INIT_LIST_HEAD(&dp->dl_perclnt);
 	INIT_LIST_HEAD(&dp->dl_recall_lru);
-	get_nfs4_file(fp);
-	dp->dl_file = fp;
+	dp->dl_file = NULL;
 	dp->dl_type = NFS4_OPEN_DELEGATE_READ;
 	fh_copy_shallow(&dp->dl_fh, &current_fh->fh_handle);
 	dp->dl_time = 0;
@@ -3044,22 +3040,35 @@ static int nfs4_setlease(struct nfs4_delegation *dp)
 	return 0;
 }
 
-static int nfs4_set_delegation(struct nfs4_delegation *dp)
+static int nfs4_set_delegation(struct nfs4_delegation *dp, struct nfs4_file *fp)
 {
-	struct nfs4_file *fp = dp->dl_file;
+	int status;
 
-	if (!fp->fi_lease)
-		return nfs4_setlease(dp);
+	if (fp->fi_had_conflict)
+		return -EAGAIN;
+	get_nfs4_file(fp);
+	dp->dl_file = fp;
+	if (!fp->fi_lease) {
+		status = nfs4_setlease(dp);
+		if (status)
+			goto out_free;
+		return 0;
+	}
 	spin_lock(&recall_lock);
 	if (fp->fi_had_conflict) {
 		spin_unlock(&recall_lock);
-		return -EAGAIN;
+		status = -EAGAIN;
+		goto out_free;
 	}
 	atomic_inc(&fp->fi_delegees);
 	list_add(&dp->dl_perfile, &fp->fi_delegations);
 	spin_unlock(&recall_lock);
 	list_add(&dp->dl_perclnt, &dp->dl_stid.sc_client->cl_delegations);
 	return 0;
+out_free:
+	put_nfs4_file(fp);
+	dp->dl_file = fp;
+	return status;
 }
 
 static void nfsd4_open_deleg_none_ext(struct nfsd4_open *open, int status)
@@ -3134,7 +3143,7 @@ nfs4_open_delegation(struct net *net, struct svc_fh *fh,
 	dp = alloc_init_deleg(oo->oo_owner.so_client, stp, fh);
 	if (dp == NULL)
 		goto out_no_deleg;
-	status = nfs4_set_delegation(dp);
+	status = nfs4_set_delegation(dp, stp->st_file);
 	if (status)
 		goto out_free;
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


  parent reply	other threads:[~2013-08-27 18:07 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-11  9:48 Issues with a rather unusual configured NFS server Toralf Förster
2013-08-11  9:48 ` [uml-devel] " Toralf Förster
2013-08-11  9:48 ` Toralf Förster
     [not found] ` <52075E01.7030506-Mmb7MZpHnFY@public.gmane.org>
2013-08-12 14:36   ` Jan Kara
2013-08-12 14:36     ` Jan Kara
2013-08-12 14:36     ` Jan Kara
2013-08-13 21:53     ` J. Bruce Fields
2013-08-13 21:53       ` J. Bruce Fields
2013-08-14 16:44       ` Toralf Förster
2013-08-14 16:44         ` Toralf Förster
2013-08-27 18:06       ` J. Bruce Fields [this message]
2013-08-27 18:06         ` J. Bruce Fields
2013-08-27 18:06         ` J. Bruce Fields
2013-08-28 17:21         ` Toralf Förster
2013-08-28 17:21           ` Toralf Förster
2013-08-29  9:57           ` [uml-devel] " richard -rw- weinberger
2013-08-29  9:57             ` richard -rw- weinberger
2013-08-29 13:30             ` J. Bruce Fields
2013-08-29 13:30               ` J. Bruce Fields
     [not found]               ` <20130829133010.GA14773-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
2013-08-30 14:10                 ` Toralf Förster
2013-08-30 14:10                   ` Toralf Förster
2013-08-30 14:10                   ` Toralf Förster
2013-08-30 14:25                   ` J. Bruce Fields
2013-08-30 14:25                     ` J. Bruce Fields
2013-08-30 14:36                   ` Richard Weinberger
2013-08-30 14:36                     ` Richard Weinberger
2013-09-01 16:09                     ` Toralf Förster
2013-09-01 21:15                       ` Richard Weinberger
2013-09-02 16:53                         ` Toralf Förster
2013-09-02 16:56                           ` Richard Weinberger
     [not found]             ` <CAFLxGvyK5+nB9TgW1uPho9KGwQrWQHx=wEpj+o-mZcN92bWAOg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-08-30 18:27               ` Michael Richardson
2013-08-30 18:27                 ` Michael Richardson
2013-09-07 20:44           ` Toralf Förster
2013-09-07 20:44             ` Toralf Förster
2013-09-07 20:44             ` Toralf Förster
     [not found]             ` <522B9010.8070902-Mmb7MZpHnFY@public.gmane.org>
2013-09-07 20:51               ` [uml-devel] " richard -rw- weinberger
2013-09-07 20:51                 ` richard -rw- weinberger
2013-09-07 20:51                 ` richard -rw- weinberger
2013-09-10 14:09               ` J. Bruce Fields
2013-09-10 14:09                 ` J. Bruce Fields
2013-09-10 14:09                 ` J. Bruce Fields
     [not found]                 ` <20130910140937.GD16011-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
2013-09-10 15:51                   ` Toralf Förster
2013-09-10 15:51                     ` Toralf Förster
2013-09-10 15:51                     ` Toralf Förster
2013-09-22 16:58                   ` Toralf Förster
2013-09-22 16:58                     ` Toralf Förster
2013-09-22 16:58                     ` Toralf Förster
2013-09-23 17:41                     ` J. Bruce Fields
2013-09-23 17:41                       ` J. Bruce Fields
2013-09-23 17:41                       ` J. Bruce Fields
     [not found]                       ` <20130923174129.GA19720-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
2013-10-02 20:29                         ` Toralf Förster
2013-10-02 20:29                           ` Toralf Förster
2013-10-02 20:29                           ` Toralf Förster
  -- strict thread matches above, loose matches on Subject: below --
2013-09-27 14:53 Marc Meledandri
2013-09-28 15:37 Marc Meledandri
2013-10-01 14:34 ` J. Bruce Fields
2013-10-02  1:24   ` Marc Meledandri
2013-10-02 14:04     ` J. Bruce Fields

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=20130827180655.GE14809@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=bfields@redhat.com \
    --cc=jack@suse.cz \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=toralf.foerster@gmx.de \
    --cc=user-mode-linux-devel@lists.sourceforge.net \
    /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.