Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Chuck Lever <chuck.lever@oracle.com>
To:     Bruce Fields <bfields@fieldses.org>
CC:     Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH v1 12/42] NFSD: Update the NFSv3 FSSTAT3res encoder to use
 struct xdr_stream
Thread-Topic: [PATCH v1 12/42] NFSD: Update the NFSv3 FSSTAT3res encoder to
 use struct xdr_stream
Thread-Index: AQHXDq5LtiyQpyHVN0Gs9zjPv8p1s6pxLI4AgAADfgA=
Date:   Tue, 2 Mar 2021 20:57:52 +0000
Message-ID: <FBB0E09F-BD89-4B6B-98A2-757F75387411@oracle.com>
References: <161461145466.8508.13379815439337754427.stgit@klimt.1015granger.net>
 <161461179102.8508.11890812651210896607.stgit@klimt.1015granger.net>
 <20210302204520.GF3400@fieldses.org>
In-Reply-To: <20210302204520.GF3400@fieldses.org>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-ID: <6F5851F1FF26684DA31FBA003C701242@namprd10.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: be109d15-9ec8-4e7d-ac9c-08d8ddbdd863
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Mar 2021 20:57:52.0469
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Tx/gcKDgW6y1IRc+vIV2ZPh1lqLQ5JrFoCBRnID9oBYjPwtu3vZ1qf/XQiTdvtGY4ovkaf+TxCJaaTTnSz3/CA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR10MB3143
X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9911 signatures=668683
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 mlxlogscore=999
 phishscore=0 bulkscore=0 mlxscore=0 spamscore=0 suspectscore=0
 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2009150000 definitions=main-2103020159
X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9911 signatures=668683
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 clxscore=1015 malwarescore=0
 mlxlogscore=999 spamscore=0 phishscore=0 lowpriorityscore=0
 impostorscore=0 mlxscore=0 suspectscore=0 bulkscore=0 adultscore=0
 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2009150000 definitions=main-2103020159
Precedence: bulk
List-ID: <linux-nfs.vger.kernel.org>
X-Mailing-List: linux-nfs@vger.kernel.org


