linux-kernel - Re: [PATCH v2 2/2] ext4: Convert EXT4_B2C(sbi->s_stripe) users to EXT4_NUM

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZtFSTBf3uCVMd1v/@li-bb2b2a4c-3307-11b2-a85c-8fa5c3a69313.ibm.com>
Date: Fri, 30 Aug 2024 10:32:04 +0530
From: Ojaswin Mujoo <ojaswin@...ux.ibm.com>
To: Ritesh Harjani <ritesh.list@...il.com>
Cc: linux-ext4@...r.kernel.org, "Theodore Ts'o" <tytso@....edu>,
        linux-kernel@...r.kernel.org, Kemeng Shi <shikemeng@...weicloud.com>
Subject: Re: [PATCH v2 2/2] ext4: Convert EXT4_B2C(sbi->s_stripe) users to
 EXT4_NUM_B2C

On Wed, Aug 28, 2024 at 02:58:13PM +0530, Ritesh Harjani wrote:
> Ojaswin Mujoo <ojaswin@...ux.ibm.com> writes:
> 
> > Although we have checks to make sure s_stripe is a multiple of cluster
> > size, in case we accidentally end up with a scenario where this is not
> > the case, use EXT4_NUM_B2C() so that we don't end up with unexpected
> > cases where EXT4_B2C(stripe) becomes 0.
> 
> man page of strip=n mount options says...
>        stripe=n
>               Number of file system blocks that mballoc will try to use
>               for allocation size and alignment. For RAID5/6 systems
>               this should be the number of data disks * RAID chunk size
>               in file system blocks.
> 
> ... So stripe is anyways the no. of filesystem blocks. Making it
> EXT4_NUM_B2C() make sense to me.
> 
> However, there is one more user that remains in ext4_mb_find_by_goal(),
> right?

Oh right, I'll fix that in v3. Thanks! 

> 
> -ritesh
> 
> >
> > Also make the is_stripe_aligned check in regular_allocator a bit more
> > robust while we are at it. This should ideally have no functional change
> > unless we have a bug somewhere causing (stripe % cluster_size != 0)
> >
> > Signed-off-by: Ojaswin Mujoo <ojaswin@...ux.ibm.com>
> > ---
> >  fs/ext4/mballoc.c | 10 ++++++----
> >  1 file changed, 6 insertions(+), 4 deletions(-)