Re: [PATCH 2/2] dirstress: Allow ESTALE as well as ENOENT

[Eryu Guan <eguan@redhat.com>]

On Fri, Nov 25, 2016 at 08:39:39PM -0500, J. Bruce Fields wrote:
> From: "J. Bruce Fields" <bfields@redhat.com>
> 
> In the NFS case an attempt to chdir out of a removed directory could result
> in ESTALE, and that should not cause the test to fail.
> 
> This was causing intermittent failures on generic/011 on NFS.
> 
> Signed-off-by: J. Bruce Fields <bfields@redhat.com>
> ---
>  src/dirstress.c | 12 ++++++++----
>  1 file changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/src/dirstress.c b/src/dirstress.c
> index f8f73553a1bc..33a166c51819 100644
> --- a/src/dirstress.c
> +++ b/src/dirstress.c
> @@ -203,8 +203,10 @@ dirstress(
>          if (verbose) fprintf(stderr,"** [%d] chdir ..\n", pid);
>  	error = chdir("..");
>  	if (error) {
> -		/* If this is multithreaded, then expecting a ENOENT here is fine */
> -		if (nprocs_per_dir > 1 && errno == ENOENT) {
> +		/* If this is multithreaded, then expecting a ENOENT here is fine,
> +		 * and ESTALE is normal in the NFS case. */
> +		if (nprocs_per_dir > 1 &&
> +				(errno == ENOENT || errno = ESTALE)) {
                                                         ^^^ this should be ==
>  			return 0;
>  		}
>  
> @@ -224,8 +226,10 @@ dirstress(
>          if (verbose) fprintf(stderr,"** [%d] chdir ..\n", pid);
>  	error = chdir("..");
>  	if (error) {
> -		/* If this is multithreaded, then expecting a ENOENT here is fine */
> -		if (nprocs_per_dir > 1 && errno == ENOENT) {
> +		/* If this is multithreaded, then expecting a ENOENT here is fine,
> +		 * and ESTALE is normal in the NFS case. */
> +		if (nprocs_per_dir > 1 &&
> +				(errno == ENOENT || errno = ESTALE)) {
                                                         ^^^ same here

I can fix them at commit time, no resend is needed.

Thanks,
Eryu

>  			return 0;
>  		}
>  
> -- 
> 2.9.3
> 
> --
> To unsubscribe from this list: send the line "unsubscribe fstests" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html