On Tue, Mar 01, 2022 at 04:09:31PM +0530, Chandan Babu R wrote:
> Reported-by: kernel test robot <lkp@xxxxxxxxx>
What was reported by the robot? I don't quite see the relevance of
this change to the overall patchset just from the change being made.
> Reviewed-by: Darrick J. Wong <djwong@xxxxxxxxxx>
> Signed-off-by: Chandan Babu R <chandan.babu@xxxxxxxxxx>
> ---
> fs/xfs/libxfs/xfs_bmap.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/fs/xfs/libxfs/xfs_bmap.c b/fs/xfs/libxfs/xfs_bmap.c
> index 9df98339a43a..a01d9a9225ae 100644
> --- a/fs/xfs/libxfs/xfs_bmap.c
> +++ b/fs/xfs/libxfs/xfs_bmap.c
> @@ -53,8 +53,8 @@ xfs_bmap_compute_maxlevels(
> int whichfork) /* data or attr fork */
> {
> xfs_extnum_t maxleafents; /* max leaf entries possible */
> + xfs_rfsblock_t maxblocks; /* max blocks at this level */
typedef uint64_t xfs_rfsblock_t; /* blockno in filesystem (raw) */
Usage of the type doesn't seem to match it's definition. This
function is calculating a block count, not a block number. If you
must use a xfs type, then:
typedef uint64_t xfs_filblks_t; /* number of blocks in a file */
is a better match, but I think this should just use uint64_t because
the count has nothing to do with block addresses or files..
Cheers,
Dave.
--
Dave Chinner
david@xxxxxxxxxxxxx
