[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200428074713.GA12180@infradead.org>
Date: Tue, 28 Apr 2020 00:47:13 -0700
From: Christoph Hellwig <hch@...radead.org>
To: Ritesh Harjani <riteshh@...ux.ibm.com>
Cc: linux-fsdevel@...r.kernel.org, linux-xfs@...r.kernel.org,
Alexander Viro <viro@...iv.linux.org.uk>,
"Darrick J . Wong" <darrick.wong@...cle.com>,
Christoph Hellwig <hch@...radead.org>,
Jan Kara <jack@...e.com>, tytso@....edu,
"Aneesh Kumar K . V" <aneesh.kumar@...ux.ibm.com>,
linux-ext4@...r.kernel.org, Jan Kara <jack@...e.cz>,
Christoph Hellwig <hch@....de>
Subject: Re: [PATCHv2] fibmap: Warn and return an error in case of block >
INT_MAX
On Tue, Apr 28, 2020 at 01:08:31PM +0530, Ritesh Harjani wrote:
> We better warn the fibmap user and not return a truncated and therefore
> an incorrect block map address if the bmap() returned block address
> is greater than INT_MAX (since user supplied integer pointer).
>
> It's better to pr_warn() all user of ioctl_fibmap() and return a proper
> error code rather than silently letting a FS corruption happen if the
> user tries to fiddle around with the returned block map address.
>
> We fix this by returning an error code of -ERANGE and returning 0 as the
> block mapping address in case if it is > INT_MAX.
>
> Now iomap_bmap() could be called from either of these two paths.
> Either when a user is calling an ioctl_fibmap() interface to get
> the block mapping address or by some filesystem via use of bmap()
> internal kernel API.
> bmap() kernel API is well equipped with handling of u64 addresses.
>
> WARN condition in iomap_bmap_actor() was mainly added to warn all
> the fibmap users. But now that we have directly added this warning
> for all fibmap users and also made sure to return 0 as block map address
> in case if addr > INT_MAX.
> So we can now remove this logic from iomap_bmap_actor().
>
> Reviewed-by: Jan Kara <jack@...e.cz>
> Reviewed-by: Christoph Hellwig <hch@....de>
Well, this changed quite a bit from the previous version, so I would
have dropped the Reviewed-by tags.
That being said this version still looks good to me:
Reviewed-by: Christoph Hellwig <hch@....de>
Powered by blists - more mailing lists