| Message ID | 20130121134859.24fbd103@notabene.brown (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Mon, Jan 21, 2013 at 01:48:59PM +1100, NeilBrown wrote: > > If you use NFSv4 to "mount server:/foo/bar /mnt", then "rm -r" /foo/bar on the > server, then accesses to /mnt will naturally return ESTALE. > > Unfortunately "umount /mnt" will also return ESTALE and leave the stale > directory mounted. Adding "-l" or "-f" to "umount" doesn't help. > > The problem is that nfs_lookup_revalidate fails. As the mountpoint is never > not accessed by a lookup (after the initial mount) it seems a bit pointless > calling d_revalidate in this case ... by maybe not. > > I can make the problem go away by testing for LOOKUP_JUMP and having > nfs_lookup_revalidate never fail if that flag it set (for a directory). > However I cannot easily tell if this is an elegant solution of an ugly hack, The latter. Definitely. > and am hoping that someone who understands revalidation and LOOKUP_JUMPED > better than I (who only discovered the latter today) could provide advice. > > Al? Trond? Should I make this into a formal patch submission, or is there > a better way? I really suspect that mountpoint crossing on umount ought to be done differently. I'll need to play with possible variants a bit before I can offer any replacement though... -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 01/21/13 08:39, Al Viro wrote: > On Mon, Jan 21, 2013 at 01:48:59PM +1100, NeilBrown wrote: >> If you use NFSv4 to "mount server:/foo/bar /mnt", then "rm -r" /foo/bar on the >> server, then accesses to /mnt will naturally return ESTALE. >> >> Unfortunately "umount /mnt" will also return ESTALE and leave the stale >> directory mounted. Adding "-l" or "-f" to "umount" doesn't help. >> >> The problem is that nfs_lookup_revalidate fails. As the mountpoint is never >> not accessed by a lookup (after the initial mount) it seems a bit pointless >> calling d_revalidate in this case ... by maybe not. >> >> I can make the problem go away by testing for LOOKUP_JUMP and having >> nfs_lookup_revalidate never fail if that flag it set (for a directory). >> However I cannot easily tell if this is an elegant solution of an ugly hack, > The latter. Definitely. > >> and am hoping that someone who understands revalidation and LOOKUP_JUMPED >> better than I (who only discovered the latter today) could provide advice. >> >> Al? Trond? Should I make this into a formal patch submission, or is there >> a better way? > I really suspect that mountpoint crossing on umount ought to be done > differently. I'll need to play with possible variants a bit before I can > offer any replacement though... > -- > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html I'm affected. I've to do exportfs -f to fix the issue. This problem only persists with loop mounts. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
--- linux-3.0-SLE11-SP2.orig/fs/nfs/dir.c +++ linux-3.0-SLE11-SP2/fs/nfs/dir.c @@ -1183,6 +1183,13 @@ out_zap_parent: goto out_valid; if (dentry->d_flags & DCACHE_DISCONNECTED) goto out_valid; + if (flags & LOOKUP_JUMPED) + /* Didn't use a name to get here, so saying + * the name is invalid is pointless. + * This allows "umount" to succeed on a + * STALE mountpoint. + */ + goto out_valid; shrink_dcache_parent(dentry); } d_drop(dentry);