FAILED: patch "[PATCH] ext4: fix off by one issue in" failed to apply to 6.4-stable tree

FAILED: patch "[PATCH] ext4: fix off by one issue in" failed to apply to 6.4-stable tree

[gregkh]

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@vger.kernel.org>.

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@vger.kernel.org>' --in-reply-to '2023072456-starting-gauging-768c@gregkh' --subject-prefix 'PATCH 6.4.y' HEAD^..

Possible dependencies:



thanks,

greg k-h

------------------ original commit in Linus's tree ------------------

From 5d5460fa7932bed3a9082a6a8852cfbdb46acbe8 Mon Sep 17 00:00:00 2001
From: Ojaswin Mujoo <ojaswin@linux.ibm.com>
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@kernel.org
Fixes: 33122aa930 ("ext4: Add allocation criteria 1.5 (CR1_5)")
Signed-off-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
Link: https://lore.kernel.org/r/20230609103403.112807-1-ojaswin@linux.ibm.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>

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;
 		/*

Re: FAILED: patch "[PATCH] ext4: fix off by one issue in" failed to apply to 6.4-stable tree

[Ojaswin Mujoo]

On Mon, Jul 24, 2023 at 08:17:57AM +0200, gregkh@linuxfoundation.org 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@vger.kernel.org>.
> 
> 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@vger.kernel.org>' --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@linux.ibm.com>
> 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@kernel.org
> Fixes: 33122aa930 ("ext4: Add allocation criteria 1.5 (CR1_5)")
> Signed-off-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
> Link: https://lore.kernel.org/r/20230609103403.112807-1-ojaswin@linux.ibm.com
> Signed-off-by: Theodore Ts'o <tytso@mit.edu>
> 
> 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;
>  		/*
> 

Re: FAILED: patch "[PATCH] ext4: fix off by one issue in" failed to apply to 6.4-stable tree

[Greg KH]

On Tue, Aug 22, 2023 at 02:46:38PM +0530, Ojaswin Mujoo wrote:
> On Mon, Jul 24, 2023 at 08:17:57AM +0200, gregkh@linuxfoundation.org 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@vger.kernel.org>.
> > 
> > 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@vger.kernel.org>' --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?

The fixes tag in this commit:
	> > Fixes: 33122aa930 ("ext4: Add allocation criteria 1.5 (CR1_5)")

References a commit id that is not in Linus's tree, so I have to guess.

Please use valid git ids in your Fixes: line and this will not happen in
the future.

thanks,

greg k-h