* Re: Re: [autofs] VFS: Busy inodes after unmount on 2 way SMP [not found] ` <20030917210023.GA15099@suse.de> @ 2003-09-18 5:52 ` Trond Myklebust 2003-09-18 8:26 ` Olaf Kirch 2003-09-25 23:17 ` Matt C 0 siblings, 2 replies; 12+ messages in thread From: Trond Myklebust @ 2003-09-18 5:52 UTC (permalink / raw) To: Olaf Hering; +Cc: H. Peter Anvin, Arun Sharma, autofs, nfs, Ian Kent >>>>> " " == Olaf Hering <olh@suse.de> writes: > On Wed, Sep 17, H. Peter Anvin wrote: >> Okay... let me ask this so I get it straight... >> >> Has anyone seen this (busy inodes after stopping the >> automounter) using autofs v3 kernel module and daemon? > I'm not sure, but everyone who has seen this should fiddle this > patch into the kernel and see how it goes. The whole thing > started very recently (post 2.4.21) for us. > This patch is untested, any feedback appreciated. ...and is indeed wrong... It does the exact opposite of what sillydelete should do. Instead of causing the last application that closes the file to perform the sillydelete, you are asking the *first* application that closes it to do so. Sillydelete *has* to be tied to dentries. Not files, and not inodes. It is purely a namespace operation... So exactly what are you trying to do, and why? Cheers, Trond ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ NFS maillist - NFS@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Re: [autofs] VFS: Busy inodes after unmount on 2 way SMP 2003-09-18 5:52 ` Re: [autofs] VFS: Busy inodes after unmount on 2 way SMP Trond Myklebust @ 2003-09-18 8:26 ` Olaf Kirch 2003-09-25 23:17 ` Matt C 1 sibling, 0 replies; 12+ messages in thread From: Olaf Kirch @ 2003-09-18 8:26 UTC (permalink / raw) To: Trond Myklebust Cc: Olaf Hering, H. Peter Anvin, Arun Sharma, autofs, nfs, Ian Kent On Thu, Sep 18, 2003 at 01:52:05AM -0400, Trond Myklebust wrote: > ...and is indeed wrong... It does the exact opposite of what > sillydelete should do. Instead of causing the last application that > closes the file to perform the sillydelete, you are asking the *first* > application that closes it to do so. I know. I was not claiming it's perfectly right, what I'm interested in whether it cures the oopses we're seeing. If that were true, one could still look for The Right Solution... > Sillydelete *has* to be tied to dentries. Not files, and not > inodes. It is purely a namespace operation... > > So exactly what are you trying to do, and why? We have seen several reports of autofs+nfs leading to oopses, preceded by "Busy inodes on umount, self-destruct in 5 seconds". It's somewhat hard to reproduce, so I'm currently trying to come up with possible patches by looking at the source. You cannot umount if the vfsmount mnt_count is != 2. So either something hosed the mnt_count completely (by doing too many mntput() calls for instance), or something holds dentry references without bumping mnt_count along with it. Do you agree? The only place in the nfs client code that actually does a dget is the sillydelete stuff in unlink.c. So my idea in generating this patch was that the nfs_complete_unlink was happening too late, when the file is already closed and the vfsmount reference is gone. It's a long shot admittedly... Have a nice day, Olaf -- Olaf Kirch | Anyone who has had to work with X.509 has probably okir@suse.de | experienced what can best be described as ---------------+ ISO water torture. -- Peter Gutmann ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ NFS maillist - NFS@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Re: [autofs] VFS: Busy inodes after unmount on 2 way SMP 2003-09-18 5:52 ` Re: [autofs] VFS: Busy inodes after unmount on 2 way SMP Trond Myklebust 2003-09-18 8:26 ` Olaf Kirch @ 2003-09-25 23:17 ` Matt C 2003-09-26 0:24 ` Trond Myklebust 2003-09-29 3:27 ` Frank Cusack 1 sibling, 2 replies; 12+ messages in thread From: Matt C @ 2003-09-25 23:17 UTC (permalink / raw) To: Trond Myklebust Cc: Olaf Hering, H. Peter Anvin, Arun Sharma, autofs, nfs, Ian Kent Hi All- We've been having the 'VFS: Busy inodes after unmount' problems like crazy on our desktop and server linux boxes running autofs under 2.4.21 (vanilla). We're using the autofs-3.1.7 userspace tools, but with the autofs4 kernel module. I applied the patch that was attached earlier in this thread to our kernel and have been running it for the past few days on my desktop. These errors have completely disappeared, and autofs is behaving as expected so far. So, while it might be the wrong thing to do, it does fix our problems. -matt On 18 Sep 2003, Trond Myklebust wrote: > >>>>> " " == Olaf Hering <olh@suse.de> writes: > > > On Wed, Sep 17, H. Peter Anvin wrote: > >> Okay... let me ask this so I get it straight... > >> > >> Has anyone seen this (busy inodes after stopping the > >> automounter) using autofs v3 kernel module and daemon? > > > I'm not sure, but everyone who has seen this should fiddle this > > patch into the kernel and see how it goes. The whole thing > > started very recently (post 2.4.21) for us. > > > This patch is untested, any feedback appreciated. > > ...and is indeed wrong... It does the exact opposite of what > sillydelete should do. Instead of causing the last application that > closes the file to perform the sillydelete, you are asking the *first* > application that closes it to do so. > Sillydelete *has* to be tied to dentries. Not files, and not > inodes. It is purely a namespace operation... > > So exactly what are you trying to do, and why? > > Cheers, > Trond > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > NFS maillist - NFS@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/nfs > ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ NFS maillist - NFS@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Re: [autofs] VFS: Busy inodes after unmount on 2 way SMP 2003-09-25 23:17 ` Matt C @ 2003-09-26 0:24 ` Trond Myklebust [not found] ` <200309261831.h8QIVNVw026806@buggy.badula.org> 2003-09-29 3:27 ` Frank Cusack 1 sibling, 1 reply; 12+ messages in thread From: Trond Myklebust @ 2003-09-26 0:24 UTC (permalink / raw) To: Matt C Cc: Trond Myklebust, Olaf Hering, H. Peter Anvin, Arun Sharma, autofs, nfs, Ian Kent >>>>> " " == Matt C <Matt> writes: > Hi All- We've been having the 'VFS: Busy inodes after unmount' > problems like crazy on our desktop and server linux boxes > running autofs under 2.4.21 (vanilla). We're using the > autofs-3.1.7 userspace tools, but with the autofs4 kernel > module. > I applied the patch that was attached earlier in this thread to > our kernel and have been running it for the past few days on my > desktop. These errors have completely disappeared, and autofs > is behaving as expected so far. > So, while it might be the wrong thing to do, it does fix our > problems. That changes nothing. It is still not a "fix" that I want to see go into the main kernel. The problem here is that sillyrename needs to hold onto the parent directory's inode until it is done, and yet it cannot know which vfsmount struct to hold onto because that information is not passed down by the VFS. I would rather then have something like the appended patch go in to which force the last process to close the file to actually wait on completion (unless someone signals it with a 'kill -9' - in which case they are knowingly breaking things). Cheers, Trond diff -u --recursive --new-file linux-2.4.22-03-soft2/fs/nfs/dir.c linux-2.4.22-04-fix_unlink/fs/nfs/dir.c --- linux-2.4.22-03-soft2/fs/nfs/dir.c 2002-10-15 06:59:27.000000000 +0200 +++ linux-2.4.22-04-fix_unlink/fs/nfs/dir.c 2003-07-03 12:29:28.000000000 +0200 @@ -994,7 +994,7 @@ struct inode *old_inode = old_dentry->d_inode; struct inode *new_inode = new_dentry->d_inode; struct dentry *dentry = NULL, *rehash = NULL; - int error = -EBUSY; + int error; /* * To prevent any new references to the target during the rename, @@ -1020,6 +1020,12 @@ */ if (!new_inode) goto go_ahead; + /* If target is a hard link to the source, then noop */ + error = 0; + if (NFS_FILEID(new_inode) == NFS_FILEID(old_inode)) + goto out; + + error = -EBUSY; if (S_ISDIR(new_inode->i_mode)) goto out; else if (atomic_read(&new_dentry->d_count) > 1) { diff -u --recursive --new-file linux-2.4.22-03-soft2/fs/nfs/unlink.c linux-2.4.22-04-fix_unlink/fs/nfs/unlink.c --- linux-2.4.22-03-soft2/fs/nfs/unlink.c 2002-08-11 13:34:02.000000000 +0200 +++ linux-2.4.22-04-fix_unlink/fs/nfs/unlink.c 2003-07-03 12:29:28.000000000 +0200 @@ -12,6 +12,7 @@ #include <linux/sunrpc/sched.h> #include <linux/sunrpc/clnt.h> #include <linux/nfs_fs.h> +#include <linux/wait.h> struct nfs_unlinkdata { @@ -21,6 +22,9 @@ struct rpc_task task; struct rpc_cred *cred; unsigned int count; + + wait_queue_head_t waitq; + int completed; }; static struct nfs_unlinkdata *nfs_deletes; @@ -133,6 +137,8 @@ put_rpccred(data->cred); data->cred = NULL; dput(dir); + data->completed = 1; + wake_up(&data->waitq); } /** @@ -175,6 +181,8 @@ nfs_deletes = data; data->count = 1; + init_waitqueue_head(&data->waitq); + task = &data->task; rpc_init_task(task, clnt, nfs_async_unlink_done , RPC_TASK_ASYNC); task->tk_calldata = data; @@ -212,7 +220,10 @@ data->count++; nfs_copy_dname(dentry, data); dentry->d_flags &= ~DCACHE_NFSFS_RENAMED; - if (data->task.tk_rpcwait == &nfs_delete_queue) + if (data->task.tk_rpcwait == &nfs_delete_queue) { + struct rpc_clnt *clnt = data->task.tk_client; rpc_wake_up_task(&data->task); + nfs_wait_event(clnt, data->waitq, data->completed == 1); + } nfs_put_unlinkdata(data); } ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ NFS maillist - NFS@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs ^ permalink raw reply [flat|nested] 12+ messages in thread
[parent not found: <200309261831.h8QIVNVw026806@buggy.badula.org>]
* Re: Re: [autofs] VFS: Busy inodes after unmount on 2 way SMP [not found] ` <200309261831.h8QIVNVw026806@buggy.badula.org> @ 2003-09-26 22:29 ` Trond Myklebust 2003-09-27 16:55 ` Olaf Kirch 2003-09-29 12:07 ` Ion Badulescu 0 siblings, 2 replies; 12+ messages in thread From: Trond Myklebust @ 2003-09-26 22:29 UTC (permalink / raw) To: Ion Badulescu; +Cc: nfs >>>>> " " == Ion Badulescu <lists@news.cs.columbia.edu> writes: > Ugh, that's ugly -- and potentially a DoS issue as well. Since > you don't need any privileges to issue the 'kill -9' for your > own processes, it becomes fairly easy to write some code that > exploits this and causes kernel crashes across the board... Then don't set the "intr" flag. > Not that the current situation is any better, of course. > Perhaps making that wait an uninterruptable wait would be > enough to take care of the problem? People expect the "intr" flag to work if they set it. Cheers, Trond ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ NFS maillist - NFS@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Re: [autofs] VFS: Busy inodes after unmount on 2 way SMP 2003-09-26 22:29 ` Trond Myklebust @ 2003-09-27 16:55 ` Olaf Kirch 2003-09-28 23:16 ` Steve Fosdick 2003-09-29 12:07 ` Ion Badulescu 1 sibling, 1 reply; 12+ messages in thread From: Olaf Kirch @ 2003-09-27 16:55 UTC (permalink / raw) To: Trond Myklebust; +Cc: Ion Badulescu, nfs On Fri, Sep 26, 2003 at 03:29:40PM -0700, Trond Myklebust wrote: > > Not that the current situation is any better, of course. > > > Perhaps making that wait an uninterruptable wait would be > > enough to take care of the problem? > > People expect the "intr" flag to work if they set it. In this case, not removing the sillyrenamed file instead of oopsing may be the preferred action. Olaf -- Olaf Kirch | Anyone who has had to work with X.509 has probably okir@suse.de | experienced what can best be described as ---------------+ ISO water torture. -- Peter Gutmann ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ NFS maillist - NFS@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Re: [autofs] VFS: Busy inodes after unmount on 2 way SMP 2003-09-27 16:55 ` Olaf Kirch @ 2003-09-28 23:16 ` Steve Fosdick 0 siblings, 0 replies; 12+ messages in thread From: Steve Fosdick @ 2003-09-28 23:16 UTC (permalink / raw) To: nfs On 2003.09.27 17:55, Olaf Kirch wrote: > In this case, not removing the sillyrenamed file instead > of oopsing may be the preferred action. Would it be possibly to combine both ideas, i.e. have the last process wait, but if the user attempt to kill that process and it will be allowed because intr is set the sillyrenamed file is not removed. Surely it is reasonable for people who kill -9 things to expect to do some tidying up, but not to expect a kernel panic. Steve. ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ NFS maillist - NFS@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Re: [autofs] VFS: Busy inodes after unmount on 2 way SMP 2003-09-26 22:29 ` Trond Myklebust 2003-09-27 16:55 ` Olaf Kirch @ 2003-09-29 12:07 ` Ion Badulescu 2003-09-29 17:22 ` Trond Myklebust 1 sibling, 1 reply; 12+ messages in thread From: Ion Badulescu @ 2003-09-29 12:07 UTC (permalink / raw) To: Trond Myklebust; +Cc: nfs On Fri, 26 Sep 2003, Trond Myklebust wrote: > > Perhaps making that wait an uninterruptable wait would be > > enough to take care of the problem? > > People expect the "intr" flag to work if they set it. People also expect the supported "intr" flag not to cause security problems and would gladly take an unkillable process over a kernel oops... Ion -- It is better to keep your mouth shut and be thought a fool, than to open it and remove all doubt. ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ NFS maillist - NFS@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Re: [autofs] VFS: Busy inodes after unmount on 2 way SMP 2003-09-29 12:07 ` Ion Badulescu @ 2003-09-29 17:22 ` Trond Myklebust 2003-09-30 12:50 ` Olaf Kirch 0 siblings, 1 reply; 12+ messages in thread From: Trond Myklebust @ 2003-09-29 17:22 UTC (permalink / raw) To: Ion Badulescu; +Cc: nfs >>>>> " " == Ion Badulescu <lists@news.cs.columbia.edu> writes: >> People expect the "intr" flag to work if they set it. > People also expect the supported "intr" flag not to cause > security problems and would gladly take an unkillable process > over a kernel oops... You'd have to be extremely unlucky to kill the process and hit the window for the Oops. I defy you to come up with an exploit for it. That said, I agree that a full fix would be preferable. I'm working on other projects right now, that's why I'm being slow about this issue (plus the fact that it's not exactly easy to reproduce). I'll get onto it soon... Cheers, Trond ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ NFS maillist - NFS@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Re: [autofs] VFS: Busy inodes after unmount on 2 way SMP 2003-09-29 17:22 ` Trond Myklebust @ 2003-09-30 12:50 ` Olaf Kirch 2003-09-30 13:31 ` Trond Myklebust 0 siblings, 1 reply; 12+ messages in thread From: Olaf Kirch @ 2003-09-30 12:50 UTC (permalink / raw) To: Trond Myklebust; +Cc: Ion Badulescu, nfs [-- Attachment #1: Type: text/plain, Size: 1617 bytes --] On Mon, Sep 29, 2003 at 10:22:40AM -0700, Trond Myklebust wrote: > You'd have to be extremely unlucky to kill the process and hit the > window for the Oops. I defy you to come up with an exploit for it. > > That said, I agree that a full fix would be preferable. I'm working on > other projects right now, that's why I'm being slow about this issue > (plus the fact that it's not exactly easy to reproduce). I'll get onto > it soon... I've had no luck reproducing it either in a controlled environment. However the bug is common enough to crash a few of our build machines over a weekend... I took your patch, Trond, and modified it a little to not crash if the user ctrl-c's the unlink. Still not pretty - maybe it should zap the cached attributes: @@ -212,7 +222,15 @@ data->count++; nfs_copy_dname(dentry, data); dentry->d_flags &= ~DCACHE_NFSFS_RENAMED; - if (data->task.tk_rpcwait == &nfs_delete_queue) + if (data->task.tk_rpcwait == &nfs_delete_queue) { + struct rpc_clnt *clnt = data->task.tk_client; rpc_wake_up_task(&data->task); + nfs_wait_event(clnt, data->waitq, data->completed == 1); + /* This is safe as we hold the BKL */ + if (!data->completed) { + dput(data->dir); + data->dir = NULL; + } + } nfs_put_unlinkdata(data); } Olaf -- Olaf Kirch | Anyone who has had to work with X.509 has probably okir@suse.de | experienced what can best be described as ---------------+ ISO water torture. -- Peter Gutmann [-- Attachment #2: nfs-autofs-umount-crash --] [-- Type: text/plain, Size: 2362 bytes --] diff -ur linux-2.4.21/fs/nfs/dir.c nfs/fs/nfs/dir.c --- linux-2.4.21/fs/nfs/dir.c 2003-09-29 10:33:41.000000000 +0200 +++ nfs/fs/nfs/dir.c 2003-09-29 12:34:36.000000000 +0200 @@ -1144,7 +1144,7 @@ struct inode *old_inode = old_dentry->d_inode; struct inode *new_inode = new_dentry->d_inode; struct dentry *dentry = NULL, *rehash = NULL; - int error = -EBUSY; + int error; /* * To prevent any new references to the target during the rename, @@ -1170,6 +1170,12 @@ */ if (!new_inode) goto go_ahead; + /* If target is a hard link to the source, then noop */ + error = 0; + if (NFS_FILEID(new_inode) == NFS_FILEID(old_inode)) + goto out; + + error = -EBUSY; if (S_ISDIR(new_inode->i_mode)) goto out; else if (atomic_read(&new_dentry->d_count) > 1) { diff -ur linux-2.4.21/fs/nfs/unlink.c nfs/fs/nfs/unlink.c --- linux-2.4.21/fs/nfs/unlink.c 2002-11-29 00:53:15.000000000 +0100 +++ nfs/fs/nfs/unlink.c 2003-09-29 13:38:49.000000000 +0200 @@ -12,6 +12,7 @@ #include <linux/sunrpc/sched.h> #include <linux/sunrpc/clnt.h> #include <linux/nfs_fs.h> +#include <linux/wait.h> struct nfs_unlinkdata { @@ -21,6 +22,9 @@ struct rpc_task task; struct rpc_cred *cred; unsigned int count; + + wait_queue_head_t waitq; + int completed; }; static struct nfs_unlinkdata *nfs_deletes; @@ -54,6 +58,8 @@ nfs_detach_unlinkdata(data); if (data->name.name != NULL) kfree(data->name.name); + if (data->cred) + put_rpccred(data->cred); kfree(data); } } @@ -133,6 +139,8 @@ put_rpccred(data->cred); data->cred = NULL; dput(dir); + data->completed = 1; + wake_up(&data->waitq); } /** @@ -175,6 +183,8 @@ nfs_deletes = data; data->count = 1; + init_waitqueue_head(&data->waitq); + task = &data->task; rpc_init_task(task, clnt, nfs_async_unlink_done , RPC_TASK_ASYNC); task->tk_calldata = data; @@ -212,7 +222,15 @@ data->count++; nfs_copy_dname(dentry, data); dentry->d_flags &= ~DCACHE_NFSFS_RENAMED; - if (data->task.tk_rpcwait == &nfs_delete_queue) + if (data->task.tk_rpcwait == &nfs_delete_queue) { + struct rpc_clnt *clnt = data->task.tk_client; rpc_wake_up_task(&data->task); + nfs_wait_event(clnt, data->waitq, data->completed == 1); + /* This is safe as we hold the BKL */ + if (!data->completed) { + dput(data->dir); + data->dir = NULL; + } + } nfs_put_unlinkdata(data); } ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Re: [autofs] VFS: Busy inodes after unmount on 2 way SMP 2003-09-30 12:50 ` Olaf Kirch @ 2003-09-30 13:31 ` Trond Myklebust 0 siblings, 0 replies; 12+ messages in thread From: Trond Myklebust @ 2003-09-30 13:31 UTC (permalink / raw) To: Olaf Kirch; +Cc: Ion Badulescu, nfs >>>>> " " == Olaf Kirch <okir@suse.de> writes: > On Mon, Sep 29, 2003 at 10:22:40AM -0700, Trond Myklebust >> That said, I agree that a full fix would be preferable. I'm >> working on other projects right now, that's why I'm being slow >> about this issue (plus the fact that it's not exactly easy to >> reproduce). I'll get onto it soon... > I've had no luck reproducing it either in a controlled > environment. However the bug is common enough to crash a few > of our build machines over a weekend... > I took your patch, Trond, and modified it a little to not crash > if the user ctrl-c's the unlink. Still not pretty - maybe it > should zap the cached attributes: Alternatively, we should perhaps make fsync_super() sync out all dirty inodes and readaheads, then wait on all pending RPC ops. That would be cleaner, I think... Cheers, Trond ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ NFS maillist - NFS@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Re: [autofs] VFS: Busy inodes after unmount on 2 way SMP 2003-09-25 23:17 ` Matt C 2003-09-26 0:24 ` Trond Myklebust @ 2003-09-29 3:27 ` Frank Cusack 1 sibling, 0 replies; 12+ messages in thread From: Frank Cusack @ 2003-09-29 3:27 UTC (permalink / raw) To: Matt C Cc: Trond Myklebust, Olaf Hering, H. Peter Anvin, Arun Sharma, autofs, nfs, Ian Kent Does this patch help? --- linux-2.4.22/fs/namei.c 2003-08-25 04:44:43.000000000 -0700 +++ linux-2.4.22-gg4/fs/namei.c 2003-09-26 00:03:16.000000000 -0700 @@ -893,6 +893,8 @@ static inline int check_sticky(struct in * 7. If we were asked to remove a directory and victim isn't one - ENOTDIR. * 8. If we were asked to remove a non-directory and victim isn't one - EISDIR. * 9. We can't remove a root or mountpoint. + * 10. We don't allow removal of NFS sillyrenamed files; it's handled by + * nfs_async_unlink(). */ static inline int may_delete(struct inode *dir,struct dentry *victim, int isdir) { @@ -916,6 +918,8 @@ static inline int may_delete(struct inod return -EISDIR; if (IS_DEADDIR(dir)) return -ENOENT; + if (victim->d_flags & DCACHE_NFSFS_RENAMED) + return -EBUSY; return 0; } @@ -1484,13 +1488,14 @@ int vfs_unlink(struct inode *dir, struct lock_kernel(); error = dir->i_op->unlink(dir, dentry); unlock_kernel(); - if (!error) + if (!error && + !(dentry->d_flags & DCACHE_NFSFS_RENAMED)) d_delete(dentry); } } } up(&dir->i_zombie); - if (!error) + if (!error && !(dentry->d_flags & DCACHE_NFSFS_RENAMED)) inode_dir_notify(dir, DN_DELETE); return error; } ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ NFS maillist - NFS@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2003-09-30 13:32 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <Pine.LNX.4.33.0309171251290.25153-100000@wombat.indigo.net.au>
[not found] ` <3F689E40.6090802@intel.com>
[not found] ` <3F68C6EB.2080706@zytor.com>
[not found] ` <20030917210023.GA15099@suse.de>
2003-09-18 5:52 ` Re: [autofs] VFS: Busy inodes after unmount on 2 way SMP Trond Myklebust
2003-09-18 8:26 ` Olaf Kirch
2003-09-25 23:17 ` Matt C
2003-09-26 0:24 ` Trond Myklebust
[not found] ` <200309261831.h8QIVNVw026806@buggy.badula.org>
2003-09-26 22:29 ` Trond Myklebust
2003-09-27 16:55 ` Olaf Kirch
2003-09-28 23:16 ` Steve Fosdick
2003-09-29 12:07 ` Ion Badulescu
2003-09-29 17:22 ` Trond Myklebust
2003-09-30 12:50 ` Olaf Kirch
2003-09-30 13:31 ` Trond Myklebust
2003-09-29 3:27 ` Frank Cusack
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox