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 III <chuck.lever@oracle.com>
To:     Dan Aloni <dan.aloni@vastdata.com>
CC:     Anna Schumaker <Anna.Schumaker@netapp.com>,
        "trondmy@kernel.org" <trondmy@kernel.org>,
        Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH] NFSD: trim reads past NFS_OFFSET_MAX
Thread-Topic: [PATCH] NFSD: trim reads past NFS_OFFSET_MAX
Thread-Index: AQHYDvfTRZNTkkSWjkWDIwR2Vc39WaxuD5oA
Date:   Fri, 21 Jan 2022 22:32:28 +0000
Message-ID: <5DD3C5DF-52EF-4C84-894C-FCBB9A0F4259@oracle.com>
References: <fa9974724216c43f9bdb3fd39555d398fde11e59.camel@hammerspace.com>
 <20220121185023.260128-1-dan.aloni@vastdata.com>
In-Reply-To: <20220121185023.260128-1-dan.aloni@vastdata.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?RBzNPTBwndnSzpaA+flNT9Y+A6FzgFRtk3vD3wKQtQWUAzfKB+1Ep12l1Az/?=
 =?us-ascii?Q?4WoDiHg9FudtaP/NXI3shd0bPbhmB58HtSrR9UUQtqU3k3s4QisJSsD0ipfw?=
 =?us-ascii?Q?L+7BX4Ci/M9bBercQdBo8CqFi6vKGSqBnHxxIqWkJaFUySbVcPVcrxJbKHzM?=
 =?us-ascii?Q?brRQUWdsWhNhGTFz4Kf0H4oWKOh0BFA+NsuvtVoXa6zFzkL+IrJnYzI/VZyB?=
 =?us-ascii?Q?ms+9QAhReh9ict9hQpEq5zASiv/tHKnQpDoa+RJUMoS88lyOrKPCu1s8a3zS?=
 =?us-ascii?Q?FHh9IPWYNcXpFYXlXtIyCDUAR7L7em5+EVAhHFQDGvRT0LHJcLIRX6JmO8Bn?=
 =?us-ascii?Q?whEv1gB1gCokaxmgNOJVt1DDsts9pv0IkYP2HlsQNvvTUFzNFUH4Bvm6XHwH?=
 =?us-ascii?Q?3yTYHbOWVL0LeE8KLEy42mV5EY459VJpJt/91UYxPhl9vaEey1e+vRAnOBsB?=
 =?us-ascii?Q?t160DIJ0BPeJIMucTkWyBExvrMDyr2bOQjB3b4NqXX/0i41p2ryX5efjJ2YC?=
 =?us-ascii?Q?yef2esJiNC7Dw3FxzJYPRhzYccN+cTeJBycFi7FkxKYWg6c2RUEcC+dHK7WI?=
 =?us-ascii?Q?SHhFXuv/5Sd7GnmYlP3oRFuMWDj5273OT5RT7SuKTmdQShlHHc0XU9BARFYh?=
 =?us-ascii?Q?PlHkZXEZwyUqYnvMk+ja/9vksUNHK4+SPQymhCtWgysCBIctEk27Ys9NJsa/?=
 =?us-ascii?Q?DQmGFKLKQTmSIGlXaBAmSoJhRaux4jui9dR+nqYS8z41jU5ISWizZxvhS6HN?=
 =?us-ascii?Q?5kUXxlkYfPFHUHk0EFsjCBfHZd4Mx4JaaMcAA0LvCOEyeRnAT3sma6MBoeAd?=
 =?us-ascii?Q?WnoHE+Hrg2173p63feJnBz+LLIvFjOdhRLuUaPTu7IPsL2+uIXJmMlfHXlUF?=
 =?us-ascii?Q?7B6pHSNYQfC4OW1E8eo60JzkePy0urw2TfXc9/ZnITj4Hp+my31c/Tkre2/A?=
 =?us-ascii?Q?lR0wWvt58hTgOjn+x2eByFHZ4VTKgZfUmQVaJJ4EX+pRYfZxQ7j4Na04ucFb?=
 =?us-ascii?Q?nfyu2ry930dfzQuJSZ3iU0e1YCIo79MYzGlDd/gCgQ2tl1u+ZiTKReAAASOV?=
 =?us-ascii?Q?YS5mFbXy766H9v9OaTtRXqqLDdl/8T57filYuR+axJ+Os7QyGDKrb+I2pe2C?=
 =?us-ascii?Q?bZpepYrUderYy0jBxYESiigsF6dvX9eVXgOPxZM9y5K00qNjrAgw0sn6pUya?=
 =?us-ascii?Q?HRZHPpYJpe67EacFuougGwlsjtTtikSzKXShbwCC4qBIG2TXslRRqx6Nsjie?=
 =?us-ascii?Q?i+jIUHdERaS++emeD8UzG5kE7FLnvPvJULHL9tNWQ6m+49FqJOQZnQ5uYkJA?=
 =?us-ascii?Q?4XS5xqTqHgpnB4e/sF1siITI7yD7xj+1hpAaxag7V9lr3Z4bIaapGyIx0y4/?=
 =?us-ascii?Q?miQmkyjRZVcdkb5oLFJbremsQGYLwjh/g2FfkVaBmnOCD1chgBhZTn+CzFCP?=
 =?us-ascii?Q?1xGIaNGW3zDcnBXyG6S/wFQd9Env97XwEhOJUHJef2Jel9xz5YPDRb7F2RZg?=
 =?us-ascii?Q?4aLRPQQrjktOSSbUUsUSMcWQx3qP5krQYU5DpPXfZ24XgVxqIHbEm8wEMqHe?=
 =?us-ascii?Q?Yrhw+xsqra8ZQvOjYFPNtmjaAQZ6D6RDvwFjrZo9rViKUgWUf9cnhKNdfjR1?=
 =?us-ascii?Q?8b6ayrmCr3hxxs20cTeGqKQ=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <96AC6051E3DA91489ACEFF489D6AD16B@namprd10.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CH0PR10MB4858.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4a4d885e-780b-4618-9c79-08d9dd2de816
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jan 2022 22:32:28.5448
 (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: FyG40JJjhu4N7VwbuK6C5EpFEUq6/kmvrFuOq//XmL/Ase4C2QRve4sFpu2/mOvBkTfMaw5y7y/1QR/LFaepEw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR10MB4755
X-Proofpoint-Virus-Version: vendor=nai engine=6300 definitions=10234 signatures=668683
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 mlxscore=0 suspectscore=0
 spamscore=0 mlxlogscore=999 bulkscore=0 malwarescore=0 adultscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2201110000
 definitions=main-2201210141
X-Proofpoint-GUID: 5cM5RZ4ZTDKho6EcLGV5wlkDQTJ4Uayb
X-Proofpoint-ORIG-GUID: 5cM5RZ4ZTDKho6EcLGV5wlkDQTJ4Uayb
Precedence: bulk
List-ID: <linux-nfs.vger.kernel.org>
X-Mailing-List: linux-nfs@vger.kernel.org

Hi Dan!

NFS server patches should be sent to me these days.

$ scripts/get_maintainer.pl fs/nfsd
Chuck Lever <chuck.lever@oracle.com> (supporter:KERNEL NFSD, SUNRPC, AND LO=
CKD SERVERS)
linux-nfs@vger.kernel.org (open list:KERNEL NFSD, SUNRPC, AND LOCKD SERVERS=
)
linux-kernel@vger.kernel.org (open list)


> On Jan 21, 2022, at 1:50 PM, Dan Aloni <dan.aloni@vastdata.com> wrote:
>=20
> Due to change 8cfb9015280d ("NFS: Always provide aligned buffers to the
> RPC read layers"), a read of 0xfff is aligned up to server rsize of
> 0x1000.
>=20
> As a result, in a test where the server has a file of size
> 0x7fffffffffffffff, and the client tries to read from the offset
> 0x7ffffffffffff000, the read causes loff_t overflow in the server and it
> returns an NFS code of EINVAL to the client. The client as a result
> indefinitely retries the request.

An infinite loop in this case is a client bug.

Section 3.3.6 of RFC 1813 permits the NFSv3 READ procedure
to return NFS3ERR_INVAL. The READ entry in Table 6 of RFC
5661 permits the NFSv4 READ operation to return
NFS4ERR_INVAL.

Was the client side fix for this issue rejected?


> This fixes the issue at server side by trimming reads past NFS_OFFSET_MAX=
.

It's OK for the server to return a short READ in this case,
so I will indeed consider a change to make that happen. But
see below for comments specific to this patch.


> Fixes: 8cfb9015280d ("NFS: Always provide aligned buffers to the RPC read=
 layers")
> Signed-off-by: Dan Aloni <dan.aloni@vastdata.com>
> ---
> fs/nfsd/vfs.c | 4 ++++
> 1 file changed, 4 insertions(+)
>=20
> diff --git a/fs/nfsd/vfs.c b/fs/nfsd/vfs.c
> index 738d564ca4ce..754f4e9ff4a2 100644
> --- a/fs/nfsd/vfs.c
> +++ b/fs/nfsd/vfs.c
> @@ -1046,6 +1046,10 @@ __be32 nfsd_read(struct svc_rqst *rqstp, struct sv=
c_fh *fhp,
> 	__be32 err;
>=20
> 	trace_nfsd_read_start(rqstp, fhp, offset, *count);
> +
> +	if (unlikely(offset + *count > NFS_OFFSET_MAX))
> +		*count =3D NFS_OFFSET_MAX - offset;

Can @offset ever be larger than NFS_OFFSET_MAX?

Does this check have any effect on NFSv4 READ operations?


> +
> 	err =3D nfsd_file_acquire(rqstp, fhp, NFSD_MAY_READ, &nf);
> 	if (err)
> 		return err;
> --=20
> 2.23.0
>=20

--
Chuck Lever