Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Mon, 9 Apr 2018 11:27:47 -0400
From:   "J. Bruce Fields" <bfields@redhat.com>
To:     Sasha Levin <Alexander.Levin@microsoft.com>
Cc:     "stable@vger.kernel.org" <stable@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH AUTOSEL for 4.15 168/189] nfsd: return RESOURCE not
 GARBAGE_ARGS on too many ops
Message-ID: <20180409152746.GA25317@parsley.fieldses.org>
References: <20180409001637.162453-1-alexander.levin@microsoft.com>
 <20180409001637.162453-168-alexander.levin@microsoft.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20180409001637.162453-168-alexander.levin@microsoft.com>
User-Agent: Mutt/1.9.2 (2017-12-15)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

What's your default on these patches on these AUTOSEL patches if you
don't get an ACK or NACK?  Do you apply them anyway?

(I'd skip this one as it doesn't meet the "It must fix a real bug that
bothers people" criterion.  But I don't recall it *causing* any bugs
either, so the stakes are low, I'm mainly just curious.)

--b.

On Mon, Apr 09, 2018 at 12:19:02AM +0000, Sasha Levin wrote:
> From: "J. Bruce Fields" <bfields@redhat.com>
> 
> [ Upstream commit 0078117c6d9160031b866cfa1853514d4f6865d2 ]
> 
> A client that sends more than a hundred ops in a single compound
> currently gets an rpc-level GARBAGE_ARGS error.
> 
> It would be more helpful to return NFS4ERR_RESOURCE, since that gives
> the client a better idea how to recover (for example by splitting up the
> compound into smaller compounds).
> 
> This is all a bit academic since we've never actually seen a reason for
> clients to send such long compounds, but we may as well fix it.
> 
> While we're there, just use NFSD4_MAX_OPS_PER_COMPOUND == 16, the
> constant we already use in the 4.1 case, instead of hard-coding 100.
> Chances anyone actually uses even 16 ops per compound are small enough
> that I think there's a neglible risk or any regression.
> 
> This fixes pynfs test COMP6.
> 
> Reported-by: "Lu, Xinyu" <luxy.fnst@cn.fujitsu.com>
> Signed-off-by: J. Bruce Fields <bfields@redhat.com>
> Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
> ---
>  fs/nfsd/nfs4proc.c | 3 +++
>  fs/nfsd/nfs4xdr.c  | 9 +++++++--
>  2 files changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/nfsd/nfs4proc.c b/fs/nfsd/nfs4proc.c
> index effeeb4f556f..a0bed2b2004d 100644
> --- a/fs/nfsd/nfs4proc.c
> +++ b/fs/nfsd/nfs4proc.c
> @@ -1703,6 +1703,9 @@ nfsd4_proc_compound(struct svc_rqst *rqstp)
>  	status = nfserr_minor_vers_mismatch;
>  	if (nfsd_minorversion(args->minorversion, NFSD_TEST) <= 0)
>  		goto out;
> +	status = nfserr_resource;
> +	if (args->opcnt > NFSD_MAX_OPS_PER_COMPOUND)
> +		goto out;
>  
>  	status = nfs41_check_op_ordering(args);
>  	if (status) {
> diff --git a/fs/nfsd/nfs4xdr.c b/fs/nfsd/nfs4xdr.c
> index 2c61c6b8ae09..5dcd7cb45b2d 100644
> --- a/fs/nfsd/nfs4xdr.c
> +++ b/fs/nfsd/nfs4xdr.c
> @@ -1918,8 +1918,13 @@ nfsd4_decode_compound(struct nfsd4_compoundargs *argp)
>  
>  	if (argp->taglen > NFSD4_MAX_TAGLEN)
>  		goto xdr_error;
> -	if (argp->opcnt > 100)
> -		goto xdr_error;
> +	/*
> +	 * NFS4ERR_RESOURCE is a more helpful error than GARBAGE_ARGS
> +	 * here, so we return success at the xdr level so that
> +	 * nfsd4_proc can handle this is an NFS-level error.
> +	 */
> +	if (argp->opcnt > NFSD_MAX_OPS_PER_COMPOUND)
> +		return 0;
>  
>  	if (argp->opcnt > ARRAY_SIZE(argp->iops)) {
>  		argp->ops = kzalloc(argp->opcnt * sizeof(*argp->ops), GFP_KERNEL);
> -- 
> 2.15.1