linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
To: Yu Kuai <yukuai1@huaweicloud.com>
Cc: stable@vger.kernel.org, gregkh@linuxfoundation.org,
	harry.wentland@amd.com, sunpeng.li@amd.com,
	Rodrigo.Siqueira@amd.com, alexander.deucher@amd.com,
	christian.koenig@amd.com, Xinhui.Pan@amd.com, airlied@gmail.com,
	daniel@ffwll.ch, viro@zeniv.linux.org.uk, brauner@kernel.org,
	Liam.Howlett@oracle.com, akpm@linux-foundation.org,
	hughd@google.com, willy@infradead.org, sashal@kernel.org,
	srinivasan.shanmugam@amd.com, chiahsuan.chung@amd.com,
	mingo@kernel.org, mgorman@techsingularity.net,
	yukuai3@huawei.com, chengming.zhou@linux.dev,
	zhangpeng.00@bytedance.com, chuck.lever@oracle.com,
	amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	maple-tree@lists.infradead.org, linux-mm@kvack.org,
	yi.zhang@huawei.com, yangerkun@huawei.com
Subject: Re: [PATCH 6.6 28/28] maple_tree: correct tree corruption on spanning store
Date: Wed, 6 Nov 2024 15:02:12 +0000	[thread overview]
Message-ID: <7740a098-fe11-48f1-a693-df81ef769f08@lucifer.local> (raw)
In-Reply-To: <20241024132225.2271667-13-yukuai1@huaweicloud.com>

On Thu, Oct 24, 2024 at 09:22:25PM +0800, Yu Kuai wrote:

