The patch titled
9p: fix fid behavior on failed remove
has been removed from the -mm tree. Its filename is
9p-fix-fid-behavior-on-failed-remove.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
Subject: 9p: fix fid behavior on failed remove
From: Eric Van Hensbergen <ericvh@xxxxxxxxxxxxxxx>
Based on a bug report from Russ Ross <russruss@xxxxxxxxx>
According to the spec:
"The remove request asks the file server both to remove the file
represented by fid and to clunk the fid, even if the remove fails."
but the Linux client seems to expect the fid to be valid after a failed
remove attempt. Specifically, I'm getting this behavior when attempting to
remove a non-empty directory.
Signed-off-by: Eric Van Hensbergen <ericvh@xxxxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxx>
---
fs/9p/vfs_inode.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff -puN fs/9p/vfs_inode.c~9p-fix-fid-behavior-on-failed-remove fs/9p/vfs_inode.c
--- a/fs/9p/vfs_inode.c~9p-fix-fid-behavior-on-failed-remove
+++ a/fs/9p/vfs_inode.c
@@ -434,11 +434,11 @@ static int v9fs_remove(struct inode *dir
result = v9fs_t_remove(v9ses, fid, &fcall);
if (result < 0) {
PRINT_FCALL_ERROR("remove fails", fcall);
- } else {
- v9fs_put_idpool(fid, &v9ses->fidpool);
- v9fs_fid_destroy(v9fid);
}
+ v9fs_put_idpool(fid, &v9ses->fidpool);
+ v9fs_fid_destroy(v9fid);
+
kfree(fcall);
return result;
}
_
Patches currently in -mm which might be from ericvh@xxxxxxxxxxxxxxx are
origin.patch
-
To unsubscribe from this list: send the line "unsubscribe mm-commits" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
