[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <25la4rfgyog2dq5ldjo2pghy4ezjp4dy35pfvgp2hbwv7zrcss@sq2i5sadk3xh>
Date: Fri, 6 Feb 2026 17:05:20 +0100
From: Jan Kara <jack@...e.cz>
To: Adarsh Das <adarshdas950@...il.com>
Cc: jack@...e.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] fs: udf: avoid assignment in condition when selecting
allocation goal
On Fri 06-02-26 18:26:38, Adarsh Das wrote:
> Avoid assignment inside an if condition when choosing the block
> allocation goal in inode_getblk(), and make the priority order
> explicit. No functional change.
>
> Signed-off-by: Adarsh Das <adarshdas950@...il.com>
> ---
> fs/udf/inode.c | 11 +++++------
> 1 file changed, 5 insertions(+), 6 deletions(-)
Thanks for the cleanup. I agree it is desirable. But:
> @@ -893,11 +893,10 @@ static int inode_getblk(struct inode *inode, struct udf_map_rq *map)
> else { /* otherwise, allocate a new block */
> if (iinfo->i_next_alloc_block == map->lblk)
> goal = iinfo->i_next_alloc_goal;
> -
> - if (!goal) {
> - if (!(goal = pgoal)) /* XXX: what was intended here? */
> - goal = iinfo->i_location.logicalBlockNum + 1;
> - }
> + else if (pgoal)
I don't think the 'else' here is correct. When map->lblk is zero, it can
happen that i_next_alloc_goal will be 0 as well. Previously we've used
iinfo->i_location.logicalBlockNum + 1 for such cases but now we would leave
0 in 'goal'. Anyway, I'll fix this up on commit so this is just
informational.
Honza
> + goal = pgoal;
> + else
> + goal = iinfo->i_location.logicalBlockNum + 1;
>
> newblocknum = udf_new_block(inode->i_sb, inode,
> iinfo->i_location.partitionReferenceNum,
> --
> 2.53.0
>
--
Jan Kara <jack@...e.com>
SUSE Labs, CR
Powered by blists - more mailing lists