> diff --git a/lib/maple_tree.c b/lib/maple_tree.c
> index 5328e08723d7..c57b6fc4db2e 100644
> --- a/lib/maple_tree.c
> +++ b/lib/maple_tree.c
> @@ -2239,6 +2239,8 @@ static inline void mas_node_or_none(struct ma_state *mas,
>
>  /*
>   * mas_wr_node_walk() - Find the correct offset for the index in the @mas.
> + *                      If @mas->index cannot be found within the containing
> + *                      node, we traverse to the last entry in the node.
>   * @wr_mas: The maple write state
>   *
>   * Uses mas_slot_locked() and does not need to worry about dead nodes.
> @@ -3655,7 +3657,7 @@ static bool mas_wr_walk(struct ma_wr_state *wr_mas)
>  	return true;
>  }
>
> -static bool mas_wr_walk_index(struct ma_wr_state *wr_mas)
> +static void mas_wr_walk_index(struct ma_wr_state *wr_mas)
>  {
>  	struct ma_state *mas = wr_mas->mas;
>
> @@ -3664,11 +3666,9 @@ static bool mas_wr_walk_index(struct ma_wr_state *wr_mas)
>  		wr_mas->content = mas_slot_locked(mas, wr_mas->slots,
>  						  mas->offset);
>  		if (ma_is_leaf(wr_mas->type))
> -			return true;
> +			return;
>  		mas_wr_walk_traverse(wr_mas);
> -
>  	}
> -	return true;
>  }
>  /*
>   * mas_extend_spanning_null() - Extend a store of a %NULL to include surrounding %NULLs.
> @@ -3899,8 +3899,8 @@ static inline int mas_wr_spanning_store(struct ma_wr_state *wr_mas)
>  	memset(&b_node, 0, sizeof(struct maple_big_node));
>  	/* Copy l_mas and store the value in b_node. */
>  	mas_store_b_node(&l_wr_mas, &b_node, l_mas.end);
> -	/* Copy r_mas into b_node. */
> -	if (r_mas.offset <= r_mas.end)
> +	/* Copy r_mas into b_node if there is anything to copy. */
> +	if (r_mas.max > r_mas.last)
>  		mas_mab_cp(&r_mas, r_mas.offset, r_mas.end,
>  			   &b_node, b_node.b_end + 1);
>  	else
> --
> 2.39.2
>

This is a good example of where you've gone horribly wrong, this relies on
31c532a8af57 ("maple_tree: add end of node tracking to the maple state") which
is not in 6.6.

You reverted (!!) my backported patch for this that _does not require this_
only to pull in 31c532a8af57 in order to apply the upstream version of my
fix over that.

This is totally unnecessary and I can't see why _on earth_ you would need
31c532a8af57.

You need to correctly identify what patches need to be backported and _fix
merge conflicts_ accordingly, like I did with the patch that you decided to
revert.

In the kernel it is absolutely unacceptable to arbitrarily backport huge
amounts of patches you don't understand in order to avoid merge conflicts,
you may be breaking all kinds of things without realising.

You have to find the _minimal_ change and _fix merge conflicts_.

Stable is not a playground, it's what millions (billions?) of kernels rely
upon.

In any case, I think Liam's reply suggests that we should be looking at
maybe 1 thing to backport? If we even need to?

Please in future be more cautious, and if you are unsure how to proceed,
cc- the relevant maintainers (+ all authors of patches you intend to
backport/revert) in an RFC. Thanks.


  reply	other threads:[~2024-11-06 15:03 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-24 13:19 [PATCH 6.6 00/28] fix CVE-2024-46701 Yu Kuai
2024-10-24 13:19 ` [PATCH 6.6 01/28] maple_tree: add mt_free_one() and mt_attr() helpers Yu Kuai
2024-10-24 13:19 ` [PATCH 6.6 02/28] maple_tree: introduce {mtree,mas}_lock_nested() Yu Kuai
2024-10-24 13:19 ` [PATCH 6.6 03/28] maple_tree: introduce interfaces __mt_dup() and mtree_dup() Yu Kuai
2024-10-24 13:19 ` [PATCH 6.6 04/28] maple_tree: skip other tests when BENCH is enabled Yu Kuai
2024-10-24 13:19 ` [PATCH 6.6 05/28] maple_tree: preserve the tree attributes when destroying maple tree Yu Kuai
2024-10-24 13:19 ` [PATCH 6.6 06/28] maple_tree: remove unnecessary default labels from switch statements Yu Kuai
2024-10-24 13:19 ` [PATCH 6.6 07/28] maple_tree: make mas_erase() more robust Yu Kuai
2024-10-24 13:19 ` [PATCH 6.6 08/28] maple_tree: move debug check to __mas_set_range() Yu Kuai
2024-10-24 13:19 ` [PATCH 6.6 09/28] maple_tree: add end of node tracking to the maple state Yu Kuai
2024-10-24 13:19 ` [PATCH 6.6 10/28] maple_tree: use cached node end in mas_next() Yu Kuai
2024-10-24 13:19 ` [PATCH 6.6 11/28] maple_tree: use cached node end in mas_destroy() Yu Kuai
2024-10-24 13:19 ` [PATCH 6.6 12/28] maple_tree: clean up inlines for some functions Yu Kuai
2024-10-24 13:19 ` [PATCH 6.6 13/28] maple_tree: add test for mtree_dup() Yu Kuai
2024-10-24 13:19 ` [PATCH 6.6 14/28] maple_tree: separate ma_state node from status Yu Kuai
2024-10-24 13:19 ` [PATCH 6.6 15/28] maple_tree: remove mas_searchable() Yu Kuai
2024-10-24 13:22 ` [PATCH 6.6 16/28] Revert "maple_tree: correct tree corruption on spanning store" Yu Kuai
2024-10-24 13:22   ` [PATCH 6.6 17/28] maple_tree: use maple state end for write operations Yu Kuai
2024-10-24 13:22   ` [PATCH 6.6 18/28] maple_tree: don't find node end in mtree_lookup_walk() Yu Kuai
2024-10-24 13:22   ` [PATCH 6.6 19/28] maple_tree: mtree_range_walk() clean up Yu Kuai
2024-10-24 13:22   ` [PATCH 6.6 20/28] lib/maple_tree.c: fix build error due to hotfix alteration Yu Kuai
2024-10-24 13:22   ` [PATCH 6.6 21/28] maple_tree: avoid checking other gaps after getting the largest gap Yu Kuai
2024-10-24 13:22   ` [PATCH 6.6 22/28] libfs: Re-arrange locking in offset_iterate_dir() Yu Kuai
2024-10-24 13:22   ` [PATCH 6.6 23/28] libfs: Define a minimum directory offset Yu Kuai
2024-10-24 13:22   ` [PATCH 6.6 24/28] libfs: Add simple_offset_empty() Yu Kuai
2024-10-24 13:22   ` [PATCH 6.6 25/28] maple_tree: Add mtree_alloc_cyclic() Yu Kuai
2024-10-24 13:22   ` [PATCH 6.6 26/28] libfs: Convert simple directory offsets to use a Maple Tree Yu Kuai
2024-10-24 13:22   ` [PATCH 6.6 27/28] libfs: fix infinite directory reads for offset dir Yu Kuai
2024-10-24 13:22   ` [PATCH 6.6 28/28] maple_tree: correct tree corruption on spanning store Yu Kuai
2024-11-06 15:02     ` Lorenzo Stoakes [this message]
2024-11-07  1:22       ` Yu Kuai
2024-11-06  6:16 ` [PATCH 6.6 00/28] fix CVE-2024-46701 Greg KH
2024-11-06 14:44   ` Liam R. Howlett
2024-11-06 15:19   ` Chuck Lever III
2024-11-06 16:21     ` James Bottomley
2024-11-07  0:57     ` Yu Kuai
2024-11-07 14:41       ` Chuck Lever
2024-11-08  1:19         ` Yu Kuai
2024-11-08 13:23           ` Chuck Lever III
2024-11-08 17:03             ` Liam R. Howlett
2024-11-09  1:38               ` Yu Kuai
2024-11-09  1:30             ` Yu Kuai
2024-11-09 16:58               ` Chuck Lever III
2024-11-11  0:56                 ` Yu Kuai
2024-11-07 14:44       ` Liam R. Howlett
2024-11-06 14:43 ` Lorenzo Stoakes
2024-11-07  1:43   ` Yu Kuai

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=7740a098-fe11-48f1-a693-df81ef769f08@lucifer.local \
    --to=lorenzo.stoakes@oracle.com \
    --cc=Liam.Howlett@oracle.com \
    --cc=Rodrigo.Siqueira@amd.com \
    --cc=Xinhui.Pan@amd.com \
    --cc=airlied@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=alexander.deucher@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=brauner@kernel.org \
    --cc=chengming.zhou@linux.dev \
    --cc=chiahsuan.chung@amd.com \
    --cc=christian.koenig@amd.com \
    --cc=chuck.lever@oracle.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=harry.wentland@amd.com \
    --cc=hughd@google.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=maple-tree@lists.infradead.org \
    --cc=mgorman@techsingularity.net \
    --cc=mingo@kernel.org \
    --cc=sashal@kernel.org \
    --cc=srinivasan.shanmugam@amd.com \
    --cc=stable@vger.kernel.org \
    --cc=sunpeng.li@amd.com \
    --cc=viro@zeniv.linux.org.uk \
    --cc=willy@infradead.org \
    --cc=yangerkun@huawei.com \
    --cc=yi.zhang@huawei.com \
    --cc=yukuai1@huaweicloud.com \
    --cc=yukuai3@huawei.com \
    --cc=zhangpeng.00@bytedance.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