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@xxxxxxx> > Reviewed-by: Christoph Hellwig <hch@xxxxxx> 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@xxxxxx>
