Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp604692pxj; Thu, 20 May 2021 17:36:53 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx58N6LUzdIeY/DNzSortTovq7aHOP7ri5Qjo5nym3z9/xnRq8Te6LlLqivbN5neq7Kcmgr X-Received: by 2002:a5d:94ce:: with SMTP id y14mr8629084ior.67.1621557413307; Thu, 20 May 2021 17:36:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1621557413; cv=none; d=google.com; s=arc-20160816; b=iJRPS/ZTtFVEkV8v0pEQCmg/dVeX34ESFWEjiSowdTUCFboNrEZKXGsQ/7Kf7SeZ2m P9D47sSMnDiPzR+pu/f2yAybcQaFNL0NRHpO04kMN47Ht+vXqrWiUDU+P2fZfeyYAjXq 8okEin7PQwlZljSGYZZfix/V0oog2rmGr4UwyAdHa8Ibn62SHSFfJgb5mxKdHkRF7McQ uQeaSdvcWd4F/zUD7X7mMwTSEJF2WGBdTxkwQ9kPRQR4aoQYGr7UklyRdtUiefQDuj7a PTLegnAWYhg+QWA2pNWN5D7hdI1+Ljq/Oh8MKg1T3toFzmR6MY9lWjt66WdDlu7POIMo tbvg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=CRe5GCTpwcI2jZCYRwMsVB4JqWnOpztUst8Wcss2kGU=; b=fzi53PyYfYhLfXU6HRZ/mwFohBGgPPhQYvgEZyAQEnBAyt6p8FVRZ4QmwEkVgTnJLL sWrCVKbGyZBrM3IzPG88owM+SuPFfPKr6ehSYKc8tH8e43I/YRxj9DAFcOWPT3p+uW8J x4P4UQ+PLIvWYsfh0lXyW/A/UPa1w4lbdwcSFbCdpojYo1FKMSP6odKOvAHZIxKwEkwb ba817QbmkCxucoduPkP0uGLx3sfHKqdZg5HytQHV2HC+mSlvh9Byx8a02PC6g/yZkmdT cvWHVxx7fCkFucwngF//YExS90HGg6+eU999K+MPncLFUdR29tLHd5QizL2hTK5YRYE3 AoaA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=Q4VcoZ9X; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id s18si2861133ilp.146.2021.05.20.17.36.15; Thu, 20 May 2021 17:36:53 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=Q4VcoZ9X; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240421AbhETLWw (ORCPT + 99 others); Thu, 20 May 2021 07:22:52 -0400 Received: from mail.kernel.org ([198.145.29.99]:57322 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239090AbhETLCK (ORCPT ); Thu, 20 May 2021 07:02:10 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 713E96142F; Thu, 20 May 2021 10:04:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1621505044; bh=YQZY9+XmeIwini8Qsv6Kxgjjrli83jL9m/mbdQ8qRIc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Q4VcoZ9XSiFvHPDU7/ynIsAyhBvU+UBsAhLk/F4n8Q3vLia8gT88t1nWE+QWlCczF jJhyfHiQtv1HCOyTLuINI8ZmBn1ULnKNXaMvyU/mn0NrN9uvw8WBzDM9Qq+8P1U2uq bPaQdylbVEnoEFlHf3KeHqouLasN/TlLyfn7DGhA= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Olga Kornievskaia , Trond Myklebust , Sasha Levin Subject: [PATCH 4.9 198/240] NFSv4.2 fix handling of sr_eof in SEEKs reply Date: Thu, 20 May 2021 11:23:10 +0200 Message-Id: <20210520092115.303308078@linuxfoundation.org> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20210520092108.587553970@linuxfoundation.org> References: <20210520092108.587553970@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Olga Kornievskaia [ Upstream commit 73f5c88f521a630ea1628beb9c2d48a2e777a419 ] Currently the client ignores the value of the sr_eof of the SEEK operation. According to the spec, if the server didn't find the requested extent and reached the end of the file, the server would return sr_eof=true. In case the request for DATA and no data was found (ie in the middle of the hole), then the lseek expects that ENXIO would be returned. Fixes: 1c6dcbe5ceff8 ("NFS: Implement SEEK") Signed-off-by: Olga Kornievskaia Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin --- fs/nfs/nfs42proc.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/fs/nfs/nfs42proc.c b/fs/nfs/nfs42proc.c index 7e9fb1119bcf..7efb9e0e9f25 100644 --- a/fs/nfs/nfs42proc.c +++ b/fs/nfs/nfs42proc.c @@ -294,7 +294,10 @@ static loff_t _nfs42_proc_llseek(struct file *filep, if (status) return status; - return vfs_setpos(filep, res.sr_offset, inode->i_sb->s_maxbytes); + if (whence == SEEK_DATA && res.sr_eof) + return -NFS4ERR_NXIO; + else + return vfs_setpos(filep, res.sr_offset, inode->i_sb->s_maxbytes); } loff_t nfs42_proc_llseek(struct file *filep, loff_t offset, int whence) -- 2.30.2