If an NFS client does
mkdir("dir");
fd = open("dir/file");
unlink("dir/file");
close(fd);
rmdir("dir");
then the asynchronous nature of the sillyrename operation means that
we can end up getting EBUSY for the rmdir() in the above test. Fix
that by ensuring that we wait for any in-progress sillyrenames
before sending the rmdir() to the server.
Signed-off-by: Trond Myklebust <[email protected]>
---
fs/nfs/dir.c | 19 +++++++++++++------
fs/nfs/unlink.c | 7 +++++++
include/linux/nfs_fs.h | 1 +
3 files changed, 21 insertions(+), 6 deletions(-)
diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c
index d8149e9..187caa4 100644
--- a/fs/nfs/dir.c
+++ b/fs/nfs/dir.c
@@ -1694,12 +1694,19 @@ int nfs_rmdir(struct inode *dir, struct dentry *dentry)
dir->i_sb->s_id, dir->i_ino, dentry->d_name.name);
trace_nfs_rmdir_enter(dir, dentry);
- error = NFS_PROTO(dir)->rmdir(dir, &dentry->d_name);
- /* Ensure the VFS deletes this inode */
- if (error == 0 && dentry->d_inode != NULL)
- clear_nlink(dentry->d_inode);
- else if (error == -ENOENT)
- nfs_dentry_handle_enoent(dentry);
+ if (dentry->d_inode) {
+ nfs_wait_on_sillyrename(dentry);
+ error = NFS_PROTO(dir)->rmdir(dir, &dentry->d_name);
+ /* Ensure the VFS deletes this inode */
+ switch (error) {
+ case 0:
+ clear_nlink(dentry->d_inode);
+ break;
+ case -ENOENT:
+ nfs_dentry_handle_enoent(dentry);
+ }
+ } else
+ error = NFS_PROTO(dir)->rmdir(dir, &dentry->d_name);
trace_nfs_rmdir_exit(dir, dentry, error);
return error;
diff --git a/fs/nfs/unlink.c b/fs/nfs/unlink.c
index 2c1485d..0c6dfe0 100644
--- a/fs/nfs/unlink.c
+++ b/fs/nfs/unlink.c
@@ -207,6 +207,13 @@ out_free:
return ret;
}
+void nfs_wait_on_sillyrename(struct dentry *dentry)
+{
+ struct nfs_inode *nfsi = NFS_I(dentry->d_inode);
+
+ wait_event(nfsi->waitqueue, atomic_read(&nfsi->silly_count) == 1);
+}
+
void nfs_block_sillyrename(struct dentry *dentry)
{
struct nfs_inode *nfsi = NFS_I(dentry->d_inode);
diff --git a/include/linux/nfs_fs.h b/include/linux/nfs_fs.h
index 7125cef..3ea4cde 100644
--- a/include/linux/nfs_fs.h
+++ b/include/linux/nfs_fs.h
@@ -524,6 +524,7 @@ static inline void nfs4_label_free(void *label) {}
* linux/fs/nfs/unlink.c
*/
extern void nfs_complete_unlink(struct dentry *dentry, struct inode *);
+extern void nfs_wait_on_sillyrename(struct dentry *dentry);
extern void nfs_block_sillyrename(struct dentry *dentry);
extern void nfs_unblock_sillyrename(struct dentry *dentry);
extern int nfs_sillyrename(struct inode *dir, struct dentry *dentry);
--
1.8.3.1
On Sep03 18:50, Myklebust, Trond wrote:
> Thanks again for testing! Does the following fixup on top of the 'v2'
> patch also help?
> --- a/fs/nfs/unlink.c
> +++ b/fs/nfs/unlink.c
> @@ -211,7 +211,7 @@ void nfs_wait_on_sillyrename(struct dentry *dentry)
> {
> struct nfs_inode *nfsi = NFS_I(dentry->d_inode);
>
> - wait_event(nfsi->waitqueue, atomic_read(&nfsi->silly_count) == 1);
> + wait_event(nfsi->waitqueue, atomic_read(&nfsi->silly_count) <= 1);
> }
>
> void nfs_block_sillyrename(struct dentry *dentry)
hmmm I just realized your v2 version had `== 1`; in fact I tested your v1
with `== 0`. Let me some time to retest the v2.
Thanks,
--
William
On Sep03 20:47, Myklebust, Trond wrote:
> On Tue, 2013-09-03 at 22:44 +0200, William Dauchy wrote:
> > On Sep03 18:50, Myklebust, Trond wrote:
> > > Thanks again for testing! Does the following fixup on top of the 'v2'
> > > patch also help?
> > > --- a/fs/nfs/unlink.c
> > > +++ b/fs/nfs/unlink.c
> > > @@ -211,7 +211,7 @@ void nfs_wait_on_sillyrename(struct dentry *dentry)
> > > {
> > > struct nfs_inode *nfsi = NFS_I(dentry->d_inode);
> > >
> > > - wait_event(nfsi->waitqueue, atomic_read(&nfsi->silly_count) == 1);
> > > + wait_event(nfsi->waitqueue, atomic_read(&nfsi->silly_count) <= 1);
> > > }
> > >
> > > void nfs_block_sillyrename(struct dentry *dentry)
> >
> > hmmm I just realized your v2 version had `== 1`; in fact I tested your v1
> > with `== 0`. Let me some time to retest the v2.
After some more testing the v2 was ok with `== 1`; I tested the v1 too
fast without seeing a v2 has been resent. I guess you can revert `<= 1`
Tested-by: William Dauchy <[email protected]>
Sorry for the noise,
--
William
On Mon, Sep 2, 2013 at 8:17 PM, Trond Myklebust
<[email protected]> wrote:
> If an NFS client does
>
> mkdir("dir");
> fd = open("dir/file");
> unlink("dir/file");
> close(fd);
> rmdir("dir");
>
> then the asynchronous nature of the sillyrename operation means that
> we can end up getting EBUSY for the rmdir() in the above test. Fix
> that by ensuring that we wait for any in-progress sillyrenames
> before sending the rmdir() to the server.
I tested the patch on top of a 3.10.x
When doing heavy operations like rm -rf dir/ with lots of data, the
process gets stuck for ever.
removing the patch fixes the issue.
--
William
On Tue, 2013-09-03 at 11:33 +0200, William Dauchy wrote:
> On Mon, Sep 2, 2013 at 8:17 PM, Trond Myklebust
> <[email protected]> wrote:
> > If an NFS client does
> >
> > mkdir("dir");
> > fd = open("dir/file");
> > unlink("dir/file");
> > close(fd);
> > rmdir("dir");
> >
> > then the asynchronous nature of the sillyrename operation means that
> > we can end up getting EBUSY for the rmdir() in the above test. Fix
> > that by ensuring that we wait for any in-progress sillyrenames
> > before sending the rmdir() to the server.
>
> I tested the patch on top of a 3.10.x
> When doing heavy operations like rm -rf dir/ with lots of data, the
> process gets stuck for ever.
> removing the patch fixes the issue.
>
Hi William,
Thanks again for testing! Does the following fixup on top of the 'v2'
patch also help?
Cheers
Trond
--
Trond Myklebust
Linux NFS client maintainer
NetApp
[email protected]
http://www.netapp.com
T24gVHVlLCAyMDEzLTA5LTAzIGF0IDIyOjQ0ICswMjAwLCBXaWxsaWFtIERhdWNoeSB3cm90ZToN
Cj4gT24gU2VwMDMgMTg6NTAsIE15a2xlYnVzdCwgVHJvbmQgd3JvdGU6DQo+ID4gVGhhbmtzIGFn
YWluIGZvciB0ZXN0aW5nISBEb2VzIHRoZSBmb2xsb3dpbmcgZml4dXAgb24gdG9wIG9mIHRoZSAn
djInDQo+ID4gcGF0Y2ggYWxzbyBoZWxwPw0KPiA+IC0tLSBhL2ZzL25mcy91bmxpbmsuYw0KPiA+
ICsrKyBiL2ZzL25mcy91bmxpbmsuYw0KPiA+IEBAIC0yMTEsNyArMjExLDcgQEAgdm9pZCBuZnNf
d2FpdF9vbl9zaWxseXJlbmFtZShzdHJ1Y3QgZGVudHJ5ICpkZW50cnkpDQo+ID4gIHsNCj4gPiAg
CXN0cnVjdCBuZnNfaW5vZGUgKm5mc2kgPSBORlNfSShkZW50cnktPmRfaW5vZGUpOw0KPiA+ICAN
Cj4gPiAtCXdhaXRfZXZlbnQobmZzaS0+d2FpdHF1ZXVlLCBhdG9taWNfcmVhZCgmbmZzaS0+c2ls
bHlfY291bnQpID09IDEpOw0KPiA+ICsJd2FpdF9ldmVudChuZnNpLT53YWl0cXVldWUsIGF0b21p
Y19yZWFkKCZuZnNpLT5zaWxseV9jb3VudCkgPD0gMSk7DQo+ID4gIH0NCj4gPiAgDQo+ID4gIHZv
aWQgbmZzX2Jsb2NrX3NpbGx5cmVuYW1lKHN0cnVjdCBkZW50cnkgKmRlbnRyeSkNCj4gDQo+IGht
bW0gSSBqdXN0IHJlYWxpemVkIHlvdXIgdjIgdmVyc2lvbiBoYWQgYD09IDFgOyBpbiBmYWN0IEkg
dGVzdGVkIHlvdXIgdjENCj4gd2l0aCBgPT0gMGAuIExldCBtZSBzb21lIHRpbWUgdG8gcmV0ZXN0
IHRoZSB2Mi4NCg0KT0suIFRoYW5rcyBhZ2FpbiENCg0KLS0gDQpUcm9uZCBNeWtsZWJ1c3QNCkxp
bnV4IE5GUyBjbGllbnQgbWFpbnRhaW5lcg0KDQpOZXRBcHANClRyb25kLk15a2xlYnVzdEBuZXRh
cHAuY29tDQp3d3cubmV0YXBwLmNvbQ0K