Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Ritesh Harjani <riteshh@linux.ibm.com>
To:     linux-fsdevel@vger.kernel.org, linux-xfs@vger.kernel.org
Cc:     Alexander Viro <viro@zeniv.linux.org.uk>,
        "Darrick J . Wong" <darrick.wong@oracle.com>,
        Christoph Hellwig <hch@infradead.org>,
        Jan Kara <jack@suse.com>, tytso@mit.edu,
        "Aneesh Kumar K . V" <aneesh.kumar@linux.ibm.com>,
        linux-ext4@vger.kernel.org, Ritesh Harjani <riteshh@linux.ibm.com>
Subject: [PATCH 0/2] WARN fibmap user in case of possible addr truncation
Date:   Fri, 24 Apr 2020 12:52:16 +0530
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Message-Id: <cover.1587670914.git.riteshh@linux.ibm.com>
Sender: linux-ext4-owner@vger.kernel.org
Precedence: bulk

Currently an ioctl_fibmap() caller may get a truncated and wrong block map
address if the actual mapped physical block address is > INT_MAX.
If that is the case then lets:-
1. Add a warning,
2. Returns 0 in the block mapped address,
3. And also return -ERANGE error.
This is better than providing a wrong information to the user about the
block mapping which in the worst case could cause a FS corruption
(unknowingly by the caller since kernel didn't warn).
Currently these checks are in place only for the filesystems who uses iomap
based bmap interface. So let's do this right thing for all the fibmap()
callers by adding this logic in ioctl_fibmap() directly.

Patch-1 & Patch-2 commit msg may provide additional information.

Ritesh Harjani (2):
  fibmap: Warn and return an error in case of block > INT_MAX
  iomap: bmap: Remove the WARN and return the proper block address

 fs/ioctl.c        | 5 +++++
 fs/iomap/fiemap.c | 5 +----
 2 files changed, 6 insertions(+), 4 deletions(-)

-- 
2.21.0