NFSv4 cannot unmount ESTALE directories (in some cases).

NFSv4 cannot unmount ESTALE directories (in some cases).

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 1579 bytes --]


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).

The resulting patch is:
---
 fs/nfs/dir.c |    7 +++++++
 1 file changed, 7 insertions(+)

--- 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);


However I cannot easily tell if this is an elegant solution of an ugly hack,
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?

Thanks,
NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: NFSv4 cannot unmount ESTALE directories (in some cases).

[Al Viro]

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...

Re: NFSv4 cannot unmount ESTALE directories (in some cases).

[dE .]

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.