public inbox for linux-ext4@vger.kernel.org
 help / color / mirror / Atom feed
From: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
To: Baokun Li <libaokun1@huawei.com>, linux-ext4@vger.kernel.org
Cc: tytso@mit.edu, adilger.kernel@dilger.ca, jack@suse.cz,
	ojaswin@linux.ibm.com, linux-kernel@vger.kernel.org,
	yi.zhang@huawei.com, yangerkun@huawei.com, yukuai3@huawei.com,
	libaokun1@huawei.com
Subject: Re: [PATCH 1/4] ext4: add two helper functions fex_end() and pa_end()
Date: Thu, 20 Jul 2023 23:18:06 +0530	[thread overview]
Message-ID: <87bkg6o4o9.fsf@doe.com> (raw)
In-Reply-To: <20230718131052.283350-2-libaokun1@huawei.com>

Baokun Li <libaokun1@huawei.com> writes:

> When we use lstart + len to calculate the end of free extent or prealloc
> space, it may exceed the maximum value of 4294967295(0xffffffff) supported
> by ext4_lblk_t and cause overflow, which may lead to various problems.
>
> Therefore, we add two helper functions, fex_end() and pa_end(), to limit
> the type of end to loff_t, and also convert lstart to loff_t for
> calculation to avoid overflow.
>
> Signed-off-by: Baokun Li <libaokun1@huawei.com>
> ---
>  fs/ext4/mballoc.c |  4 ++--
>  fs/ext4/mballoc.h | 13 +++++++++++++
>  2 files changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c
> index 456150ef6111..eb7f5d35ef96 100644
> --- a/fs/ext4/mballoc.c
> +++ b/fs/ext4/mballoc.c
> @@ -4432,7 +4432,7 @@ ext4_mb_normalize_request(struct ext4_allocation_context *ac,
>  
>  	/* first, let's learn actual file size
>  	 * given current request is allocated */
> -	size = ac->ac_o_ex.fe_logical + EXT4_C2B(sbi, ac->ac_o_ex.fe_len);
> +	size = fex_end(sbi, &ac->ac_o_ex, NULL);
>  	size = size << bsbits;
>  	if (size < i_size_read(ac->ac_inode))
>  		size = i_size_read(ac->ac_inode);
> @@ -5665,7 +5665,7 @@ static void ext4_mb_group_or_file(struct ext4_allocation_context *ac)
>  
>  	group_pa_eligible = sbi->s_mb_group_prealloc > 0;
>  	inode_pa_eligible = true;
> -	size = ac->ac_o_ex.fe_logical + EXT4_C2B(sbi, ac->ac_o_ex.fe_len);
> +	size = fex_end(sbi, &ac->ac_o_ex, NULL);
>  	isize = (i_size_read(ac->ac_inode) + ac->ac_sb->s_blocksize - 1)
>  		>> bsbits;
>  
> diff --git a/fs/ext4/mballoc.h b/fs/ext4/mballoc.h
> index df6b5e7c2274..fe6bf381f30a 100644
> --- a/fs/ext4/mballoc.h
> +++ b/fs/ext4/mballoc.h
> @@ -233,6 +233,19 @@ static inline ext4_fsblk_t ext4_grp_offs_to_block(struct super_block *sb,
>  		(fex->fe_start << EXT4_SB(sb)->s_cluster_bits);
>  }
>  
> +static inline loff_t fex_end(struct ext4_sb_info *sbi,
> +			     struct ext4_free_extent *fex, ext4_grpblk_t *fe_len)
> +{
> +	return (loff_t)fex->fe_logical +
> +		EXT4_C2B(sbi, fe_len ? *fe_len : fex->fe_len);
> +}
> +
> +static inline loff_t pa_end(struct ext4_sb_info *sbi,
> +			    struct ext4_prealloc_space *pa)
> +{
> +	return (loff_t)pa->pa_lstart + EXT4_C2B(sbi, pa->pa_len);
> +}
> +

I didn't find anything else where we could hit any overflow due to
fex->fe_logical + xxx. 
So, looks good to me except these two helper functions.
I think we can directly just typecast those in place. There are many
other places in ext4 code where careful arithmatic of either adding or
bit shifting has been done. These helpers specially fex_end() is
really confusing.

-ritesh


  reply	other threads:[~2023-07-20 17:48 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-18 13:10 [PATCH 0/4] ext4: fix some ext4_lblk_t overflow issues Baokun Li
2023-07-18 13:10 ` [PATCH 1/4] ext4: add two helper functions fex_end() and pa_end() Baokun Li
2023-07-20 17:48   ` Ritesh Harjani [this message]
2023-07-18 13:10 ` [PATCH 2/4] ext4: fix BUG in ext4_mb_new_inode_pa() due to overflow Baokun Li
2023-07-20 12:44   ` Ritesh Harjani
2023-07-20 13:42     ` Baokun Li
2023-07-20 19:30       ` Ritesh Harjani
2023-07-21  7:29         ` Baokun Li
2023-07-21  8:24           ` Ritesh Harjani
2023-07-21  9:13             ` Baokun Li
2023-07-21 17:15               ` Theodore Ts'o
2023-07-22  3:16                 ` Baokun Li
2023-07-20 19:07   ` Ritesh Harjani
2023-07-21  8:01     ` Baokun Li
2023-07-18 13:10 ` [PATCH 3/4] ext4: avoid overlapping preallocations " Baokun Li
2023-07-20 19:24   ` Ritesh Harjani
2023-07-18 13:10 ` [PATCH 4/4] ext4: avoid prealloc space being skipped " Baokun Li
2023-07-20 19:22   ` Ritesh Harjani

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87bkg6o4o9.fsf@doe.com \
    --to=ritesh.list@gmail.com \
    --cc=adilger.kernel@dilger.ca \
    --cc=jack@suse.cz \
    --cc=libaokun1@huawei.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ojaswin@linux.ibm.com \
    --cc=tytso@mit.edu \
    --cc=yangerkun@huawei.com \
    --cc=yi.zhang@huawei.com \
    --cc=yukuai3@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox