From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A368FC433ED for ; Fri, 2 Apr 2021 14:32:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6035D610CB for ; Fri, 2 Apr 2021 14:32:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235788AbhDBOcT (ORCPT ); Fri, 2 Apr 2021 10:32:19 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:31702 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235714AbhDBOcS (ORCPT ); Fri, 2 Apr 2021 10:32:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1617373937; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=6E+DGN3NJ2bcradoTg4mcZ6ovZ2PZ/Vz7Q9EYkYMI6M=; b=K2/UqWsAXAIigTHExf6JR7LEFeulk4RJ56F7hsWbZBfeAjZeMUQBDJEkwXgYJfwJ2kad8X 6Rh6SN2JwK7wqF6fsGs/BBDrFJgoDm8/XCkhGe+WNa4I872zFulKv3g4AeH1d5Hm6thOWP gtu0iv1uQRVRbEnk6vCjFq5DGXqK0bQ= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-365-_X0fW7YJPiW0y2IUxSzidw-1; Fri, 02 Apr 2021 10:32:15 -0400 X-MC-Unique: _X0fW7YJPiW0y2IUxSzidw-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 8547881744F; Fri, 2 Apr 2021 14:32:14 +0000 (UTC) Received: from pick.fieldses.org (ovpn-112-59.rdu2.redhat.com [10.10.112.59]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 5355D60BF1; Fri, 2 Apr 2021 14:32:14 +0000 (UTC) Received: by pick.fieldses.org (Postfix, from userid 2815) id 2F5FF1206A8; Fri, 2 Apr 2021 10:32:13 -0400 (EDT) Date: Fri, 2 Apr 2021 10:32:13 -0400 From: "J. Bruce Fields" To: Olga Kornievskaia Cc: Chuck Lever , linux-nfs Subject: Re: [PATCH 1/1] NFSD fix handling of NFSv4.2 SEEK for data within the last hole Message-ID: References: <20210331192819.25637-1-olga.kornievskaia@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org On Thu, Apr 01, 2021 at 09:27:56AM -0400, Olga Kornievskaia wrote: > On Wed, Mar 31, 2021 at 9:50 PM J. Bruce Fields wrote: > > > > On Wed, Mar 31, 2021 at 03:28:19PM -0400, Olga Kornievskaia wrote: > > > From: Olga Kornievskaia > > > > > > According to the RFC 7862, "if the server cannot find a > > > corresponding sa_what, then the status will still be NFS4_OK, > > > but sr_eof would be TRUE". If there is a file that ends with > > > a hole and a SEEK request made for sa_what=SEEK_DATA with > > > an offset in the middle of the last hole, then the server > > > has to return OK and set the eof. Currently the linux server > > > returns ERR_NXIO. > > > > Makes sense, but I think you can use the return value from vfs_llseek > > instead of checking the file size again. E.g.: > > > > seek->seek_pos = vfs_llseek(nfs->nf_file, seek->seek_offset, whence); > > if (seek->seek_pos == -ENXIO) > > seek->seek_eof = true; > > I don't believe this is correct. (1) ENXIO doesn't imply eof. If the > specified seek_offset was beyond the end of the file the server must > return ERR_NXIO and not OK. OK, never mind. > and (2) for the same reason I need to > check if the requested type was looking for data but didn't find it > because the offset is in the middle of the hole but still within the > file size (thus the need to check if the seek_offset is within the > file size). But I'm happy to check specifically if the seek_pos was > ENXIO (and not the generic negative error) and then also check if > request was for data and request was within file size. > > Also while I'm fixing this and have your attention, Can you tell if > the "else if" condition in the original code makes sense to you. I > didn't touch it but I don't think it's correct. "else if > (seek->seek_pos >= i_size_read(file_inode(nf->nf_file)))" I don't > believe this can ever happen. How can vfs_llseek() ever return a > position that is greater than the size of the file (or actually even > equal to it)? I agree, I don't get it either. --b. > > > else if (seek->seek_pos < 0) > > status = nfserrno(seek->seek_pos); > > > > --b. > > > > > > > > Fixes: 24bab491220fa ("NFSD: Implement SEEK") > > > Signed-off-by: Olga Kornievskaia > > > --- > > > fs/nfsd/nfs4proc.c | 10 +++++++--- > > > 1 file changed, 7 insertions(+), 3 deletions(-) > > > > > > diff --git a/fs/nfsd/nfs4proc.c b/fs/nfsd/nfs4proc.c > > > index e13c4c81fb89..2e7ceb9f1d5d 100644 > > > --- a/fs/nfsd/nfs4proc.c > > > +++ b/fs/nfsd/nfs4proc.c > > > @@ -1737,9 +1737,13 @@ nfsd4_seek(struct svc_rqst *rqstp, struct nfsd4_compound_state *cstate, > > > * should ever file->f_pos. > > > */ > > > seek->seek_pos = vfs_llseek(nf->nf_file, seek->seek_offset, whence); > > > - if (seek->seek_pos < 0) > > > - status = nfserrno(seek->seek_pos); > > > - else if (seek->seek_pos >= i_size_read(file_inode(nf->nf_file))) > > > + if (seek->seek_pos < 0) { > > > + if (whence == SEEK_DATA && > > > + seek->seek_offset < i_size_read(file_inode(nf->nf_file))) > > > + seek->seek_eof = true; > > > + else > > > + status = nfserrno(seek->seek_pos); > > > + } else if (seek->seek_pos >= i_size_read(file_inode(nf->nf_file))) > > > seek->seek_eof = true; > > > > > > out: > > > -- > > > 2.18.2 > > > > > >