> On Mar 2, 2021, at 3:45 PM, J. Bruce Fields <bfields@fieldses.org> wrote:
>=20
> On Mon, Mar 01, 2021 at 10:16:31AM -0500, Chuck Lever wrote:
>> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
>> ---
>> fs/nfsd/nfs3xdr.c |   58 ++++++++++++++++++++++++++++++++++++++++-------=
------
>> 1 file changed, 44 insertions(+), 14 deletions(-)
>>=20
>> diff --git a/fs/nfsd/nfs3xdr.c b/fs/nfsd/nfs3xdr.c
>> index e159e4557428..e4a569e7216d 100644
>> --- a/fs/nfsd/nfs3xdr.c
>> +++ b/fs/nfsd/nfs3xdr.c
>> @@ -17,6 +17,13 @@
>> #define NFSDDBG_FACILITY		NFSDDBG_XDR
>>=20
>>=20
>> +/*
>> + * Force construction of an empty post-op attr
>> + */
>> +static const struct svc_fh nfs3svc_null_fh =3D {
>> +	.fh_no_wcc	=3D true,
>> +};
>> +
>> /*
>>  * Mapping of S_IF* types to NFS file types
>>  */
>> @@ -1392,27 +1399,50 @@ nfs3svc_encode_entry_plus(void *cd, const char *=
name,
>> 	return encode_entry(cd, name, namlen, offset, ino, d_type, 1);
>> }
>>=20
>> +static bool
>> +svcxdr_encode_fsstat3resok(struct xdr_stream *xdr,
>> +			   const struct nfsd3_fsstatres *resp)
>> +{
>> +	const struct kstatfs *s =3D &resp->stats;
>> +	u64 bs =3D s->f_bsize;
>> +	__be32 *p;
>> +
>> +	p =3D xdr_reserve_space(xdr, XDR_UNIT * 13);
>> +	if (!p)
>> +		return false;
>> +	p =3D xdr_encode_hyper(p, bs * s->f_blocks);	/* total bytes */
>> +	p =3D xdr_encode_hyper(p, bs * s->f_bfree);	/* free bytes */
>> +	p =3D xdr_encode_hyper(p, bs * s->f_bavail);	/* user available bytes *=
/
>> +	p =3D xdr_encode_hyper(p, s->f_files);		/* total inodes */
>> +	p =3D xdr_encode_hyper(p, s->f_ffree);		/* free inodes */
>> +	p =3D xdr_encode_hyper(p, s->f_ffree);		/* user available inodes */
>> +	*p =3D cpu_to_be32(resp->invarsec);		/* mean unchanged time */
>> +
>> +	return true;
>> +}
>> +
>> /* FSSTAT */
>> int
>> nfs3svc_encode_fsstatres(struct svc_rqst *rqstp, __be32 *p)
>> {
>> +	struct xdr_stream *xdr =3D &rqstp->rq_res_stream;
>> 	struct nfsd3_fsstatres *resp =3D rqstp->rq_resp;
>> -	struct kstatfs	*s =3D &resp->stats;
>> -	u64		bs =3D s->f_bsize;
>>=20
>> -	*p++ =3D resp->status;
>> -	*p++ =3D xdr_zero;	/* no post_op_attr */
>> -
>> -	if (resp->status =3D=3D 0) {
>> -		p =3D xdr_encode_hyper(p, bs * s->f_blocks);	/* total bytes */
>> -		p =3D xdr_encode_hyper(p, bs * s->f_bfree);	/* free bytes */
>> -		p =3D xdr_encode_hyper(p, bs * s->f_bavail);	/* user available bytes =
*/
>> -		p =3D xdr_encode_hyper(p, s->f_files);	/* total inodes */
>> -		p =3D xdr_encode_hyper(p, s->f_ffree);	/* free inodes */
>> -		p =3D xdr_encode_hyper(p, s->f_ffree);	/* user available inodes */
>> -		*p++ =3D htonl(resp->invarsec);	/* mean unchanged time */
>> +	if (!svcxdr_encode_nfsstat3(xdr, resp->status))
>> +		return 0;
>> +	switch (resp->status) {
>> +	case nfs_ok:
>> +		if (!svcxdr_encode_post_op_attr(rqstp, xdr, &nfs3svc_null_fh))
>> +			return 0;
>> +		if (!svcxdr_encode_fsstat3resok(xdr, resp))
>> +			return 0;
>> +		break;
>> +	default:
>> +		if (!svcxdr_encode_post_op_attr(rqstp, xdr, &nfs3svc_null_fh))
>> +			return 0;
>=20
> Dumb question: will this result in the same xdr on the wire as the above
> that just hard-coded xdr_zero?

It should result in an xdr_zero. The point here is to document what that
xdr_zero means: basically that it is an absent post_op_attr.

The simpler form would be

     if (xdr_stream_encode_item_absent(xdr) < 0)
           return 0;

Which has the same amount of boilerplatiness but is less explanatory.


> I feel like there's a lot of biolerplate error handling.  In the v4 case
> I centralized some of it after a fuzzer found an oops in some of that
> copy-pasted boilerplate:
>=20
> 	b7571e4cd39a nfsd4: skip encoder in trivial error cases
> 	bac966d60652 nfsd4: individual encoders no longer see error cases
>=20
> I dunno, maybe that was overkill.

True, errors will be extremely rare and usually the result of a coding
error. The problem is that an encoder error can result in:

- A general protection fault that makes the server unusable, resulting
  in a temporary denial of service or at worst corruption of recently
  written data, or
- The server returning garbage or corrupted data along with an NFS_OK
  result.

So I think we need to take a little extra care here. If there's a more
efficient and easier way to do that checking, I'm all ears.


> --b.
>=20
>> 	}
>> -	return xdr_ressize_check(rqstp, p);
>> +
>> +	return 1;
>> }
>>=20
>> /* FSINFO */

--
Chuck Lever