On Mon, Jul 24, 2023 at 08:17:57AM +0200, gregkh@xxxxxxxxxxxxxxxxxxx wrote: > > The patch below does not apply to the 6.4-stable tree. > If someone wants it applied there, or to any other stable or longterm > tree, then please email the backport, including the original git commit > id to <stable@xxxxxxxxxxxxxxx>. > > To reproduce the conflict and resubmit, you may use the following commands: > > git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.4.y > git checkout FETCH_HEAD > git cherry-pick -x 5d5460fa7932bed3a9082a6a8852cfbdb46acbe8 > # <resolve conflicts, build, test, etc.> > git commit -s > git send-email --to '<stable@xxxxxxxxxxxxxxx>' --in-reply-to '2023072456-starting-gauging-768c@gregkh' --subject-prefix 'PATCH 6.4.y' HEAD^.. > > Possible dependencies: > > > > thanks, > > greg k-h Hi Greg, Ted, Sorry for being late on this, I was off for a good part of this month. So i got multiple such FAILUREs from different stable trees for this particular patch (linked at end), but seems like these trees don't even have the patch pointed by Fixes tag. Although we can safely ignore backporting this, I just wanted to check why did I get these false failures so I can avoid it in the future. I was thinking that we would automatically check the fixes tag to see which trees need the backport? Is that not the case? Other similar failures on older stable trees: https://lore.kernel.org/stable/?q=s%3AFAILED+AND+s%3A%22ext4%3A+fix+off+by+one%22+AND+t%3Aojaswin Regards, ojaswin > > ------------------ original commit in Linus's tree ------------------ > > From 5d5460fa7932bed3a9082a6a8852cfbdb46acbe8 Mon Sep 17 00:00:00 2001 > From: Ojaswin Mujoo <ojaswin@xxxxxxxxxxxxx> > Date: Fri, 9 Jun 2023 16:04:03 +0530 > Subject: [PATCH] ext4: fix off by one issue in > ext4_mb_choose_next_group_best_avail() > > In ext4_mb_choose_next_group_best_avail(), we want the start order to be > 1 less than goal length and the min_order to be, at max, 1 more than the > original length. This commit fixes an off by one issue that arose due to > the fact that 1 << fls(n) > (n). > > After all the processing: > > order = 1 order below goal len > min_order = maximum of the three:- > - order - trim_order > - 1 order below B2C(s_stripe) > - 1 order above original len > > Cc: stable@xxxxxxxxxx > Fixes: 33122aa930 ("ext4: Add allocation criteria 1.5 (CR1_5)") > Signed-off-by: Ojaswin Mujoo <ojaswin@xxxxxxxxxxxxx> > Link: https://lore.kernel.org/r/20230609103403.112807-1-ojaswin@xxxxxxxxxxxxx > Signed-off-by: Theodore Ts'o <tytso@xxxxxxx> > > diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c > index a2475b8c9fb5..456150ef6111 100644 > --- a/fs/ext4/mballoc.c > +++ b/fs/ext4/mballoc.c > @@ -1006,14 +1006,11 @@ static void ext4_mb_choose_next_group_best_avail(struct ext4_allocation_context > * fls() instead since we need to know the actual length while modifying > * goal length. > */ > - order = fls(ac->ac_g_ex.fe_len); > + order = fls(ac->ac_g_ex.fe_len) - 1; > min_order = order - sbi->s_mb_best_avail_max_trim_order; > if (min_order < 0) > min_order = 0; > > - if (1 << min_order < ac->ac_o_ex.fe_len) > - min_order = fls(ac->ac_o_ex.fe_len) + 1; > - > if (sbi->s_stripe > 0) { > /* > * We are assuming that stripe size is always a multiple of > @@ -1021,9 +1018,16 @@ static void ext4_mb_choose_next_group_best_avail(struct ext4_allocation_context > */ > num_stripe_clusters = EXT4_NUM_B2C(sbi, sbi->s_stripe); > if (1 << min_order < num_stripe_clusters) > - min_order = fls(num_stripe_clusters); > + /* > + * We consider 1 order less because later we round > + * up the goal len to num_stripe_clusters > + */ > + min_order = fls(num_stripe_clusters) - 1; > } > > + if (1 << min_order < ac->ac_o_ex.fe_len) > + min_order = fls(ac->ac_o_ex.fe_len); > + > for (i = order; i >= min_order; i--) { > int frag_order; > /* >
