From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-f68.google.com ([209.85.128.68]:54804 "EHLO mail-wm1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727663AbfEZGL3 (ORCPT ); Sun, 26 May 2019 02:11:29 -0400 From: Amir Goldstein Subject: [PATCH v2 8/8] vfs: remove redundant checks from generic_remap_checks() Date: Sun, 26 May 2019 09:10:59 +0300 Message-Id: <20190526061100.21761-9-amir73il@gmail.com> In-Reply-To: <20190526061100.21761-1-amir73il@gmail.com> References: <20190526061100.21761-1-amir73il@gmail.com> Sender: linux-xfs-owner@vger.kernel.org List-ID: List-Id: xfs To: "Darrick J . Wong" Cc: Dave Chinner , Christoph Hellwig , Olga Kornievskaia , Luis Henriques , Al Viro , linux-fsdevel@vger.kernel.org, linux-xfs@vger.kernel.org, linux-nfs@vger.kernel.org, linux-cifs@vger.kernel.org, ceph-devel@vger.kernel.org, linux-api@vger.kernel.org The access limit checks on input file range in generic_remap_checks() are redundant because the input file size is guarantied to be within limits and pos+len are already checked to be within input file size. Beyond the fact that the check cannot fail, if it would have failed, it could return -EFBIG for input file range error. There is no precedent for that. -EFBIG is returned in syscalls that would change file length. Signed-off-by: Amir Goldstein --- mm/filemap.c | 4 ---- 1 file changed, 4 deletions(-) diff --git a/mm/filemap.c b/mm/filemap.c index 1852fbf08eeb..7e1aa36d57a2 100644 --- a/mm/filemap.c +++ b/mm/filemap.c @@ -3000,10 +3000,6 @@ int generic_remap_checks(struct file *file_in, loff_t pos_in, return -EINVAL; count = min(count, size_in - (uint64_t)pos_in); - ret = generic_access_check_limits(file_in, pos_in, &count); - if (ret) - return ret; - ret = generic_write_check_limits(file_out, pos_out, &count); if (ret) return ret; -- 2.17.1