* [merged mm-hotfixes-stable] maple_tree-add-rcu-lock-checking-to-rcu-callback-functions.patch removed from -mm tree
From: Andrew Morton @ 2023-04-06 1:06 UTC (permalink / raw)
To: mm-commits, surenb, stable, Liam.Howlett, akpm
The quilt patch titled
Subject: maple_tree: add RCU lock checking to rcu callback functions
has been removed from the -mm tree. Its filename was
maple_tree-add-rcu-lock-checking-to-rcu-callback-functions.patch
This patch was dropped because it was merged into the mm-hotfixes-stable branch
of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
------------------------------------------------------
From: "Liam R. Howlett" <Liam.Howlett@oracle.com>
Subject: maple_tree: add RCU lock checking to rcu callback functions
Date: Mon, 27 Feb 2023 09:36:06 -0800
Dereferencing RCU objects within the RCU callback without the RCU check
has caused lockdep to complain. Fix the RCU dereferencing by using the
RCU callback lock to ensure the operation is safe.
Also stop creating a new lock to use for dereferencing during destruction
of the tree or subtree. Instead, pass through a pointer to the tree that
has the lock that is held for RCU dereferencing checking. It also does
not make sense to use the maple state in the freeing scenario as the tree
walk is a special case where the tree no longer has the normal encodings
and parent pointers.
Link: https://lkml.kernel.org/r/20230227173632.3292573-8-surenb@google.com
Fixes: 54a611b60590 ("Maple Tree: add new data structure")
Signed-off-by: Liam R. Howlett <Liam.Howlett@oracle.com>
Reported-by: Suren Baghdasaryan <surenb@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
lib/maple_tree.c | 188 ++++++++++++++++++++++-----------------------
1 file changed, 96 insertions(+), 92 deletions(-)
--- a/lib/maple_tree.c~maple_tree-add-rcu-lock-checking-to-rcu-callback-functions
+++ a/lib/maple_tree.c
@@ -824,6 +824,11 @@ static inline void *mt_slot(const struct
return rcu_dereference_check(slots[offset], mt_locked(mt));
}
+static inline void *mt_slot_locked(struct maple_tree *mt, void __rcu **slots,
+ unsigned char offset)
+{
+ return rcu_dereference_protected(slots[offset], mt_locked(mt));
+}
/*
* mas_slot_locked() - Get the slot value when holding the maple tree lock.
* @mas: The maple state
@@ -835,7 +840,7 @@ static inline void *mt_slot(const struct
static inline void *mas_slot_locked(struct ma_state *mas, void __rcu **slots,
unsigned char offset)
{
- return rcu_dereference_protected(slots[offset], mt_locked(mas->tree));
+ return mt_slot_locked(mas->tree, slots, offset);
}
/*
@@ -907,34 +912,35 @@ static inline void ma_set_meta(struct ma
}
/*
- * mas_clear_meta() - clear the metadata information of a node, if it exists
- * @mas: The maple state
+ * mt_clear_meta() - clear the metadata information of a node, if it exists
+ * @mt: The maple tree
* @mn: The maple node
- * @mt: The maple node type
+ * @type: The maple node type
* @offset: The offset of the highest sub-gap in this node.
* @end: The end of the data in this node.
*/
-static inline void mas_clear_meta(struct ma_state *mas, struct maple_node *mn,
- enum maple_type mt)
+static inline void mt_clear_meta(struct maple_tree *mt, struct maple_node *mn,
+ enum maple_type type)
{
struct maple_metadata *meta;
unsigned long *pivots;
void __rcu **slots;
void *next;
- switch (mt) {
+ switch (type) {
case maple_range_64:
pivots = mn->mr64.pivot;
if (unlikely(pivots[MAPLE_RANGE64_SLOTS - 2])) {
slots = mn->mr64.slot;
- next = mas_slot_locked(mas, slots,
- MAPLE_RANGE64_SLOTS - 1);
- if (unlikely((mte_to_node(next) && mte_node_type(next))))
- return; /* The last slot is a node, no metadata */
+ next = mt_slot_locked(mt, slots,
+ MAPLE_RANGE64_SLOTS - 1);
+ if (unlikely((mte_to_node(next) &&
+ mte_node_type(next))))
+ return; /* no metadata, could be node */
}
fallthrough;
case maple_arange_64:
- meta = ma_meta(mn, mt);
+ meta = ma_meta(mn, type);
break;
default:
return;
@@ -5483,7 +5489,7 @@ no_gap:
}
/*
- * mas_dead_leaves() - Mark all leaves of a node as dead.
+ * mte_dead_leaves() - Mark all leaves of a node as dead.
* @mas: The maple state
* @slots: Pointer to the slot array
* @type: The maple node type
@@ -5493,16 +5499,16 @@ no_gap:
* Return: The number of leaves marked as dead.
*/
static inline
-unsigned char mas_dead_leaves(struct ma_state *mas, void __rcu **slots,
- enum maple_type mt)
+unsigned char mte_dead_leaves(struct maple_enode *enode, struct maple_tree *mt,
+ void __rcu **slots)
{
struct maple_node *node;
enum maple_type type;
void *entry;
int offset;
- for (offset = 0; offset < mt_slots[mt]; offset++) {
- entry = mas_slot_locked(mas, slots, offset);
+ for (offset = 0; offset < mt_slot_count(enode); offset++) {
+ entry = mt_slot(mt, slots, offset);
type = mte_node_type(entry);
node = mte_to_node(entry);
/* Use both node and type to catch LE & BE metadata */
@@ -5517,162 +5523,160 @@ unsigned char mas_dead_leaves(struct ma_
return offset;
}
-static void __rcu **mas_dead_walk(struct ma_state *mas, unsigned char offset)
+/**
+ * mte_dead_walk() - Walk down a dead tree to just before the leaves
+ * @enode: The maple encoded node
+ * @offset: The starting offset
+ *
+ * Note: This can only be used from the RCU callback context.
+ */
+static void __rcu **mte_dead_walk(struct maple_enode **enode, unsigned char offset)
{
- struct maple_node *next;
+ struct maple_node *node, *next;
void __rcu **slots = NULL;
- next = mas_mn(mas);
+ next = mte_to_node(*enode);
do {
- mas->node = mt_mk_node(next, next->type);
- slots = ma_slots(next, next->type);
- next = mas_slot_locked(mas, slots, offset);
+ *enode = ma_enode_ptr(next);
+ node = mte_to_node(*enode);
+ slots = ma_slots(node, node->type);
+ next = rcu_dereference_protected(slots[offset],
+ lock_is_held(&rcu_callback_map));
offset = 0;
} while (!ma_is_leaf(next->type));
return slots;
}
+/**
+ * mt_free_walk() - Walk & free a tree in the RCU callback context
+ * @head: The RCU head that's within the node.
+ *
+ * Note: This can only be used from the RCU callback context.
+ */
static void mt_free_walk(struct rcu_head *head)
{
void __rcu **slots;
struct maple_node *node, *start;
- struct maple_tree mt;
+ struct maple_enode *enode;
unsigned char offset;
enum maple_type type;
- MA_STATE(mas, &mt, 0, 0);
node = container_of(head, struct maple_node, rcu);
if (ma_is_leaf(node->type))
goto free_leaf;
- mt_init_flags(&mt, node->ma_flags);
- mas_lock(&mas);
start = node;
- mas.node = mt_mk_node(node, node->type);
- slots = mas_dead_walk(&mas, 0);
- node = mas_mn(&mas);
+ enode = mt_mk_node(node, node->type);
+ slots = mte_dead_walk(&enode, 0);
+ node = mte_to_node(enode);
do {
mt_free_bulk(node->slot_len, slots);
offset = node->parent_slot + 1;
- mas.node = node->piv_parent;
- if (mas_mn(&mas) == node)
- goto start_slots_free;
-
- type = mte_node_type(mas.node);
- slots = ma_slots(mte_to_node(mas.node), type);
- if ((offset < mt_slots[type]) && (slots[offset]))
- slots = mas_dead_walk(&mas, offset);
-
- node = mas_mn(&mas);
+ enode = node->piv_parent;
+ if (mte_to_node(enode) == node)
+ goto free_leaf;
+
+ type = mte_node_type(enode);
+ slots = ma_slots(mte_to_node(enode), type);
+ if ((offset < mt_slots[type]) &&
+ rcu_dereference_protected(slots[offset],
+ lock_is_held(&rcu_callback_map)))
+ slots = mte_dead_walk(&enode, offset);
+ node = mte_to_node(enode);
} while ((node != start) || (node->slot_len < offset));
slots = ma_slots(node, node->type);
mt_free_bulk(node->slot_len, slots);
-start_slots_free:
- mas_unlock(&mas);
free_leaf:
mt_free_rcu(&node->rcu);
}
-static inline void __rcu **mas_destroy_descend(struct ma_state *mas,
- struct maple_enode *prev, unsigned char offset)
+static inline void __rcu **mte_destroy_descend(struct maple_enode **enode,
+ struct maple_tree *mt, struct maple_enode *prev, unsigned char offset)
{
struct maple_node *node;
- struct maple_enode *next = mas->node;
+ struct maple_enode *next = *enode;
void __rcu **slots = NULL;
+ enum maple_type type;
+ unsigned char next_offset = 0;
do {
- mas->node = next;
- node = mas_mn(mas);
- slots = ma_slots(node, mte_node_type(mas->node));
- next = mas_slot_locked(mas, slots, 0);
- if ((mte_dead_node(next))) {
- mte_to_node(next)->type = mte_node_type(next);
- next = mas_slot_locked(mas, slots, 1);
- }
+ *enode = next;
+ node = mte_to_node(*enode);
+ type = mte_node_type(*enode);
+ slots = ma_slots(node, type);
+ next = mt_slot_locked(mt, slots, next_offset);
+ if ((mte_dead_node(next)))
+ next = mt_slot_locked(mt, slots, ++next_offset);
- mte_set_node_dead(mas->node);
- node->type = mte_node_type(mas->node);
- mas_clear_meta(mas, node, node->type);
+ mte_set_node_dead(*enode);
+ node->type = type;
node->piv_parent = prev;
node->parent_slot = offset;
- offset = 0;
- prev = mas->node;
+ offset = next_offset;
+ next_offset = 0;
+ prev = *enode;
} while (!mte_is_leaf(next));
return slots;
}
-static void mt_destroy_walk(struct maple_enode *enode, unsigned char ma_flags,
+static void mt_destroy_walk(struct maple_enode *enode, struct maple_tree *mt,
bool free)
{
void __rcu **slots;
struct maple_node *node = mte_to_node(enode);
struct maple_enode *start;
- struct maple_tree mt;
- MA_STATE(mas, &mt, 0, 0);
-
- mas.node = enode;
if (mte_is_leaf(enode)) {
node->type = mte_node_type(enode);
goto free_leaf;
}
- ma_flags &= ~MT_FLAGS_LOCK_MASK;
- mt_init_flags(&mt, ma_flags);
- mas_lock(&mas);
-
- mte_to_node(enode)->ma_flags = ma_flags;
start = enode;
- slots = mas_destroy_descend(&mas, start, 0);
- node = mas_mn(&mas);
+ slots = mte_destroy_descend(&enode, mt, start, 0);
+ node = mte_to_node(enode); // Updated in the above call.
do {
enum maple_type type;
unsigned char offset;
struct maple_enode *parent, *tmp;
- node->type = mte_node_type(mas.node);
- node->slot_len = mas_dead_leaves(&mas, slots, node->type);
+ node->slot_len = mte_dead_leaves(enode, mt, slots);
if (free)
mt_free_bulk(node->slot_len, slots);
offset = node->parent_slot + 1;
- mas.node = node->piv_parent;
- if (mas_mn(&mas) == node)
- goto start_slots_free;
+ enode = node->piv_parent;
+ if (mte_to_node(enode) == node)
+ goto free_leaf;
- type = mte_node_type(mas.node);
- slots = ma_slots(mte_to_node(mas.node), type);
+ type = mte_node_type(enode);
+ slots = ma_slots(mte_to_node(enode), type);
if (offset >= mt_slots[type])
goto next;
- tmp = mas_slot_locked(&mas, slots, offset);
+ tmp = mt_slot_locked(mt, slots, offset);
if (mte_node_type(tmp) && mte_to_node(tmp)) {
- parent = mas.node;
- mas.node = tmp;
- slots = mas_destroy_descend(&mas, parent, offset);
+ parent = enode;
+ enode = tmp;
+ slots = mte_destroy_descend(&enode, mt, parent, offset);
}
next:
- node = mas_mn(&mas);
- } while (start != mas.node);
+ node = mte_to_node(enode);
+ } while (start != enode);
- node = mas_mn(&mas);
- node->type = mte_node_type(mas.node);
- node->slot_len = mas_dead_leaves(&mas, slots, node->type);
+ node = mte_to_node(enode);
+ node->slot_len = mte_dead_leaves(enode, mt, slots);
if (free)
mt_free_bulk(node->slot_len, slots);
-start_slots_free:
- mas_unlock(&mas);
-
free_leaf:
if (free)
mt_free_rcu(&node->rcu);
else
- mas_clear_meta(&mas, node, node->type);
+ mt_clear_meta(mt, node, node->type);
}
/*
@@ -5688,10 +5692,10 @@ static inline void mte_destroy_walk(stru
struct maple_node *node = mte_to_node(enode);
if (mt_in_rcu(mt)) {
- mt_destroy_walk(enode, mt->ma_flags, false);
+ mt_destroy_walk(enode, mt, false);
call_rcu(&node->rcu, mt_free_walk);
} else {
- mt_destroy_walk(enode, mt->ma_flags, true);
+ mt_destroy_walk(enode, mt, true);
}
}
_
Patches currently in -mm which might be from Liam.Howlett@oracle.com are
^ permalink raw reply
* [merged mm-hotfixes-stable] maple_tree-remove-extra-smp_wmb-from-mas_dead_leaves.patch removed from -mm tree
From: Andrew Morton @ 2023-04-06 1:06 UTC (permalink / raw)
To: mm-commits, surenb, stable, Liam.Howlett, akpm
The quilt patch titled
Subject: maple_tree: remove extra smp_wmb() from mas_dead_leaves()
has been removed from the -mm tree. Its filename was
maple_tree-remove-extra-smp_wmb-from-mas_dead_leaves.patch
This patch was dropped because it was merged into the mm-hotfixes-stable branch
of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
------------------------------------------------------
From: Liam Howlett <Liam.Howlett@oracle.com>
Subject: maple_tree: remove extra smp_wmb() from mas_dead_leaves()
Date: Mon, 27 Feb 2023 09:36:03 -0800
The call to mte_set_dead_node() before the smp_wmb() already calls
smp_wmb() so this is not needed. This is an optimization for the RCU mode
of the maple tree.
Link: https://lkml.kernel.org/r/20230227173632.3292573-5-surenb@google.com
Fixes: 54a611b60590 ("Maple Tree: add new data structure")
Signed-off-by: Liam Howlett <Liam.Howlett@oracle.com>
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
lib/maple_tree.c | 1 -
1 file changed, 1 deletion(-)
--- a/lib/maple_tree.c~maple_tree-remove-extra-smp_wmb-from-mas_dead_leaves
+++ a/lib/maple_tree.c
@@ -5503,7 +5503,6 @@ unsigned char mas_dead_leaves(struct ma_
break;
mte_set_node_dead(entry);
- smp_wmb(); /* Needed for RCU */
node->type = type;
rcu_assign_pointer(slots[offset], node);
}
_
Patches currently in -mm which might be from Liam.Howlett@oracle.com are
^ permalink raw reply
* [merged mm-hotfixes-stable] maple_tree-fix-write-memory-barrier-of-nodes-once-dead-for-rcu-mode.patch removed from -mm tree
From: Andrew Morton @ 2023-04-06 1:06 UTC (permalink / raw)
To: mm-commits, surenb, stable, Liam.Howlett, akpm
The quilt patch titled
Subject: maple_tree: fix write memory barrier of nodes once dead for RCU mode
has been removed from the -mm tree. Its filename was
maple_tree-fix-write-memory-barrier-of-nodes-once-dead-for-rcu-mode.patch
This patch was dropped because it was merged into the mm-hotfixes-stable branch
of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
------------------------------------------------------
From: "Liam R. Howlett" <Liam.Howlett@oracle.com>
Subject: maple_tree: fix write memory barrier of nodes once dead for RCU mode
Date: Mon, 27 Feb 2023 09:36:04 -0800
During the development of the maple tree, the strategy of freeing multiple
nodes changed and, in the process, the pivots were reused to store
pointers to dead nodes. To ensure the readers see accurate pivots, the
writers need to mark the nodes as dead and call smp_wmb() to ensure any
readers can identify the node as dead before using the pivot values.
There were two places where the old method of marking the node as dead
without smp_wmb() were being used, which resulted in RCU readers seeing
the wrong pivot value before seeing the node was dead. Fix this race
condition by using mte_set_node_dead() which has the smp_wmb() call to
ensure the race is closed.
Add a WARN_ON() to the ma_free_rcu() call to ensure all nodes being freed
are marked as dead to ensure there are no other call paths besides the two
updated paths.
This is necessary for the RCU mode of the maple tree.
Link: https://lkml.kernel.org/r/20230227173632.3292573-6-surenb@google.com
Fixes: 54a611b60590 ("Maple Tree: add new data structure")
Signed-off-by: Liam R. Howlett <Liam.Howlett@oracle.com>
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
lib/maple_tree.c | 7 +++++--
tools/testing/radix-tree/maple.c | 16 ++++++++++++++++
2 files changed, 21 insertions(+), 2 deletions(-)
--- a/lib/maple_tree.c~maple_tree-fix-write-memory-barrier-of-nodes-once-dead-for-rcu-mode
+++ a/lib/maple_tree.c
@@ -185,7 +185,7 @@ static void mt_free_rcu(struct rcu_head
*/
static void ma_free_rcu(struct maple_node *node)
{
- node->parent = ma_parent_ptr(node);
+ WARN_ON(node->parent != ma_parent_ptr(node));
call_rcu(&node->rcu, mt_free_rcu);
}
@@ -1778,8 +1778,10 @@ static inline void mas_replace(struct ma
rcu_assign_pointer(slots[offset], mas->node);
}
- if (!advanced)
+ if (!advanced) {
+ mte_set_node_dead(old_enode);
mas_free(mas, old_enode);
+ }
}
/*
@@ -4218,6 +4220,7 @@ static inline bool mas_wr_node_store(str
done:
mas_leaf_set_meta(mas, newnode, dst_pivots, maple_leaf_64, new_end);
if (in_rcu) {
+ mte_set_node_dead(mas->node);
mas->node = mt_mk_node(newnode, wr_mas->type);
mas_replace(mas, false);
} else {
--- a/tools/testing/radix-tree/maple.c~maple_tree-fix-write-memory-barrier-of-nodes-once-dead-for-rcu-mode
+++ a/tools/testing/radix-tree/maple.c
@@ -108,6 +108,7 @@ static noinline void check_new_node(stru
MT_BUG_ON(mt, mn->slot[1] != NULL);
MT_BUG_ON(mt, mas_allocated(&mas) != 0);
+ mn->parent = ma_parent_ptr(mn);
ma_free_rcu(mn);
mas.node = MAS_START;
mas_nomem(&mas, GFP_KERNEL);
@@ -160,6 +161,7 @@ static noinline void check_new_node(stru
MT_BUG_ON(mt, mas_allocated(&mas) != i);
MT_BUG_ON(mt, !mn);
MT_BUG_ON(mt, not_empty(mn));
+ mn->parent = ma_parent_ptr(mn);
ma_free_rcu(mn);
}
@@ -192,6 +194,7 @@ static noinline void check_new_node(stru
MT_BUG_ON(mt, not_empty(mn));
MT_BUG_ON(mt, mas_allocated(&mas) != i - 1);
MT_BUG_ON(mt, !mn);
+ mn->parent = ma_parent_ptr(mn);
ma_free_rcu(mn);
}
@@ -210,6 +213,7 @@ static noinline void check_new_node(stru
mn = mas_pop_node(&mas);
MT_BUG_ON(mt, not_empty(mn));
MT_BUG_ON(mt, mas_allocated(&mas) != j - 1);
+ mn->parent = ma_parent_ptr(mn);
ma_free_rcu(mn);
}
MT_BUG_ON(mt, mas_allocated(&mas) != 0);
@@ -233,6 +237,7 @@ static noinline void check_new_node(stru
MT_BUG_ON(mt, mas_allocated(&mas) != i - j);
mn = mas_pop_node(&mas);
MT_BUG_ON(mt, not_empty(mn));
+ mn->parent = ma_parent_ptr(mn);
ma_free_rcu(mn);
MT_BUG_ON(mt, mas_allocated(&mas) != i - j - 1);
}
@@ -269,6 +274,7 @@ static noinline void check_new_node(stru
mn = mas_pop_node(&mas); /* get the next node. */
MT_BUG_ON(mt, mn == NULL);
MT_BUG_ON(mt, not_empty(mn));
+ mn->parent = ma_parent_ptr(mn);
ma_free_rcu(mn);
}
MT_BUG_ON(mt, mas_allocated(&mas) != 0);
@@ -294,6 +300,7 @@ static noinline void check_new_node(stru
mn = mas_pop_node(&mas2); /* get the next node. */
MT_BUG_ON(mt, mn == NULL);
MT_BUG_ON(mt, not_empty(mn));
+ mn->parent = ma_parent_ptr(mn);
ma_free_rcu(mn);
}
MT_BUG_ON(mt, mas_allocated(&mas2) != 0);
@@ -334,10 +341,12 @@ static noinline void check_new_node(stru
MT_BUG_ON(mt, mas_allocated(&mas) != MAPLE_ALLOC_SLOTS + 2);
mn = mas_pop_node(&mas);
MT_BUG_ON(mt, not_empty(mn));
+ mn->parent = ma_parent_ptr(mn);
ma_free_rcu(mn);
for (i = 1; i <= MAPLE_ALLOC_SLOTS + 1; i++) {
mn = mas_pop_node(&mas);
MT_BUG_ON(mt, not_empty(mn));
+ mn->parent = ma_parent_ptr(mn);
ma_free_rcu(mn);
}
MT_BUG_ON(mt, mas_allocated(&mas) != 0);
@@ -375,6 +384,7 @@ static noinline void check_new_node(stru
mas_node_count(&mas, i); /* Request */
mas_nomem(&mas, GFP_KERNEL); /* Fill request */
mn = mas_pop_node(&mas); /* get the next node. */
+ mn->parent = ma_parent_ptr(mn);
ma_free_rcu(mn);
mas_destroy(&mas);
@@ -382,10 +392,13 @@ static noinline void check_new_node(stru
mas_node_count(&mas, i); /* Request */
mas_nomem(&mas, GFP_KERNEL); /* Fill request */
mn = mas_pop_node(&mas); /* get the next node. */
+ mn->parent = ma_parent_ptr(mn);
ma_free_rcu(mn);
mn = mas_pop_node(&mas); /* get the next node. */
+ mn->parent = ma_parent_ptr(mn);
ma_free_rcu(mn);
mn = mas_pop_node(&mas); /* get the next node. */
+ mn->parent = ma_parent_ptr(mn);
ma_free_rcu(mn);
mas_destroy(&mas);
}
@@ -35369,6 +35382,7 @@ static noinline void check_prealloc(stru
MT_BUG_ON(mt, allocated != 1 + height * 3);
mn = mas_pop_node(&mas);
MT_BUG_ON(mt, mas_allocated(&mas) != allocated - 1);
+ mn->parent = ma_parent_ptr(mn);
ma_free_rcu(mn);
MT_BUG_ON(mt, mas_preallocate(&mas, GFP_KERNEL) != 0);
mas_destroy(&mas);
@@ -35386,6 +35400,7 @@ static noinline void check_prealloc(stru
mas_destroy(&mas);
allocated = mas_allocated(&mas);
MT_BUG_ON(mt, allocated != 0);
+ mn->parent = ma_parent_ptr(mn);
ma_free_rcu(mn);
MT_BUG_ON(mt, mas_preallocate(&mas, GFP_KERNEL) != 0);
@@ -35756,6 +35771,7 @@ void farmer_tests(void)
tree.ma_root = mt_mk_node(node, maple_leaf_64);
mt_dump(&tree);
+ node->parent = ma_parent_ptr(node);
ma_free_rcu(node);
/* Check things that will make lockdep angry */
_
Patches currently in -mm which might be from Liam.Howlett@oracle.com are
^ permalink raw reply
* [merged mm-hotfixes-stable] maple_tree-add-smp_rmb-to-dead-node-detection.patch removed from -mm tree
From: Andrew Morton @ 2023-04-06 1:06 UTC (permalink / raw)
To: mm-commits, surenb, stable, Liam.Howlett, akpm
The quilt patch titled
Subject: maple_tree: add smp_rmb() to dead node detection
has been removed from the -mm tree. Its filename was
maple_tree-add-smp_rmb-to-dead-node-detection.patch
This patch was dropped because it was merged into the mm-hotfixes-stable branch
of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
------------------------------------------------------
From: "Liam R. Howlett" <Liam.Howlett@oracle.com>
Subject: maple_tree: add smp_rmb() to dead node detection
Date: Mon, 27 Feb 2023 09:36:05 -0800
Add an smp_rmb() before reading the parent pointer to ensure that anything
read from the node prior to the parent pointer hasn't been reordered ahead
of this check.
The is necessary for RCU mode.
Link: https://lkml.kernel.org/r/20230227173632.3292573-7-surenb@google.com
Fixes: 54a611b60590 ("Maple Tree: add new data structure")
Signed-off-by: Liam R. Howlett <Liam.Howlett@oracle.com>
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
lib/maple_tree.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
--- a/lib/maple_tree.c~maple_tree-add-smp_rmb-to-dead-node-detection
+++ a/lib/maple_tree.c
@@ -539,9 +539,11 @@ static inline struct maple_node *mte_par
*/
static inline bool ma_dead_node(const struct maple_node *node)
{
- struct maple_node *parent = (void *)((unsigned long)
- node->parent & ~MAPLE_NODE_MASK);
+ struct maple_node *parent;
+ /* Do not reorder reads from the node prior to the parent check */
+ smp_rmb();
+ parent = (void *)((unsigned long) node->parent & ~MAPLE_NODE_MASK);
return (parent == node);
}
@@ -556,6 +558,8 @@ static inline bool mte_dead_node(const s
struct maple_node *parent, *node;
node = mte_to_node(enode);
+ /* Do not reorder reads from the node prior to the parent check */
+ smp_rmb();
parent = mte_parent(enode);
return (parent == node);
}
_
Patches currently in -mm which might be from Liam.Howlett@oracle.com are
^ permalink raw reply
* [merged mm-hotfixes-stable] maple_tree-fix-freeing-of-nodes-in-rcu-mode.patch removed from -mm tree
From: Andrew Morton @ 2023-04-06 1:06 UTC (permalink / raw)
To: mm-commits, surenb, stable, Liam.Howlett, akpm
The quilt patch titled
Subject: maple_tree: fix freeing of nodes in rcu mode
has been removed from the -mm tree. Its filename was
maple_tree-fix-freeing-of-nodes-in-rcu-mode.patch
This patch was dropped because it was merged into the mm-hotfixes-stable branch
of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
------------------------------------------------------
From: Liam Howlett <Liam.Howlett@oracle.com>
Subject: maple_tree: fix freeing of nodes in rcu mode
Date: Mon, 27 Feb 2023 09:36:02 -0800
The walk to destroy the nodes was not always setting the node type and
would result in a destroy method potentially using the values as nodes.
Avoid this by setting the correct node types. This is necessary for the
RCU mode of the maple tree.
Link: https://lkml.kernel.org/r/20230227173632.3292573-4-surenb@google.com
Fixes: 54a611b60590 ("Maple Tree: add new data structure")
Signed-off-by: Liam Howlett <Liam.Howlett@oracle.com>
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
lib/maple_tree.c | 73 ++++++++++++++++++++++++++++++++++++++-------
1 file changed, 62 insertions(+), 11 deletions(-)
--- a/lib/maple_tree.c~maple_tree-fix-freeing-of-nodes-in-rcu-mode
+++ a/lib/maple_tree.c
@@ -903,6 +903,44 @@ static inline void ma_set_meta(struct ma
}
/*
+ * mas_clear_meta() - clear the metadata information of a node, if it exists
+ * @mas: The maple state
+ * @mn: The maple node
+ * @mt: The maple node type
+ * @offset: The offset of the highest sub-gap in this node.
+ * @end: The end of the data in this node.
+ */
+static inline void mas_clear_meta(struct ma_state *mas, struct maple_node *mn,
+ enum maple_type mt)
+{
+ struct maple_metadata *meta;
+ unsigned long *pivots;
+ void __rcu **slots;
+ void *next;
+
+ switch (mt) {
+ case maple_range_64:
+ pivots = mn->mr64.pivot;
+ if (unlikely(pivots[MAPLE_RANGE64_SLOTS - 2])) {
+ slots = mn->mr64.slot;
+ next = mas_slot_locked(mas, slots,
+ MAPLE_RANGE64_SLOTS - 1);
+ if (unlikely((mte_to_node(next) && mte_node_type(next))))
+ return; /* The last slot is a node, no metadata */
+ }
+ fallthrough;
+ case maple_arange_64:
+ meta = ma_meta(mn, mt);
+ break;
+ default:
+ return;
+ }
+
+ meta->gap = 0;
+ meta->end = 0;
+}
+
+/*
* ma_meta_end() - Get the data end of a node from the metadata
* @mn: The maple node
* @mt: The maple node type
@@ -5441,20 +5479,22 @@ no_gap:
* mas_dead_leaves() - Mark all leaves of a node as dead.
* @mas: The maple state
* @slots: Pointer to the slot array
+ * @type: The maple node type
*
* Must hold the write lock.
*
* Return: The number of leaves marked as dead.
*/
static inline
-unsigned char mas_dead_leaves(struct ma_state *mas, void __rcu **slots)
+unsigned char mas_dead_leaves(struct ma_state *mas, void __rcu **slots,
+ enum maple_type mt)
{
struct maple_node *node;
enum maple_type type;
void *entry;
int offset;
- for (offset = 0; offset < mt_slot_count(mas->node); offset++) {
+ for (offset = 0; offset < mt_slots[mt]; offset++) {
entry = mas_slot_locked(mas, slots, offset);
type = mte_node_type(entry);
node = mte_to_node(entry);
@@ -5473,14 +5513,13 @@ unsigned char mas_dead_leaves(struct ma_
static void __rcu **mas_dead_walk(struct ma_state *mas, unsigned char offset)
{
- struct maple_node *node, *next;
+ struct maple_node *next;
void __rcu **slots = NULL;
next = mas_mn(mas);
do {
- mas->node = ma_enode_ptr(next);
- node = mas_mn(mas);
- slots = ma_slots(node, node->type);
+ mas->node = mt_mk_node(next, next->type);
+ slots = ma_slots(next, next->type);
next = mas_slot_locked(mas, slots, offset);
offset = 0;
} while (!ma_is_leaf(next->type));
@@ -5544,11 +5583,14 @@ static inline void __rcu **mas_destroy_d
node = mas_mn(mas);
slots = ma_slots(node, mte_node_type(mas->node));
next = mas_slot_locked(mas, slots, 0);
- if ((mte_dead_node(next)))
+ if ((mte_dead_node(next))) {
+ mte_to_node(next)->type = mte_node_type(next);
next = mas_slot_locked(mas, slots, 1);
+ }
mte_set_node_dead(mas->node);
node->type = mte_node_type(mas->node);
+ mas_clear_meta(mas, node, node->type);
node->piv_parent = prev;
node->parent_slot = offset;
offset = 0;
@@ -5568,13 +5610,18 @@ static void mt_destroy_walk(struct maple
MA_STATE(mas, &mt, 0, 0);
- if (mte_is_leaf(enode))
+ mas.node = enode;
+ if (mte_is_leaf(enode)) {
+ node->type = mte_node_type(enode);
goto free_leaf;
+ }
+ ma_flags &= ~MT_FLAGS_LOCK_MASK;
mt_init_flags(&mt, ma_flags);
mas_lock(&mas);
- mas.node = start = enode;
+ mte_to_node(enode)->ma_flags = ma_flags;
+ start = enode;
slots = mas_destroy_descend(&mas, start, 0);
node = mas_mn(&mas);
do {
@@ -5582,7 +5629,8 @@ static void mt_destroy_walk(struct maple
unsigned char offset;
struct maple_enode *parent, *tmp;
- node->slot_len = mas_dead_leaves(&mas, slots);
+ node->type = mte_node_type(mas.node);
+ node->slot_len = mas_dead_leaves(&mas, slots, node->type);
if (free)
mt_free_bulk(node->slot_len, slots);
offset = node->parent_slot + 1;
@@ -5606,7 +5654,8 @@ next:
} while (start != mas.node);
node = mas_mn(&mas);
- node->slot_len = mas_dead_leaves(&mas, slots);
+ node->type = mte_node_type(mas.node);
+ node->slot_len = mas_dead_leaves(&mas, slots, node->type);
if (free)
mt_free_bulk(node->slot_len, slots);
@@ -5616,6 +5665,8 @@ start_slots_free:
free_leaf:
if (free)
mt_free_rcu(&node->rcu);
+ else
+ mas_clear_meta(&mas, node, node->type);
}
/*
_
Patches currently in -mm which might be from Liam.Howlett@oracle.com are
^ permalink raw reply
* [merged mm-hotfixes-stable] maple_tree-detect-dead-nodes-in-mas_start.patch removed from -mm tree
From: Andrew Morton @ 2023-04-06 1:06 UTC (permalink / raw)
To: mm-commits, surenb, stable, Liam.Howlett, akpm
The quilt patch titled
Subject: maple_tree: detect dead nodes in mas_start()
has been removed from the -mm tree. Its filename was
maple_tree-detect-dead-nodes-in-mas_start.patch
This patch was dropped because it was merged into the mm-hotfixes-stable branch
of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
------------------------------------------------------
From: Liam Howlett <Liam.Howlett@oracle.com>
Subject: maple_tree: detect dead nodes in mas_start()
Date: Mon, 27 Feb 2023 09:36:01 -0800
When initially starting a search, the root node may already be in the
process of being replaced in RCU mode. Detect and restart the walk if
this is the case. This is necessary for RCU mode of the maple tree.
Link: https://lkml.kernel.org/r/20230227173632.3292573-3-surenb@google.com
Fixes: 54a611b60590 ("Maple Tree: add new data structure")
Signed-off-by: Liam Howlett <Liam.Howlett@oracle.com>
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
lib/maple_tree.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/lib/maple_tree.c~maple_tree-detect-dead-nodes-in-mas_start
+++ a/lib/maple_tree.c
@@ -1360,12 +1360,16 @@ static inline struct maple_enode *mas_st
mas->max = ULONG_MAX;
mas->depth = 0;
+retry:
root = mas_root(mas);
/* Tree with nodes */
if (likely(xa_is_node(root))) {
mas->depth = 1;
mas->node = mte_safe_root(root);
mas->offset = 0;
+ if (mte_dead_node(mas->node))
+ goto retry;
+
return NULL;
}
_
Patches currently in -mm which might be from Liam.Howlett@oracle.com are
^ permalink raw reply
* [merged mm-hotfixes-stable] maple_tree-be-more-cautious-about-dead-nodes.patch removed from -mm tree
From: Andrew Morton @ 2023-04-06 1:06 UTC (permalink / raw)
To: mm-commits, willy, will, vbabka, surenb, stable, songliubraving,
soheil, shakeelb, rppt, rientjes, punit.agrawal, posk, peterz,
peterx, paulmck, mingo, minchan, michalechner92, mhocko, mgorman,
luto, lstoakes, ldufour, kent.overstreet, joelaf, jannh, hughd,
hannes, gthelen, edumazet, dhowells, david, dave, chriscli,
bigeasy, axelrasmussen, arjunroy, Liam.Howlett, akpm
The quilt patch titled
Subject: maple_tree: be more cautious about dead nodes
has been removed from the -mm tree. Its filename was
maple_tree-be-more-cautious-about-dead-nodes.patch
This patch was dropped because it was merged into the mm-hotfixes-stable branch
of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
------------------------------------------------------
From: Liam Howlett <Liam.Howlett@oracle.com>
Subject: maple_tree: be more cautious about dead nodes
Date: Mon, 27 Feb 2023 09:36:00 -0800
Patch series "Fix VMA tree modification under mmap read lock".
Syzbot reported a BUG_ON in mm/mmap.c which was found to be caused by an
inconsistency between threads walking the VMA maple tree. The
inconsistency is caused by the page fault handler modifying the maple tree
while holding the mmap_lock for read.
This only happens for stack VMAs. We had thought this was safe as it only
modifies a single pivot in the tree. Unfortunately, syzbot constructed a
test case where the stack had no guard page and grew the stack to abut the
next VMA. This causes us to delete the NULL entry between the two VMAs
and rewrite the node.
We considered several options for fixing this, including dropping the
mmap_lock, then reacquiring it for write; and relaxing the definition of
the tree to permit a zero-length NULL entry in the node. We decided the
best option was to backport some of the RCU patches from -next, which
solve the problem by allocating a new node and RCU-freeing the old node.
Since the problem exists in 6.1, we preferred a solution which is similar
to the one we intended to merge next merge window.
These patches have been in -next since next-20230301, and have received
intensive testing in Android as part of the RCU page fault patchset. They
were also sent as part of the "Per-VMA locks" v4 patch series. Patches 1
to 7 are bug fixes for RCU mode of the tree and patch 8 enables RCU mode
for the tree.
Performance v6.3-rc3 vs patched v6.3-rc3: Running these changes through
mmtests showed there was a 15-20% performance decrease in
will-it-scale/brk1-processes. This tests creating and inserting a single
VMA repeatedly through the brk interface and isn't representative of any
real world applications.
This patch (of 8):
ma_pivots() and ma_data_end() may be called with a dead node. Ensure to
that the node isn't dead before using the returned values.
This is necessary for RCU mode of the maple tree.
Link: https://lkml.kernel.org/r/20230327185532.2354250-1-Liam.Howlett@oracle.com
Link: https://lkml.kernel.org/r/20230227173632.3292573-1-surenb@google.com
Link: https://lkml.kernel.org/r/20230227173632.3292573-2-surenb@google.com
Fixes: 54a611b60590 ("Maple Tree: add new data structure")
Signed-off-by: Liam Howlett <Liam.Howlett@oracle.com>
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Arjun Roy <arjunroy@google.com>
Cc: Axel Rasmussen <axelrasmussen@google.com>
Cc: Chris Li <chriscli@google.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: David Howells <dhowells@redhat.com>
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: David Rientjes <rientjes@google.com>
Cc: Eric Dumazet <edumazet@google.com>
Cc: freak07 <michalechner92@googlemail.com>
Cc: Greg Thelen <gthelen@google.com>
Cc: Hugh Dickins <hughd@google.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jann Horn <jannh@google.com>
Cc: Joel Fernandes <joelaf@google.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Kent Overstreet <kent.overstreet@linux.dev>
Cc: Laurent Dufour <ldufour@linux.ibm.com>
Cc: Lorenzo Stoakes <lstoakes@gmail.com>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Mel Gorman <mgorman@techsingularity.net>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Minchan Kim <minchan@google.com>
Cc: Paul E. McKenney <paulmck@kernel.org>
Cc: Peter Oskolkov <posk@google.com>
Cc: Peter Xu <peterx@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Punit Agrawal <punit.agrawal@bytedance.com>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Shakeel Butt <shakeelb@google.com>
Cc: Soheil Hassas Yeganeh <soheil@google.com>
Cc: Song Liu <songliubraving@fb.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Will Deacon <will@kernel.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
lib/maple_tree.c | 52 +++++++++++++++++++++++++++++++++++++--------
1 file changed, 43 insertions(+), 9 deletions(-)
--- a/lib/maple_tree.c~maple_tree-be-more-cautious-about-dead-nodes
+++ a/lib/maple_tree.c
@@ -544,6 +544,7 @@ static inline bool ma_dead_node(const st
return (parent == node);
}
+
/*
* mte_dead_node() - check if the @enode is dead.
* @enode: The encoded maple node
@@ -625,6 +626,8 @@ static inline unsigned int mas_alloc_req
* @node - the maple node
* @type - the node type
*
+ * In the event of a dead node, this array may be %NULL
+ *
* Return: A pointer to the maple node pivots
*/
static inline unsigned long *ma_pivots(struct maple_node *node,
@@ -1096,8 +1099,11 @@ static int mas_ascend(struct ma_state *m
a_type = mas_parent_enum(mas, p_enode);
a_node = mte_parent(p_enode);
a_slot = mte_parent_slot(p_enode);
- pivots = ma_pivots(a_node, a_type);
a_enode = mt_mk_node(a_node, a_type);
+ pivots = ma_pivots(a_node, a_type);
+
+ if (unlikely(ma_dead_node(a_node)))
+ return 1;
if (!set_min && a_slot) {
set_min = true;
@@ -1401,6 +1407,9 @@ static inline unsigned char ma_data_end(
{
unsigned char offset;
+ if (!pivots)
+ return 0;
+
if (type == maple_arange_64)
return ma_meta_end(node, type);
@@ -1436,6 +1445,9 @@ static inline unsigned char mas_data_end
return ma_meta_end(node, type);
pivots = ma_pivots(node, type);
+ if (unlikely(ma_dead_node(node)))
+ return 0;
+
offset = mt_pivots[type] - 1;
if (likely(!pivots[offset]))
return ma_meta_end(node, type);
@@ -4505,6 +4517,9 @@ static inline int mas_prev_node(struct m
node = mas_mn(mas);
slots = ma_slots(node, mt);
pivots = ma_pivots(node, mt);
+ if (unlikely(ma_dead_node(node)))
+ return 1;
+
mas->max = pivots[offset];
if (offset)
mas->min = pivots[offset - 1] + 1;
@@ -4526,6 +4541,9 @@ static inline int mas_prev_node(struct m
slots = ma_slots(node, mt);
pivots = ma_pivots(node, mt);
offset = ma_data_end(node, mt, pivots, mas->max);
+ if (unlikely(ma_dead_node(node)))
+ return 1;
+
if (offset)
mas->min = pivots[offset - 1] + 1;
@@ -4574,6 +4592,7 @@ static inline int mas_next_node(struct m
struct maple_enode *enode;
int level = 0;
unsigned char offset;
+ unsigned char node_end;
enum maple_type mt;
void __rcu **slots;
@@ -4597,7 +4616,11 @@ static inline int mas_next_node(struct m
node = mas_mn(mas);
mt = mte_node_type(mas->node);
pivots = ma_pivots(node, mt);
- } while (unlikely(offset == ma_data_end(node, mt, pivots, mas->max)));
+ node_end = ma_data_end(node, mt, pivots, mas->max);
+ if (unlikely(ma_dead_node(node)))
+ return 1;
+
+ } while (unlikely(offset == node_end));
slots = ma_slots(node, mt);
pivot = mas_safe_pivot(mas, pivots, ++offset, mt);
@@ -4613,6 +4636,9 @@ static inline int mas_next_node(struct m
mt = mte_node_type(mas->node);
slots = ma_slots(node, mt);
pivots = ma_pivots(node, mt);
+ if (unlikely(ma_dead_node(node)))
+ return 1;
+
offset = 0;
pivot = pivots[0];
}
@@ -4659,11 +4685,14 @@ static inline void *mas_next_nentry(stru
return NULL;
}
- pivots = ma_pivots(node, type);
slots = ma_slots(node, type);
- mas->index = mas_safe_min(mas, pivots, mas->offset);
+ pivots = ma_pivots(node, type);
count = ma_data_end(node, type, pivots, mas->max);
- if (ma_dead_node(node))
+ if (unlikely(ma_dead_node(node)))
+ return NULL;
+
+ mas->index = mas_safe_min(mas, pivots, mas->offset);
+ if (unlikely(ma_dead_node(node)))
return NULL;
if (mas->index > max)
@@ -4817,6 +4846,11 @@ retry:
slots = ma_slots(mn, mt);
pivots = ma_pivots(mn, mt);
+ if (unlikely(ma_dead_node(mn))) {
+ mas_rewalk(mas, index);
+ goto retry;
+ }
+
if (offset == mt_pivots[mt])
pivot = mas->max;
else
@@ -6617,11 +6651,11 @@ static inline void *mas_first_entry(stru
while (likely(!ma_is_leaf(mt))) {
MT_BUG_ON(mas->tree, mte_dead_node(mas->node));
slots = ma_slots(mn, mt);
- pivots = ma_pivots(mn, mt);
- max = pivots[0];
entry = mas_slot(mas, slots, 0);
+ pivots = ma_pivots(mn, mt);
if (unlikely(ma_dead_node(mn)))
return NULL;
+ max = pivots[0];
mas->node = entry;
mn = mas_mn(mas);
mt = mte_node_type(mas->node);
@@ -6641,13 +6675,13 @@ static inline void *mas_first_entry(stru
if (likely(entry))
return entry;
- pivots = ma_pivots(mn, mt);
- mas->index = pivots[0] + 1;
mas->offset = 1;
entry = mas_slot(mas, slots, 1);
+ pivots = ma_pivots(mn, mt);
if (unlikely(ma_dead_node(mn)))
return NULL;
+ mas->index = pivots[0] + 1;
if (mas->index > limit)
goto none;
_
Patches currently in -mm which might be from Liam.Howlett@oracle.com are
^ permalink raw reply
* [folded-merged] mm-hugetlb-fix-uffd-wr-protection-for-cow-optimization-path-v3.patch removed from -mm tree
From: Andrew Morton @ 2023-04-06 1:04 UTC (permalink / raw)
To: mm-commits, usama.anjum, stable, peterx, akpm
The quilt patch titled
Subject: mm-hugetlb-fix-uffd-wr-protection-for-cow-optimization-path-v3
has been removed from the -mm tree. Its filename was
mm-hugetlb-fix-uffd-wr-protection-for-cow-optimization-path-v3.patch
This patch was dropped because it was folded into mm-hugetlb-fix-uffd-wr-protection-for-cow-optimization-path.patch
------------------------------------------------------
From: Peter Xu <peterx@redhat.com>
Subject: mm-hugetlb-fix-uffd-wr-protection-for-cow-optimization-path-v3
Date: Fri, 24 Mar 2023 10:26:20 -0400
Link: https://lkml.kernel.org/r/20230324142620.2344140-1-peterx@redhat.com
Reported-by: Muhammad Usama Anjum <usama.anjum@collabora.com>
Cc: linux-stable <stable@vger.kernel.org>
Fixes: 166f3ecc0daf ("mm/hugetlb: hook page faults for uffd write protection")
Signed-off-by: Peter Xu <peterx@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/hugetlb.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/mm/hugetlb.c~mm-hugetlb-fix-uffd-wr-protection-for-cow-optimization-path-v3
+++ a/mm/hugetlb.c
@@ -5491,11 +5491,11 @@ static vm_fault_t hugetlb_wp(struct mm_s
* Never handle CoW for uffd-wp protected pages. It should be only
* handled when the uffd-wp protection is removed.
*
- * Note that only the CoW optimization path can trigger this and
- * got skipped, because hugetlb_fault() will always resolve uffd-wp
- * bit first.
+ * Note that only the CoW optimization path (in hugetlb_no_page())
+ * can trigger this, because hugetlb_fault() will always resolve
+ * uffd-wp bit first.
*/
- if (huge_pte_uffd_wp(pte))
+ if (!unshare && huge_pte_uffd_wp(pte))
return 0;
/*
_
Patches currently in -mm which might be from peterx@redhat.com are
mm-hugetlb-fix-uffd-wr-protection-for-cow-optimization-path.patch
mm-khugepaged-check-again-on-anon-uffd-wp-during-isolation.patch
mm-uffd-uffd_feature_wp_unpopulated.patch
mm-uffd-uffd_feature_wp_unpopulated-fix.patch
selftests-mm-smoke-test-uffd_feature_wp_unpopulated.patch
^ permalink raw reply
* Re: [PATCH 5.4 084/357] treewide: Replace DECLARE_TASKLET() with DECLARE_TASKLET_OLD()
From: Daniel Díaz @ 2023-04-06 0:44 UTC (permalink / raw)
To: Tom Saeger, Greg Kroah-Hartman
Cc: stable, patches, Thomas Gleixner, Kees Cook, Sasha Levin
In-Reply-To: <20230320172710.mx7hsqs6tgmcpxjd@oracle.com>
Hello!
On 20/03/23 11:27, Tom Saeger wrote:
> On Mon, Mar 20, 2023 at 11:48:02AM -0500, Tom Saeger wrote:
>> On Mon, Mar 20, 2023 at 02:24:35PM +0100, Greg Kroah-Hartman wrote:
>>> On Fri, Mar 17, 2023 at 12:28:06PM -0600, Tom Saeger wrote:
>>>> On Fri, Mar 10, 2023 at 02:36:13PM +0100, Greg Kroah-Hartman wrote:
>>>>> From: Kees Cook <keescook@chromium.org>
>>>>>
>>>>> [ Upstream commit b13fecb1c3a603c4b8e99b306fecf4f668c11b32 ]
>>>>>
>>>>> This converts all the existing DECLARE_TASKLET() (and ...DISABLED)
>>>>> macros with DECLARE_TASKLET_OLD() in preparation for refactoring the
>>>>> tasklet callback type. All existing DECLARE_TASKLET() users had a "0"
>>>>> data argument, it has been removed here as well.
>>>>>
>>>>> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>>>>> Acked-by: Thomas Gleixner <tglx@linutronix.de>
>>>>> Signed-off-by: Kees Cook <keescook@chromium.org>
>>>>> Stable-dep-of: 1fdeb8b9f29d ("wifi: iwl3945: Add missing check for create_singlethread_workqueue")
>>>>> Signed-off-by: Sasha Levin <sashal@kernel.org>
>>>>> ---
>>>>
>>>> I noticed kernelci.org bot (5.4) reports:
>>>>
>>>> Build Failures Detected:
>>>>
>>>> mips:
>>>> ip27_defconfig: (gcc-10) FAIL
>>>> ip28_defconfig: (gcc-10) FAIL
>>>> lasat_defconfig: (gcc-10) FAIL
>>>>
>>>> Errors summary:
>>>>
>>>> 1 arch/mips/lasat/picvue_proc.c:87:20: error: ‘pvc_display_tasklet’ undeclared (first use in this function)
>>>> 1 arch/mips/lasat/picvue_proc.c:42:44: error: expected ‘)’ before ‘&’ token
>>>> 1 arch/mips/lasat/picvue_proc.c:33:13: error: ‘pvc_display’ defined but not used [-Werror=unused-function]
>>>>
>>>> Link: https://lore.kernel.org/stable/64041dda.170a0220.8cc25.79c9@mx.google.com/
>>>>
>>>> Here's what I found...
>>>> this backport to 5.4.y of:
>>>> b13fecb1c3a6 ("treewide: Replace DECLARE_TASKLET() with DECLARE_TASKLET_OLD()")
>>>> changed all locations of DECLARE_TASKLET with DECLARE_TASKLET_OLD,
>>>> except one, in arch/mips/lasat/pcivue_proc.c.
>>>>
>>>> This is due to:
>>>> 10760dde9be3 ("MIPS: Remove support for LASAT") preceeding
>>>> b13fecb1c3a6 ("treewide: Replace DECLARE_TASKLET() with DECLARE_TASKLET_OLD()")
>>>> upstream and the former not being present in 5.4.y.
>>>>
>>>> I rolled a revert/re-apply with fixes in the attached mbox,
>>>> however maybe just a revert makes more sense? Up to you.
>>>>
>>>> I have yet to try building this on mips, just did this by inspection.
>>>
>>> I've taken your patches, let's see how that works...
>>>
>>
>> Ugh, It didn't go well. I now see a problem. The change to DECLARE_TASKLET_OLD also
>> removed the last parameter. I missed that. I'll spin-up a mips build.
>>
>
> I've now confirmed locally with gcc-10 mips build of lasat_defconfig
>
>
> fixup patch should be:
>
>
> diff --git a/arch/mips/lasat/picvue_proc.c b/arch/mips/lasat/picvue_proc.c
> index 8126f15b8e09..6b019915b0c8 100644
> --- a/arch/mips/lasat/picvue_proc.c
> +++ b/arch/mips/lasat/picvue_proc.c
> @@ -39,7 +39,7 @@ static void pvc_display(unsigned long data)
> pvc_write_string(pvc_lines[i], 0, i);
> }
>
> -static DECLARE_TASKLET(pvc_display_tasklet, &pvc_display, 0);
> +static DECLARE_TASKLET_OLD(pvc_display_tasklet, &pvc_display);
>
> static int pvc_line_proc_show(struct seq_file *m, void *v)
> {
>
>
> Attached is a reflow of these two patches.
We don't generally build lasat_defconfig but can reproduce the problem on the most recent 5.4.y RC (5.4.240-rc1). Bisection led to "treewide: Replace DECLARE_TASKLET() with DECLARE_TASKLET_OLD()" (5de7a4254eb2) (as expected), and reverting it also made the build pass (as expected, I guess).
With those two patches applied on top of 5.4.240-rc1, MIPS' lasat_defconfig builds with GCC-12 for us.
Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
Greetings!
Daniel Díaz
daniel.diaz@linaro.org
^ permalink raw reply
* Re: [PATCH net 1/4] can: j1939: j1939_tp_tx_dat_new(): fix out-of-bounds memory access
From: patchwork-bot+netdevbpf @ 2023-04-06 0:30 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: netdev, davem, kuba, linux-can, kernel, o.rempel, sjb7183, stable
In-Reply-To: <20230405092444.1802340-2-mkl@pengutronix.de>
Hello:
This series was applied to netdev/net.git (main)
by Marc Kleine-Budde <mkl@pengutronix.de>:
On Wed, 5 Apr 2023 11:24:41 +0200 you wrote:
> From: Oleksij Rempel <o.rempel@pengutronix.de>
>
> In the j1939_tp_tx_dat_new() function, an out-of-bounds memory access
> could occur during the memcpy() operation if the size of skb->cb is
> larger than the size of struct j1939_sk_buff_cb. This is because the
> memcpy() operation uses the size of skb->cb, leading to a read beyond
> the struct j1939_sk_buff_cb.
>
> [...]
Here is the summary with links:
- [net,1/4] can: j1939: j1939_tp_tx_dat_new(): fix out-of-bounds memory access
https://git.kernel.org/netdev/net/c/b45193cb4df5
- [net,2/4] can: isotp: isotp_recvmsg(): use sock_recv_cmsgs() to get SOCK_RXQ_OVFL infos
https://git.kernel.org/netdev/net/c/0145462fc802
- [net,3/4] can: isotp: isotp_ops: fix poll() to not report false EPOLLOUT events
https://git.kernel.org/netdev/net/c/79e19fa79cb5
- [net,4/4] can: isotp: fix race between isotp_sendsmg() and isotp_release()
https://git.kernel.org/netdev/net/c/051737439eae
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH 6.2 000/185] 6.2.10-rc2 review
From: Kelsey Steele @ 2023-04-05 23:47 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: stable, patches, linux-kernel, torvalds, akpm, linux, shuah,
patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, srw, rwarsow
In-Reply-To: <20230405100309.298748790@linuxfoundation.org>
On Wed, Apr 05, 2023 at 12:03:46PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 6.2.10 release.
> There are 185 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Fri, 07 Apr 2023 10:02:32 +0000.
> Anything received after that time might be too late.
No regressions found on WSL (x86 and arm64).
Built, booted, and reviewed dmesg.
Thank you.
Tested-by: Kelsey Steele <kelseysteele@linux.microsoft.com>
^ permalink raw reply
* Re: [PATCH 6.1 000/177] 6.1.23-rc3 review
From: Kelsey Steele @ 2023-04-05 23:43 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: stable, patches, linux-kernel, torvalds, akpm, linux, shuah,
patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, srw, rwarsow
In-Reply-To: <20230405100302.540890806@linuxfoundation.org>
On Wed, Apr 05, 2023 at 12:03:38PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 6.1.23 release.
> There are 177 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Fri, 07 Apr 2023 10:02:26 +0000.
> Anything received after that time might be too late.
Builds and boots on x86 and arm64 WSL. No regressions found through
dmesg.
Thank you Greg for the updated -rc. :)
Tested-by: Kelsey Steele <kelseysteele@linux.microsoft.com>
^ permalink raw reply
* [PATCH] serial: max310x: fix IO data corruption in batched operations
From: Jan Kundrát @ 2023-04-05 20:14 UTC (permalink / raw)
To: linux-serial
Cc: Cosmin Tanislav, Cosmin Tanislav, Greg Kroah-Hartman, stable,
Jiri Slaby, Andy Shevchenko
After upgrading from 5.16 to 6.1, our board with a MAX14830 started
producing lots of garbage data over UART. Bisection pointed out commit
285e76fc049c as the culprit. That patch tried to replace hand-written
code which I added in 2b4bac48c1084 ("serial: max310x: Use batched reads
when reasonably safe") with the generic regmap infrastructure for
batched operations.
Unfortunately, the `regmap_raw_read` and `regmap_raw_write` which were
used are actually functions which perform IO over *multiple* registers.
That's not what is needed for accessing these Tx/Rx FIFOs; the
appropriate functions are the `_noinc_` versions, not the `_raw_` ones.
Fix this regression by using `regmap_noinc_read()` and
`regmap_noinc_write()` along with the necessary `regmap_config` setup;
with this patch in place, our board communicates happily again. Since
our board uses SPI for talking to this chip, the I2C part is completely
untested.
Fixes: 285e76fc049c serial: max310x: use regmap methods for SPI batch operations
Signed-off-by: Jan Kundrát <jan.kundrat@cesnet.cz>
Cc: stable@vger.kernel.org
---
drivers/tty/serial/max310x.c | 17 +++++++++++++++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/max310x.c b/drivers/tty/serial/max310x.c
index c82391c928cb..47520d4a381f 100644
--- a/drivers/tty/serial/max310x.c
+++ b/drivers/tty/serial/max310x.c
@@ -529,6 +529,11 @@ static bool max310x_reg_precious(struct device *dev, unsigned int reg)
return false;
}
+static bool max310x_reg_noinc(struct device *dev, unsigned int reg)
+{
+ return reg == MAX310X_RHR_REG;
+}
+
static int max310x_set_baud(struct uart_port *port, int baud)
{
unsigned int mode = 0, div = 0, frac = 0, c = 0, F = 0;
@@ -658,14 +663,14 @@ static void max310x_batch_write(struct uart_port *port, u8 *txbuf, unsigned int
{
struct max310x_one *one = to_max310x_port(port);
- regmap_raw_write(one->regmap, MAX310X_THR_REG, txbuf, len);
+ regmap_noinc_write(one->regmap, MAX310X_THR_REG, txbuf, len);
}
static void max310x_batch_read(struct uart_port *port, u8 *rxbuf, unsigned int len)
{
struct max310x_one *one = to_max310x_port(port);
- regmap_raw_read(one->regmap, MAX310X_RHR_REG, rxbuf, len);
+ regmap_noinc_read(one->regmap, MAX310X_RHR_REG, rxbuf, len);
}
static void max310x_handle_rx(struct uart_port *port, unsigned int rxlen)
@@ -1480,6 +1485,10 @@ static struct regmap_config regcfg = {
.writeable_reg = max310x_reg_writeable,
.volatile_reg = max310x_reg_volatile,
.precious_reg = max310x_reg_precious,
+ .writeable_noinc_reg = max310x_reg_noinc,
+ .readable_noinc_reg = max310x_reg_noinc,
+ .max_raw_read = MAX310X_FIFO_SIZE,
+ .max_raw_write = MAX310X_FIFO_SIZE,
};
#ifdef CONFIG_SPI_MASTER
@@ -1565,6 +1574,10 @@ static struct regmap_config regcfg_i2c = {
.volatile_reg = max310x_reg_volatile,
.precious_reg = max310x_reg_precious,
.max_register = MAX310X_I2C_REVID_EXTREG,
+ .writeable_noinc_reg = max310x_reg_noinc,
+ .readable_noinc_reg = max310x_reg_noinc,
+ .max_raw_read = MAX310X_FIFO_SIZE,
+ .max_raw_write = MAX310X_FIFO_SIZE,
};
static const struct max310x_if_cfg max310x_i2c_if_cfg = {
--
2.39.2
^ permalink raw reply related
* MST Unplugged during suspend
From: Limonciello, Mario @ 2023-04-05 22:13 UTC (permalink / raw)
To: stable@vger.kernel.org
[Public]
Hi,
There is a bug present in 6.2.y and 6.1.y where if a dock that supports MST is unplugged during suspend it's not possible to get MST working after resume. This is because the cleanup/error path doesn't actually clear the MST tree.
It's fixed in 6.3 with:
3f6752b4de41 ("drm/amd/display: Clear MST topology if it fails to resume")
Can this please be backported to 6.2.y and 6.1.y?
Thanks,
^ permalink raw reply
* Re: [PATCH net] net: sfp: initialize sfp->i2c_block_size at sfp allocation
From: Ivan Bornyakov @ 2023-04-05 21:13 UTC (permalink / raw)
To: Andrew Lunn
Cc: netdev, linux, hkallweit1, davem, edumazet, kuba, pabeni,
linux-kernel, system, stable
In-Reply-To: <4c78acf7-3c72-40c5-b6cf-ff6033b80e85@lunn.ch>
On Wed, Apr 05, 2023 at 10:51:38PM +0200, Andrew Lunn wrote:
> On Wed, Apr 05, 2023 at 11:41:16PM +0300, Ivan Bornyakov wrote:
> > On Wed, Apr 05, 2023 at 09:35:31PM +0200, Andrew Lunn wrote:
> > > On Wed, Apr 05, 2023 at 06:39:00PM +0300, Ivan Bornyakov wrote:
> > > > sfp->i2c_block_size is initialized at SFP module insertion in
> > > > sfp_sm_mod_probe(). Because of that, if SFP module was not inserted
> > > > since boot, ethtool -m leads to zero-length I2C read attempt.
> > > >
> > > > # ethtool -m xge0
> > > > i2c i2c-3: adapter quirk: no zero length (addr 0x0050, size 0, read)
> > > > Cannot get Module EEPROM data: Operation not supported
> > >
> > > Do i understand you correct in that this is when the SFP cage has
> > > always been empty? The I2C transaction is going to fail whatever the
> > > length is.
> > >
> >
> > Yes, SFP cage is empty, I2C transaction will fail anyways, but not all
> > I2C controllers are happy about zero-length reads.
> >
> > > > If SFP module was plugged then removed at least once,
> > > > sfp->i2c_block_size will be initialized and ethtool -m will fail with
> > > > different error
> > > >
> > > > # ethtool -m xge0
> > > > Cannot get Module EEPROM data: Remote I/O error
> > >
> > > So again, the SFP cage is empty?
> > >
> > > I wonder if a better fix is to use
> > >
> > > sfp->state & SFP_F_PRESENT
> > >
> > > in sfp_module_eeprom() and sfp_module_eeprom_by_page() and don't even
> > > do the I2C read if there is no module in the cage?
> > >
> >
> > This is also worthy addition to sfp.c, but IMHO sfp->i2c_block_size
> > initialization still need to be fixed since
> >
> > $ grep -c "sfp_read(" drivers/net/phy/sfp.c
> > 31
> >
> > and I can't vouch all of them are possible only after SFP module
> > insertion. Also for future proof reason.
>
> I think everything else should be safe. A lot of those reads are for
> the HWMON code. And the HWMON code only registers when the module is
> inserted.
>
> How about two patches, what you have here, plus checking sfp->state &
> SFP_F_PRESENT in the ethtool functions?
>
> Andrew
Sure, will do in the near future.
^ permalink raw reply
* Re: [PATCH net] net: sfp: initialize sfp->i2c_block_size at sfp allocation
From: Ivan Bornyakov @ 2023-04-05 20:41 UTC (permalink / raw)
To: Andrew Lunn
Cc: netdev, linux, hkallweit1, davem, edumazet, kuba, pabeni,
linux-kernel, system, stable
In-Reply-To: <19d7ef3c-de9d-4a44-92e9-16ac14b663d9@lunn.ch>
On Wed, Apr 05, 2023 at 09:35:31PM +0200, Andrew Lunn wrote:
> On Wed, Apr 05, 2023 at 06:39:00PM +0300, Ivan Bornyakov wrote:
> > sfp->i2c_block_size is initialized at SFP module insertion in
> > sfp_sm_mod_probe(). Because of that, if SFP module was not inserted
> > since boot, ethtool -m leads to zero-length I2C read attempt.
> >
> > # ethtool -m xge0
> > i2c i2c-3: adapter quirk: no zero length (addr 0x0050, size 0, read)
> > Cannot get Module EEPROM data: Operation not supported
>
> Do i understand you correct in that this is when the SFP cage has
> always been empty? The I2C transaction is going to fail whatever the
> length is.
>
Yes, SFP cage is empty, I2C transaction will fail anyways, but not all
I2C controllers are happy about zero-length reads.
> > If SFP module was plugged then removed at least once,
> > sfp->i2c_block_size will be initialized and ethtool -m will fail with
> > different error
> >
> > # ethtool -m xge0
> > Cannot get Module EEPROM data: Remote I/O error
>
> So again, the SFP cage is empty?
>
> I wonder if a better fix is to use
>
> sfp->state & SFP_F_PRESENT
>
> in sfp_module_eeprom() and sfp_module_eeprom_by_page() and don't even
> do the I2C read if there is no module in the cage?
>
This is also worthy addition to sfp.c, but IMHO sfp->i2c_block_size
initialization still need to be fixed since
$ grep -c "sfp_read(" drivers/net/phy/sfp.c
31
and I can't vouch all of them are possible only after SFP module
insertion. Also for future proof reason.
^ permalink raw reply
* stable-rc/queue/6.1 baseline: 175 runs, 8 regressions (v6.1.22-178-gaa9876e65686)
From: kernelci.org bot @ 2023-04-05 20:55 UTC (permalink / raw)
To: stable, kernel-build-reports, kernelci-results
stable-rc/queue/6.1 baseline: 175 runs, 8 regressions (v6.1.22-178-gaa9876e65686)
Regressions Summary
-------------------
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+---------------+----------+------------------------------+------------
asus-C436FA-Flip-hatch | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1
asus-CM1400CXA-dalboz | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1
asus-cx9400-volteer | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1
bcm2835-rpi-b-rev2 | arm | lab-broonie | gcc-10 | bcm2835_defconfig | 1
hp-x360-12b-c...4020-octopus | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1
hp-x360-14-G1-sona | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1
hp-x360-14a-cb0001xx-zork | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1
lenovo-TPad-C13-Yoga-zork | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1
Details: https://kernelci.org/test/job/stable-rc/branch/queue%2F6.1/kernel/v6.1.22-178-gaa9876e65686/plan/baseline/
Test: baseline
Tree: stable-rc
Branch: queue/6.1
Describe: v6.1.22-178-gaa9876e65686
URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
SHA: aa9876e6568634e604c60ae37d1c0f811840bd0d
Test Regressions
----------------
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+---------------+----------+------------------------------+------------
asus-C436FA-Flip-hatch | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1
Details: https://kernelci.org/test/plan/id/642da878662ddf2ee679e94c
Results: 6 PASS, 1 FAIL, 0 SKIP
Full config: x86_64_defconfig+x86-chromebook
Compiler: gcc-10 (gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//stable-rc/queue-6.1/v6.1.22-178-gaa9876e65686/x86_64/x86_64_defconfig+x86-chromebook/gcc-10/lab-collabora/baseline-asus-C436FA-Flip-hatch.txt
HTML log: https://storage.kernelci.org//stable-rc/queue-6.1/v6.1.22-178-gaa9876e65686/x86_64/x86_64_defconfig+x86-chromebook/gcc-10/lab-collabora/baseline-asus-C436FA-Flip-hatch.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230324.0/x86/rootfs.cpio.gz
* baseline.bootrr.deferred-probe-empty: https://kernelci.org/test/case/id/642da878662ddf2ee679e951
failing since 7 days (last pass: v6.1.21-104-gd5eb32be5b26, first fail: v6.1.21-224-g1abeb39fad59)
2023-04-05T16:57:08.785018 + set +x
2023-04-05T16:57:08.791909 <8>[ 10.533543] <LAVA_SIGNAL_ENDRUN 0_dmesg 9884572_1.4.2.3.1>
2023-04-05T16:57:08.894100
2023-04-05T16:57:08.995061 / # #export SHELL=/bin/sh
2023-04-05T16:57:08.995216
2023-04-05T16:57:09.096100 / # export SHELL=/bin/sh. /lava-9884572/environment
2023-04-05T16:57:09.096252
2023-04-05T16:57:09.197177 / # . /lava-9884572/environment/lava-9884572/bin/lava-test-runner /lava-9884572/1
2023-04-05T16:57:09.197412
2023-04-05T16:57:09.203616 / # /lava-9884572/bin/lava-test-runner /lava-9884572/1
... (12 line(s) more)
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+---------------+----------+------------------------------+------------
asus-CM1400CXA-dalboz | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1
Details: https://kernelci.org/test/plan/id/642da87b662ddf2ee679e965
Results: 6 PASS, 1 FAIL, 0 SKIP
Full config: x86_64_defconfig+x86-chromebook
Compiler: gcc-10 (gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//stable-rc/queue-6.1/v6.1.22-178-gaa9876e65686/x86_64/x86_64_defconfig+x86-chromebook/gcc-10/lab-collabora/baseline-asus-CM1400CXA-dalboz.txt
HTML log: https://storage.kernelci.org//stable-rc/queue-6.1/v6.1.22-178-gaa9876e65686/x86_64/x86_64_defconfig+x86-chromebook/gcc-10/lab-collabora/baseline-asus-CM1400CXA-dalboz.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230324.0/x86/rootfs.cpio.gz
* baseline.bootrr.deferred-probe-empty: https://kernelci.org/test/case/id/642da87b662ddf2ee679e96a
failing since 7 days (last pass: v6.1.21-104-gd5eb32be5b26, first fail: v6.1.21-224-g1abeb39fad59)
2023-04-05T16:57:12.356110 + <8>[ 11.479510] <LAVA_SIGNAL_ENDRUN 0_dmesg 9884521_1.4.2.3.1>
2023-04-05T16:57:12.356208 set +x
2023-04-05T16:57:12.461075 / # #
2023-04-05T16:57:12.562231 export SHELL=/bin/sh
2023-04-05T16:57:12.562449 #
2023-04-05T16:57:12.663355 / # export SHELL=/bin/sh. /lava-9884521/environment
2023-04-05T16:57:12.663577
2023-04-05T16:57:12.764486 / # . /lava-9884521/environment/lava-9884521/bin/lava-test-runner /lava-9884521/1
2023-04-05T16:57:12.764803
2023-04-05T16:57:12.769188 / # /lava-9884521/bin/lava-test-runner /lava-9884521/1
... (12 line(s) more)
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+---------------+----------+------------------------------+------------
asus-cx9400-volteer | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1
Details: https://kernelci.org/test/plan/id/642da8854acffb6aaa79e94a
Results: 6 PASS, 1 FAIL, 0 SKIP
Full config: x86_64_defconfig+x86-chromebook
Compiler: gcc-10 (gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//stable-rc/queue-6.1/v6.1.22-178-gaa9876e65686/x86_64/x86_64_defconfig+x86-chromebook/gcc-10/lab-collabora/baseline-asus-cx9400-volteer.txt
HTML log: https://storage.kernelci.org//stable-rc/queue-6.1/v6.1.22-178-gaa9876e65686/x86_64/x86_64_defconfig+x86-chromebook/gcc-10/lab-collabora/baseline-asus-cx9400-volteer.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230324.0/x86/rootfs.cpio.gz
* baseline.bootrr.deferred-probe-empty: https://kernelci.org/test/case/id/642da8854acffb6aaa79e94f
failing since 7 days (last pass: v6.1.21-104-gd5eb32be5b26, first fail: v6.1.21-224-g1abeb39fad59)
2023-04-05T16:57:24.060586 <8>[ 10.635629] <LAVA_SIGNAL_ENDRUN 0_dmesg 9884537_1.4.2.3.1>
2023-04-05T16:57:24.063757 + set +x
2023-04-05T16:57:24.169253 #
2023-04-05T16:57:24.170386
2023-04-05T16:57:24.272574 / # #export SHELL=/bin/sh
2023-04-05T16:57:24.273304
2023-04-05T16:57:24.374958 / # export SHELL=/bin/sh. /lava-9884537/environment
2023-04-05T16:57:24.375737
2023-04-05T16:57:24.477776 / # . /lava-9884537/environment/lava-9884537/bin/lava-test-runner /lava-9884537/1
2023-04-05T16:57:24.478972
... (13 line(s) more)
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+---------------+----------+------------------------------+------------
bcm2835-rpi-b-rev2 | arm | lab-broonie | gcc-10 | bcm2835_defconfig | 1
Details: https://kernelci.org/test/plan/id/642da72b73073ac4ec79ea73
Results: 50 PASS, 2 FAIL, 1 SKIP
Full config: bcm2835_defconfig
Compiler: gcc-10 (arm-linux-gnueabihf-gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//stable-rc/queue-6.1/v6.1.22-178-gaa9876e65686/arm/bcm2835_defconfig/gcc-10/lab-broonie/baseline-bcm2835-rpi-b-rev2.txt
HTML log: https://storage.kernelci.org//stable-rc/queue-6.1/v6.1.22-178-gaa9876e65686/arm/bcm2835_defconfig/gcc-10/lab-broonie/baseline-bcm2835-rpi-b-rev2.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230324.0/armel/rootfs.cpio.gz
* baseline.bootrr.deferred-probe-empty: https://kernelci.org/test/case/id/642da72b73073ac4ec79eaa2
new failure (last pass: v6.1.22-178-g526133810841)
2023-04-05T16:51:37.061498 + set +x
2023-04-05T16:51:37.065357 <8>[ 16.759503] <LAVA_SIGNAL_ENDRUN 0_dmesg 285922_1.5.2.4.1>
2023-04-05T16:51:37.180543 / # #
2023-04-05T16:51:37.282934 export SHELL=/bin/sh
2023-04-05T16:51:37.283499 #
2023-04-05T16:51:37.385518 / # export SHELL=/bin/sh. /lava-285922/environment
2023-04-05T16:51:37.386264
2023-04-05T16:51:37.488215 / # . /lava-285922/environment/lava-285922/bin/lava-test-runner /lava-285922/1
2023-04-05T16:51:37.489288
2023-04-05T16:51:37.495122 / # /lava-285922/bin/lava-test-runner /lava-285922/1
... (14 line(s) more)
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+---------------+----------+------------------------------+------------
hp-x360-12b-c...4020-octopus | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1
Details: https://kernelci.org/test/plan/id/642da97f5e231379a279e963
Results: 6 PASS, 1 FAIL, 0 SKIP
Full config: x86_64_defconfig+x86-chromebook
Compiler: gcc-10 (gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//stable-rc/queue-6.1/v6.1.22-178-gaa9876e65686/x86_64/x86_64_defconfig+x86-chromebook/gcc-10/lab-collabora/baseline-hp-x360-12b-ca0010nr-n4020-octopus.txt
HTML log: https://storage.kernelci.org//stable-rc/queue-6.1/v6.1.22-178-gaa9876e65686/x86_64/x86_64_defconfig+x86-chromebook/gcc-10/lab-collabora/baseline-hp-x360-12b-ca0010nr-n4020-octopus.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230324.0/x86/rootfs.cpio.gz
* baseline.bootrr.deferred-probe-empty: https://kernelci.org/test/case/id/642da97f5e231379a279e968
failing since 7 days (last pass: v6.1.21-104-gd5eb32be5b26, first fail: v6.1.21-224-g1abeb39fad59)
2023-04-05T17:01:36.279898 + set +x
2023-04-05T17:01:36.286526 <8>[ 10.291402] <LAVA_SIGNAL_ENDRUN 0_dmesg 9884549_1.4.2.3.1>
2023-04-05T17:01:36.395558 / # #
2023-04-05T17:01:36.498051 export SHELL=/bin/sh
2023-04-05T17:01:36.498723 #
2023-04-05T17:01:36.600622 / # export SHELL=/bin/sh. /lava-9884549/environment
2023-04-05T17:01:36.600811
2023-04-05T17:01:36.701757 / # . /lava-9884549/environment/lava-9884549/bin/lava-test-runner /lava-9884549/1
2023-04-05T17:01:36.702898
2023-04-05T17:01:36.707609 / # /lava-9884549/bin/lava-test-runner /lava-9884549/1
... (12 line(s) more)
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+---------------+----------+------------------------------+------------
hp-x360-14-G1-sona | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1
Details: https://kernelci.org/test/plan/id/642da8708243e482ee79e937
Results: 6 PASS, 1 FAIL, 0 SKIP
Full config: x86_64_defconfig+x86-chromebook
Compiler: gcc-10 (gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//stable-rc/queue-6.1/v6.1.22-178-gaa9876e65686/x86_64/x86_64_defconfig+x86-chromebook/gcc-10/lab-collabora/baseline-hp-x360-14-G1-sona.txt
HTML log: https://storage.kernelci.org//stable-rc/queue-6.1/v6.1.22-178-gaa9876e65686/x86_64/x86_64_defconfig+x86-chromebook/gcc-10/lab-collabora/baseline-hp-x360-14-G1-sona.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230324.0/x86/rootfs.cpio.gz
* baseline.bootrr.deferred-probe-empty: https://kernelci.org/test/case/id/642da8708243e482ee79e93c
failing since 7 days (last pass: v6.1.21-104-gd5eb32be5b26, first fail: v6.1.21-224-g1abeb39fad59)
2023-04-05T16:57:06.936263 + set +x
2023-04-05T16:57:06.942872 <8>[ 10.697891] <LAVA_SIGNAL_ENDRUN 0_dmesg 9884520_1.4.2.3.1>
2023-04-05T16:57:07.047634 / # #
2023-04-05T16:57:07.148714 export SHELL=/bin/sh
2023-04-05T16:57:07.148913 #
2023-04-05T16:57:07.249806 / # export SHELL=/bin/sh. /lava-9884520/environment
2023-04-05T16:57:07.250003
2023-04-05T16:57:07.350933 / # . /lava-9884520/environment/lava-9884520/bin/lava-test-runner /lava-9884520/1
2023-04-05T16:57:07.351219
2023-04-05T16:57:07.355842 / # /lava-9884520/bin/lava-test-runner /lava-9884520/1
... (12 line(s) more)
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+---------------+----------+------------------------------+------------
hp-x360-14a-cb0001xx-zork | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1
Details: https://kernelci.org/test/plan/id/642da87c662ddf2ee679e970
Results: 6 PASS, 1 FAIL, 0 SKIP
Full config: x86_64_defconfig+x86-chromebook
Compiler: gcc-10 (gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//stable-rc/queue-6.1/v6.1.22-178-gaa9876e65686/x86_64/x86_64_defconfig+x86-chromebook/gcc-10/lab-collabora/baseline-hp-x360-14a-cb0001xx-zork.txt
HTML log: https://storage.kernelci.org//stable-rc/queue-6.1/v6.1.22-178-gaa9876e65686/x86_64/x86_64_defconfig+x86-chromebook/gcc-10/lab-collabora/baseline-hp-x360-14a-cb0001xx-zork.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230324.0/x86/rootfs.cpio.gz
* baseline.bootrr.deferred-probe-empty: https://kernelci.org/test/case/id/642da87c662ddf2ee679e975
failing since 7 days (last pass: v6.1.21-104-gd5eb32be5b26, first fail: v6.1.21-224-g1abeb39fad59)
2023-04-05T16:57:11.028335 + <8>[ 10.977432] <LAVA_SIGNAL_ENDRUN 0_dmesg 9884551_1.4.2.3.1>
2023-04-05T16:57:11.028461 set +x
2023-04-05T16:57:11.133526 / # #
2023-04-05T16:57:11.234697 export SHELL=/bin/sh
2023-04-05T16:57:11.234904 #
2023-04-05T16:57:11.335798 / # export SHELL=/bin/sh. /lava-9884551/environment
2023-04-05T16:57:11.336033
2023-04-05T16:57:11.437014 / # . /lava-9884551/environment/lava-9884551/bin/lava-test-runner /lava-9884551/1
2023-04-05T16:57:11.437366
2023-04-05T16:57:11.442236 / # /lava-9884551/bin/lava-test-runner /lava-9884551/1
... (12 line(s) more)
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+---------------+----------+------------------------------+------------
lenovo-TPad-C13-Yoga-zork | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1
Details: https://kernelci.org/test/plan/id/642da8cb37fe92f30579e940
Results: 6 PASS, 1 FAIL, 0 SKIP
Full config: x86_64_defconfig+x86-chromebook
Compiler: gcc-10 (gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//stable-rc/queue-6.1/v6.1.22-178-gaa9876e65686/x86_64/x86_64_defconfig+x86-chromebook/gcc-10/lab-collabora/baseline-lenovo-TPad-C13-Yoga-zork.txt
HTML log: https://storage.kernelci.org//stable-rc/queue-6.1/v6.1.22-178-gaa9876e65686/x86_64/x86_64_defconfig+x86-chromebook/gcc-10/lab-collabora/baseline-lenovo-TPad-C13-Yoga-zork.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230324.0/x86/rootfs.cpio.gz
* baseline.bootrr.deferred-probe-empty: https://kernelci.org/test/case/id/642da8cb37fe92f30579e945
failing since 7 days (last pass: v6.1.21-104-gd5eb32be5b26, first fail: v6.1.21-224-g1abeb39fad59)
2023-04-05T16:58:30.275405 + set<8>[ 8.721733] <LAVA_SIGNAL_ENDRUN 0_dmesg 9884552_1.4.2.3.1>
2023-04-05T16:58:30.275500 +x
2023-04-05T16:58:30.380673 / # #
2023-04-05T16:58:30.481799 export SHELL=/bin/sh
2023-04-05T16:58:30.482002 #
2023-04-05T16:58:30.582899 / # export SHELL=/bin/sh. /lava-9884552/environment
2023-04-05T16:58:30.583156
2023-04-05T16:58:30.684170 / # . /lava-9884552/environment/lava-9884552/bin/lava-test-runner /lava-9884552/1
2023-04-05T16:58:30.684547
2023-04-05T16:58:30.688757 / # /lava-9884552/bin/lava-test-runner /lava-9884552/1
... (12 line(s) more)
^ permalink raw reply
* Re: [PATCH net] net: sfp: initialize sfp->i2c_block_size at sfp allocation
From: Andrew Lunn @ 2023-04-05 20:51 UTC (permalink / raw)
To: Ivan Bornyakov
Cc: netdev, linux, hkallweit1, davem, edumazet, kuba, pabeni,
linux-kernel, system, stable
In-Reply-To: <20230405204116.mo5j6klyjnuvenag@x260>
On Wed, Apr 05, 2023 at 11:41:16PM +0300, Ivan Bornyakov wrote:
> On Wed, Apr 05, 2023 at 09:35:31PM +0200, Andrew Lunn wrote:
> > On Wed, Apr 05, 2023 at 06:39:00PM +0300, Ivan Bornyakov wrote:
> > > sfp->i2c_block_size is initialized at SFP module insertion in
> > > sfp_sm_mod_probe(). Because of that, if SFP module was not inserted
> > > since boot, ethtool -m leads to zero-length I2C read attempt.
> > >
> > > # ethtool -m xge0
> > > i2c i2c-3: adapter quirk: no zero length (addr 0x0050, size 0, read)
> > > Cannot get Module EEPROM data: Operation not supported
> >
> > Do i understand you correct in that this is when the SFP cage has
> > always been empty? The I2C transaction is going to fail whatever the
> > length is.
> >
>
> Yes, SFP cage is empty, I2C transaction will fail anyways, but not all
> I2C controllers are happy about zero-length reads.
>
> > > If SFP module was plugged then removed at least once,
> > > sfp->i2c_block_size will be initialized and ethtool -m will fail with
> > > different error
> > >
> > > # ethtool -m xge0
> > > Cannot get Module EEPROM data: Remote I/O error
> >
> > So again, the SFP cage is empty?
> >
> > I wonder if a better fix is to use
> >
> > sfp->state & SFP_F_PRESENT
> >
> > in sfp_module_eeprom() and sfp_module_eeprom_by_page() and don't even
> > do the I2C read if there is no module in the cage?
> >
>
> This is also worthy addition to sfp.c, but IMHO sfp->i2c_block_size
> initialization still need to be fixed since
>
> $ grep -c "sfp_read(" drivers/net/phy/sfp.c
> 31
>
> and I can't vouch all of them are possible only after SFP module
> insertion. Also for future proof reason.
I think everything else should be safe. A lot of those reads are for
the HWMON code. And the HWMON code only registers when the module is
inserted.
How about two patches, what you have here, plus checking sfp->state &
SFP_F_PRESENT in the ethtool functions?
Andrew
^ permalink raw reply
* Re: [f2fs-dev] [PATCH] f2fs: get out of a repeat loop when getting a locked data page
From: Jaegeuk Kim @ 2023-04-05 20:47 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Chao Yu, linux-kernel, linux-f2fs-devel, stable, linux-mm,
linux-fsdevel
In-Reply-To: <ZC2kSfNUXKK4PfpM@google.com>
On 04/05, Jaegeuk Kim wrote:
> On 03/27, Matthew Wilcox wrote:
> > On Mon, Mar 27, 2023 at 08:30:33AM -0700, Jaegeuk Kim wrote:
> > > On 03/26, Chao Yu wrote:
> > > > On 2023/3/24 5:39, Jaegeuk Kim wrote:
> > > > > https://bugzilla.kernel.org/show_bug.cgi?id=216050
> > > > >
> > > > > Somehow we're getting a page which has a different mapping.
> > > > > Let's avoid the infinite loop.
> > > > >
> > > > > Cc: <stable@vger.kernel.org>
> > > > > Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
> > > > > ---
> > > > > fs/f2fs/data.c | 8 ++------
> > > > > 1 file changed, 2 insertions(+), 6 deletions(-)
> > > > >
> > > > > diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
> > > > > index bf51e6e4eb64..80702c93e885 100644
> > > > > --- a/fs/f2fs/data.c
> > > > > +++ b/fs/f2fs/data.c
> > > > > @@ -1329,18 +1329,14 @@ struct page *f2fs_get_lock_data_page(struct inode *inode, pgoff_t index,
> > > > > {
> > > > > struct address_space *mapping = inode->i_mapping;
> > > > > struct page *page;
> > > > > -repeat:
> > > > > +
> > > > > page = f2fs_get_read_data_page(inode, index, 0, for_write, NULL);
> > > > > if (IS_ERR(page))
> > > > > return page;
> > > > > /* wait for read completion */
> > > > > lock_page(page);
> > > > > - if (unlikely(page->mapping != mapping)) {
> > > >
> > > > How about using such logic only for move_data_page() to limit affect for
> > > > other paths?
> > >
> > > Why move_data_page() only? If this happens, we'll fall into a loop in anywhere?
> > >
> > > >
> > > > Jaegeuk, any thoughts about why mapping is mismatch in between page's one and
> > > > inode->i_mapping?
> > >
> > > >
> > > > After several times code review, I didn't get any clue about why f2fs always
> > > > get the different mapping in a loop.
> > >
> > > I couldn't find the path to happen this. So weird. Please check the history in the
> > > bug.
> > >
> > > >
> > > > Maybe we can loop MM guys to check whether below folio_file_page() may return
> > > > page which has different mapping?
> > >
> > > Matthew may have some idea on this?
> >
> > There's a lot of comments in the bug ... hard to come into this one
> > cold.
> >
> > I did notice this one (#119):
> > : Interestingly, ref count is 514, which looks suspiciously as a binary
> > : flag 1000000010. Is it possible that during 5.17/5.18 implementation
> > : of a "pin", somehow binary flag was written to ref count, or something
> > : like '1 << ...' happens?
> >
> > That indicates to me that somehow you've got hold of a THP that is in
> > the page cache. Probably shmem/tmpfs. That indicate to me a refcount
> > problem that looks something like this:
> >
> > f2fs allocates a page
> > f2fs adds the page to the page cache
> > f2fs puts the reference to the page without removing it from the
> > page cache (how?)
>
> Is it somewhat related to setting a bit in private field?
>
> When we migrate the blocks, we do:
> 1) get_lock_page()
> 2) submit read
> 3) lock_page()
> 3) set_page_dirty()
> 4) set_page_private_gcing(page)
>
> --- in fs/f2fs/f2fs.h
> 1409 #define PAGE_PRIVATE_SET_FUNC(name, flagname) \
> 1410 static inline void set_page_private_##name(struct page *page) \
> 1411 { \
> 1412 if (!PagePrivate(page)) { \
> 1413 get_page(page); \
> 1414 SetPagePrivate(page); \
> 1415 set_page_private(page, 0); \
> 1416 } \
> 1417 set_bit(PAGE_PRIVATE_NOT_POINTER, &page_private(page)); \
> 1418 set_bit(PAGE_PRIVATE_##flagname, &page_private(page)); \
> 1419 }
>
>
> 5) set_page_writebac()
> 6) submit write
> 7) unlock_page()
> 8) put_page(page)
>
> Later, f2fs_invalidate_folio will do put_page again by:
> clear_page_private_gcing(&folio->page);
>
> --- in fs/f2fs/f2fs.h
> 1421 #define PAGE_PRIVATE_CLEAR_FUNC(name, flagname) \
> 1422 static inline void clear_page_private_##name(struct page *page) \
> 1423 { \
> 1424 clear_bit(PAGE_PRIVATE_##flagname, &page_private(page)); \
> 1425 if (page_private(page) == BIT(PAGE_PRIVATE_NOT_POINTER)) { \
> 1426 set_page_private(page, 0); \
> 1427 if (PagePrivate(page)) { \
> 1428 ClearPagePrivate(page); \
> 1429 put_page(page); \
> 1430 }\
> 1431 } \
> 1432 }
It seems f2fs_invalidate_folio and f2fs_release_folio drop the refcount by
folio_detach_private() additionally.
https://lore.kernel.org/lkml/20230405204321.2056498-1-jaegeuk@kernel.org/T/#u
>
> > page is now free, gets reallocated into a THP
> > lookup from the f2fs file finds the new THP
> > things explode messily
> >
> > Checking page->mapping is going to avoid the messy explosion, but
> > you'll still have a page in the page cache which doesn't actually
> > belong to you, and that's going to lead to subtle data corruption.
> >
> > This should be caught by page_expected_state(), called from
> > free_page_is_bad(), called from free_pages_prepare(). Do your testers
> > have CONFIG_DEBUG_VM enabled? That might give you a fighting chance at
> > finding the last place which called put_page(). It won't necessarily be
> > the _wrong_ place to call put_page() (that may have happened earlier),
> > but it may give you a clue.
> >
> > > >
> > > > struct page *pagecache_get_page(struct address_space *mapping, pgoff_t index,
> > > > int fgp_flags, gfp_t gfp)
> > > > {
> > > > struct folio *folio;
> > > >
> > > > folio = __filemap_get_folio(mapping, index, fgp_flags, gfp);
> > > > if (IS_ERR(folio))
> > > > return NULL;
> > > > return folio_file_page(folio, index);
> > > > }
> > > >
> > > > Thanks,
> > > >
> > > > > - f2fs_put_page(page, 1);
> > > > > - goto repeat;
> > > > > - }
> > > > > - if (unlikely(!PageUptodate(page))) {
> > > > > + if (unlikely(page->mapping != mapping || !PageUptodate(page))) {
> > > > > f2fs_put_page(page, 1);
> > > > > return ERR_PTR(-EIO);
> > > > > }
^ permalink raw reply
* [PATCH] f2fs: attach/detach private value in pair
From: Jaegeuk Kim @ 2023-04-05 20:43 UTC (permalink / raw)
To: linux-kernel, linux-f2fs-devel; +Cc: Jaegeuk Kim, stable
set_page_private_# increases a refcount after attaching page->private, and
clear_page_private_# decreases it.
But, f2fs_release_folio and f2fs_invalidate_folio call folio_detach_private()
which decreases the refcount again, which corrupts the page cache.
Cc: <stable@vger.kernel.org>
Fixes: b763f3bedc2d ("f2fs: restructure f2fs page.private layout")
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
---
fs/f2fs/compress.c | 4 ++--
fs/f2fs/data.c | 6 ++++--
fs/f2fs/f2fs.h | 48 ++++++++++++++++------------------------------
3 files changed, 22 insertions(+), 36 deletions(-)
diff --git a/fs/f2fs/compress.c b/fs/f2fs/compress.c
index 11653fa79289..70b3910db413 100644
--- a/fs/f2fs/compress.c
+++ b/fs/f2fs/compress.c
@@ -1854,7 +1854,7 @@ void f2fs_cache_compressed_page(struct f2fs_sb_info *sbi, struct page *page,
return;
}
- set_page_private_data(cpage, ino);
+ set_page_private_ino(cpage, ino);
if (!f2fs_is_valid_blkaddr(sbi, blkaddr, DATA_GENERIC_ENHANCE_READ))
goto out;
@@ -1917,7 +1917,7 @@ void f2fs_invalidate_compress_pages(struct f2fs_sb_info *sbi, nid_t ino)
continue;
}
- if (ino != get_page_private_data(&folio->page)) {
+ if (ino != get_page_private_ino(&folio->page)) {
folio_unlock(folio);
continue;
}
diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 359de650772e..7262c754ff8b 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -3724,8 +3724,9 @@ void f2fs_invalidate_folio(struct folio *folio, size_t offset, size_t length)
if (test_opt(sbi, COMPRESS_CACHE) &&
inode->i_ino == F2FS_COMPRESS_INO(sbi))
- clear_page_private_data(&folio->page);
+ clear_page_private_ino(&folio->page);
+ WARN_ON_ONCE(page_private(&folio->page));
folio_detach_private(folio);
}
@@ -3742,12 +3743,13 @@ bool f2fs_release_folio(struct folio *folio, gfp_t wait)
struct inode *inode = folio->mapping->host;
if (inode->i_ino == F2FS_COMPRESS_INO(sbi))
- clear_page_private_data(&folio->page);
+ clear_page_private_ino(&folio->page);
}
clear_page_private_reference(&folio->page);
clear_page_private_gcing(&folio->page);
+ WARN_ON_ONCE(page_private(&folio->page));
folio_detach_private(folio);
return true;
}
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index dfead8160a51..3d883201e7a5 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -1395,6 +1395,7 @@ enum {
PAGE_PRIVATE_ONGOING_MIGRATION, /* data page which is on-going migrating */
PAGE_PRIVATE_INLINE_INODE, /* inode page contains inline data */
PAGE_PRIVATE_REF_RESOURCE, /* dirty page has referenced resources */
+ PAGE_PRIVATE_DATA, /* page has referenced data */
PAGE_PRIVATE_MAX
};
@@ -1409,73 +1410,56 @@ static inline bool page_private_##name(struct page *page) \
#define PAGE_PRIVATE_SET_FUNC(name, flagname) \
static inline void set_page_private_##name(struct page *page) \
{ \
- if (!PagePrivate(page)) { \
- get_page(page); \
- SetPagePrivate(page); \
- set_page_private(page, 0); \
- } \
+ if (!PagePrivate(page)) \
+ attach_page_private(page, 0); \
set_bit(PAGE_PRIVATE_NOT_POINTER, &page_private(page)); \
set_bit(PAGE_PRIVATE_##flagname, &page_private(page)); \
}
+/* clear private by f2fs_release_folio or f2fs_invalidate_folio */
#define PAGE_PRIVATE_CLEAR_FUNC(name, flagname) \
static inline void clear_page_private_##name(struct page *page) \
{ \
clear_bit(PAGE_PRIVATE_##flagname, &page_private(page)); \
- if (page_private(page) == BIT(PAGE_PRIVATE_NOT_POINTER)) { \
+ if (page_private(page) == BIT(PAGE_PRIVATE_NOT_POINTER)) \
set_page_private(page, 0); \
- if (PagePrivate(page)) { \
- ClearPagePrivate(page); \
- put_page(page); \
- }\
- } \
}
PAGE_PRIVATE_GET_FUNC(nonpointer, NOT_POINTER);
PAGE_PRIVATE_GET_FUNC(inline, INLINE_INODE);
PAGE_PRIVATE_GET_FUNC(gcing, ONGOING_MIGRATION);
PAGE_PRIVATE_GET_FUNC(dummy, DUMMY_WRITE);
+PAGE_PRIVATE_GET_FUNC(data, DATA);
PAGE_PRIVATE_SET_FUNC(reference, REF_RESOURCE);
PAGE_PRIVATE_SET_FUNC(inline, INLINE_INODE);
PAGE_PRIVATE_SET_FUNC(gcing, ONGOING_MIGRATION);
PAGE_PRIVATE_SET_FUNC(dummy, DUMMY_WRITE);
+PAGE_PRIVATE_SET_FUNC(data, DATA);
PAGE_PRIVATE_CLEAR_FUNC(reference, REF_RESOURCE);
PAGE_PRIVATE_CLEAR_FUNC(inline, INLINE_INODE);
PAGE_PRIVATE_CLEAR_FUNC(gcing, ONGOING_MIGRATION);
PAGE_PRIVATE_CLEAR_FUNC(dummy, DUMMY_WRITE);
+PAGE_PRIVATE_CLEAR_FUNC(data, DATA);
-static inline unsigned long get_page_private_data(struct page *page)
+static inline nid_t get_page_private_ino(struct page *page)
{
- unsigned long data = page_private(page);
-
- if (!test_bit(PAGE_PRIVATE_NOT_POINTER, &data))
+ if (!page_private_data(page))
return 0;
- return data >> PAGE_PRIVATE_MAX;
+ return page_private(page) >> PAGE_PRIVATE_MAX;
}
-static inline void set_page_private_data(struct page *page, unsigned long data)
+static inline void set_page_private_ino(struct page *page, nid_t ino)
{
- if (!PagePrivate(page)) {
- get_page(page);
- SetPagePrivate(page);
- set_page_private(page, 0);
- }
- set_bit(PAGE_PRIVATE_NOT_POINTER, &page_private(page));
- page_private(page) |= data << PAGE_PRIVATE_MAX;
+ set_page_private_data(page);
+ page_private(page) |= ino << PAGE_PRIVATE_MAX;
}
-static inline void clear_page_private_data(struct page *page)
+static inline void clear_page_private_ino(struct page *page)
{
page_private(page) &= GENMASK(PAGE_PRIVATE_MAX - 1, 0);
- if (page_private(page) == BIT(PAGE_PRIVATE_NOT_POINTER)) {
- set_page_private(page, 0);
- if (PagePrivate(page)) {
- ClearPagePrivate(page);
- put_page(page);
- }
- }
+ clear_page_private_data(page);
}
/* For compression */
--
2.40.0.348.gf938b09366-goog
^ permalink raw reply related
* stable-rc/queue/5.4 baseline: 166 runs, 29 regressions (v5.4.238-109-g98dfb0f6675c)
From: kernelci.org bot @ 2023-04-05 20:14 UTC (permalink / raw)
To: stable, kernel-build-reports, kernelci-results
stable-rc/queue/5.4 baseline: 166 runs, 29 regressions (v5.4.238-109-g98dfb0f6675c)
Regressions Summary
-------------------
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+---------------+----------+------------------------------+------------
cubietruck | arm | lab-baylibre | gcc-10 | multi_v7_defconfig | 1
hifive-unleashed-a00 | riscv | lab-baylibre | gcc-10 | defconfig | 1
hp-x360-12b-c...4020-octopus | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1
hp-x360-14-G1-sona | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1
qemu_arm64-virt-gicv2 | arm64 | lab-baylibre | gcc-10 | defconfig+arm64-chromebook | 1
qemu_arm64-virt-gicv2 | arm64 | lab-baylibre | gcc-10 | defconfig | 1
qemu_arm64-virt-gicv2 | arm64 | lab-broonie | gcc-10 | defconfig+arm64-chromebook | 1
qemu_arm64-virt-gicv2 | arm64 | lab-broonie | gcc-10 | defconfig | 1
qemu_arm64-virt-gicv2 | arm64 | lab-collabora | gcc-10 | defconfig+arm64-chromebook | 1
qemu_arm64-virt-gicv2 | arm64 | lab-collabora | gcc-10 | defconfig | 1
qemu_arm64-virt-gicv2-uefi | arm64 | lab-baylibre | gcc-10 | defconfig+arm64-chromebook | 1
qemu_arm64-virt-gicv2-uefi | arm64 | lab-baylibre | gcc-10 | defconfig | 1
qemu_arm64-virt-gicv2-uefi | arm64 | lab-broonie | gcc-10 | defconfig+arm64-chromebook | 1
qemu_arm64-virt-gicv2-uefi | arm64 | lab-broonie | gcc-10 | defconfig | 1
qemu_arm64-virt-gicv2-uefi | arm64 | lab-collabora | gcc-10 | defconfig+arm64-chromebook | 1
qemu_arm64-virt-gicv2-uefi | arm64 | lab-collabora | gcc-10 | defconfig | 1
qemu_arm64-virt-gicv3 | arm64 | lab-baylibre | gcc-10 | defconfig+arm64-chromebook | 1
qemu_arm64-virt-gicv3 | arm64 | lab-baylibre | gcc-10 | defconfig | 1
qemu_arm64-virt-gicv3 | arm64 | lab-broonie | gcc-10 | defconfig+arm64-chromebook | 1
qemu_arm64-virt-gicv3 | arm64 | lab-broonie | gcc-10 | defconfig | 1
qemu_arm64-virt-gicv3 | arm64 | lab-collabora | gcc-10 | defconfig+arm64-chromebook | 1
qemu_arm64-virt-gicv3 | arm64 | lab-collabora | gcc-10 | defconfig | 1
qemu_arm64-virt-gicv3-uefi | arm64 | lab-baylibre | gcc-10 | defconfig+arm64-chromebook | 1
qemu_arm64-virt-gicv3-uefi | arm64 | lab-baylibre | gcc-10 | defconfig | 1
qemu_arm64-virt-gicv3-uefi | arm64 | lab-broonie | gcc-10 | defconfig+arm64-chromebook | 1
qemu_arm64-virt-gicv3-uefi | arm64 | lab-broonie | gcc-10 | defconfig | 1
qemu_arm64-virt-gicv3-uefi | arm64 | lab-collabora | gcc-10 | defconfig+arm64-chromebook | 1
qemu_arm64-virt-gicv3-uefi | arm64 | lab-collabora | gcc-10 | defconfig | 1
sun8i-h3-libretech-all-h3-cc | arm | lab-baylibre | gcc-10 | multi_v7_defconfig | 1
Details: https://kernelci.org/test/job/stable-rc/branch/queue%2F5.4/kernel/v5.4.238-109-g98dfb0f6675c/plan/baseline/
Test: baseline
Tree: stable-rc
Branch: queue/5.4
Describe: v5.4.238-109-g98dfb0f6675c
URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
SHA: 98dfb0f6675c358d8a7f4a01c6f2e42c365bb557
Test Regressions
----------------
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+---------------+----------+------------------------------+------------
cubietruck | arm | lab-baylibre | gcc-10 | multi_v7_defconfig | 1
Details: https://kernelci.org/test/plan/id/642da4a022e264624f79e999
Results: 5 PASS, 1 FAIL, 1 SKIP
Full config: multi_v7_defconfig
Compiler: gcc-10 (arm-linux-gnueabihf-gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//stable-rc/queue-5.4/v5.4.238-109-g98dfb0f6675c/arm/multi_v7_defconfig/gcc-10/lab-baylibre/baseline-cubietruck.txt
HTML log: https://storage.kernelci.org//stable-rc/queue-5.4/v5.4.238-109-g98dfb0f6675c/arm/multi_v7_defconfig/gcc-10/lab-baylibre/baseline-cubietruck.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230324.0/armel/rootfs.cpio.gz
* baseline.bootrr.deferred-probe-empty: https://kernelci.org/test/case/id/642da4a022e264624f79e99e
failing since 65 days (last pass: v5.4.230-81-g2ad0dc06d587, first fail: v5.4.230-108-g761a8268d868)
2023-04-05T16:40:45.489658 <8>[ 9.870939] <LAVA_SIGNAL_ENDRUN 0_dmesg 3473986_1.5.2.4.1>
2023-04-05T16:40:45.599283 / # #
2023-04-05T16:40:45.702928 export SHELL=/bin/sh
2023-04-05T16:40:45.704065 #
2023-04-05T16:40:45.806439 / # export SHELL=/bin/sh. /lava-3473986/environment
2023-04-05T16:40:45.807555
2023-04-05T16:40:45.910024 / # . /lava-3473986/environment/lava-3473986/bin/lava-test-runner /lava-3473986/1
2023-04-05T16:40:45.911582
2023-04-05T16:40:45.917094 / # /lava-3473986/bin/lava-test-runner /lava-3473986/1
2023-04-05T16:40:46.001344 + export 'TESTRUN_ID=1_bootrr'
... (11 line(s) more)
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+---------------+----------+------------------------------+------------
hifive-unleashed-a00 | riscv | lab-baylibre | gcc-10 | defconfig | 1
Details: https://kernelci.org/test/plan/id/642da1ae18748d8ba679e946
Results: 3 PASS, 2 FAIL, 2 SKIP
Full config: defconfig
Compiler: gcc-10 (riscv64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//stable-rc/queue-5.4/v5.4.238-109-g98dfb0f6675c/riscv/defconfig/gcc-10/lab-baylibre/baseline-hifive-unleashed-a00.txt
HTML log: https://storage.kernelci.org//stable-rc/queue-5.4/v5.4.238-109-g98dfb0f6675c/riscv/defconfig/gcc-10/lab-baylibre/baseline-hifive-unleashed-a00.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230324.0/riscv/rootfs.cpio.gz
* baseline.dmesg.crit: https://kernelci.org/test/case/id/642da1ae18748d8ba679e94f
failing since 168 days (last pass: v5.4.219-270-gde284a6cd1e4, first fail: v5.4.219-266-g5eb28a6c7901)
3 lines
2023-04-05T16:28:04.967626 / #
2023-04-05T16:28:04.978531
2023-04-05T16:28:05.081703 / # #
2023-04-05T16:28:05.090509 #
2023-04-05T16:28:05.191913 / # export SHELL=/bin/sh
2023-04-05T16:28:05.202530 export SHELL=/bin/sh
2023-04-05T16:28:05.303778 / # . /lava-3473955/environment
2023-04-05T16:28:05.314424 . /lava-3473955/environment
2023-04-05T16:28:05.415706 / # /lava-3473955/bin/lava-test-runner /lava-3473955/0
2023-04-05T16:28:05.426593 /lava-3473955/bin/lava-test-runner /lava-3473955/0
... (11 line(s) more)
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+---------------+----------+------------------------------+------------
hp-x360-12b-c...4020-octopus | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1
Details: https://kernelci.org/test/plan/id/642da3482a7b8e4c9f79e93c
Results: 5 PASS, 1 FAIL, 1 SKIP
Full config: x86_64_defconfig+x86-chromebook
Compiler: gcc-10 (gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//stable-rc/queue-5.4/v5.4.238-109-g98dfb0f6675c/x86_64/x86_64_defconfig+x86-chromebook/gcc-10/lab-collabora/baseline-hp-x360-12b-ca0010nr-n4020-octopus.txt
HTML log: https://storage.kernelci.org//stable-rc/queue-5.4/v5.4.238-109-g98dfb0f6675c/x86_64/x86_64_defconfig+x86-chromebook/gcc-10/lab-collabora/baseline-hp-x360-12b-ca0010nr-n4020-octopus.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230324.0/x86/rootfs.cpio.gz
* baseline.bootrr.deferred-probe-empty: https://kernelci.org/test/case/id/642da3482a7b8e4c9f79e941
failing since 7 days (last pass: v5.4.238-29-g39c31e43e3b2b, first fail: v5.4.238-60-gcf51829325af)
2023-04-05T16:35:00.313136 + set<8>[ 7.826154] <LAVA_SIGNAL_ENDRUN 0_dmesg 9884227_1.4.2.3.1>
2023-04-05T16:35:00.313231 +x
2023-04-05T16:35:00.415369 /#
2023-04-05T16:35:00.516601 # #export SHELL=/bin/sh
2023-04-05T16:35:00.516816
2023-04-05T16:35:00.617598 / # export SHELL=/bin/sh. /lava-9884227/environment
2023-04-05T16:35:00.617838
2023-04-05T16:35:00.718785 / # . /lava-9884227/environment/lava-9884227/bin/lava-test-runner /lava-9884227/1
2023-04-05T16:35:00.719107
2023-04-05T16:35:00.724264 / # /lava-9884227/bin/lava-test-runner /lava-9884227/1
... (12 line(s) more)
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+---------------+----------+------------------------------+------------
hp-x360-14-G1-sona | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1
Details: https://kernelci.org/test/plan/id/642da323efc4cab97379e955
Results: 5 PASS, 1 FAIL, 1 SKIP
Full config: x86_64_defconfig+x86-chromebook
Compiler: gcc-10 (gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//stable-rc/queue-5.4/v5.4.238-109-g98dfb0f6675c/x86_64/x86_64_defconfig+x86-chromebook/gcc-10/lab-collabora/baseline-hp-x360-14-G1-sona.txt
HTML log: https://storage.kernelci.org//stable-rc/queue-5.4/v5.4.238-109-g98dfb0f6675c/x86_64/x86_64_defconfig+x86-chromebook/gcc-10/lab-collabora/baseline-hp-x360-14-G1-sona.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230324.0/x86/rootfs.cpio.gz
* baseline.bootrr.deferred-probe-empty: https://kernelci.org/test/case/id/642da323efc4cab97379e95a
failing since 7 days (last pass: v5.4.238-29-g39c31e43e3b2b, first fail: v5.4.238-60-gcf51829325af)
2023-04-05T16:34:25.195354 + set +x<8>[ 12.284848] <LAVA_SIGNAL_ENDRUN 0_dmesg 9884251_1.4.2.3.1>
2023-04-05T16:34:25.195446
2023-04-05T16:34:25.297746 #
2023-04-05T16:34:25.399030 / # #export SHELL=/bin/sh
2023-04-05T16:34:25.399233
2023-04-05T16:34:25.500118 / # export SHELL=/bin/sh. /lava-9884251/environment
2023-04-05T16:34:25.500307
2023-04-05T16:34:25.601188 / # . /lava-9884251/environment/lava-9884251/bin/lava-test-runner /lava-9884251/1
2023-04-05T16:34:25.601511
2023-04-05T16:34:25.606503 / # /lava-9884251/bin/lava-test-runner /lava-9884251/1
... (12 line(s) more)
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+---------------+----------+------------------------------+------------
qemu_arm64-virt-gicv2 | arm64 | lab-baylibre | gcc-10 | defconfig+arm64-chromebook | 1
Details: https://kernelci.org/test/plan/id/642da5c653d0b65f8d79e982
Results: 0 PASS, 1 FAIL, 0 SKIP
Full config: defconfig+arm64-chromebook
Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//stable-rc/queue-5.4/v5.4.238-109-g98dfb0f6675c/arm64/defconfig+arm64-chromebook/gcc-10/lab-baylibre/baseline-qemu_arm64-virt-gicv2.txt
HTML log: https://storage.kernelci.org//stable-rc/queue-5.4/v5.4.238-109-g98dfb0f6675c/arm64/defconfig+arm64-chromebook/gcc-10/lab-baylibre/baseline-qemu_arm64-virt-gicv2.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230324.0/arm64/rootfs.cpio.gz
* baseline.login: https://kernelci.org/test/case/id/642da5c653d0b65f8d79e983
failing since 330 days (last pass: v5.4.191-84-g56ce42d78d96, first fail: v5.4.191-125-g5917d1547e6e)
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+---------------+----------+------------------------------+------------
qemu_arm64-virt-gicv2 | arm64 | lab-baylibre | gcc-10 | defconfig | 1
Details: https://kernelci.org/test/plan/id/642da68ba283afe01a79e938
Results: 0 PASS, 1 FAIL, 0 SKIP
Full config: defconfig
Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//stable-rc/queue-5.4/v5.4.238-109-g98dfb0f6675c/arm64/defconfig/gcc-10/lab-baylibre/baseline-qemu_arm64-virt-gicv2.txt
HTML log: https://storage.kernelci.org//stable-rc/queue-5.4/v5.4.238-109-g98dfb0f6675c/arm64/defconfig/gcc-10/lab-baylibre/baseline-qemu_arm64-virt-gicv2.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230324.0/arm64/rootfs.cpio.gz
* baseline.login: https://kernelci.org/test/case/id/642da68ba283afe01a79e939
failing since 330 days (last pass: v5.4.191-77-g1a3b249e415b, first fail: v5.4.191-125-g5917d1547e6e)
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+---------------+----------+------------------------------+------------
qemu_arm64-virt-gicv2 | arm64 | lab-broonie | gcc-10 | defconfig+arm64-chromebook | 1
Details: https://kernelci.org/test/plan/id/642da9f1ffbd374d2f79e989
Results: 0 PASS, 1 FAIL, 0 SKIP
Full config: defconfig+arm64-chromebook
Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//stable-rc/queue-5.4/v5.4.238-109-g98dfb0f6675c/arm64/defconfig+arm64-chromebook/gcc-10/lab-broonie/baseline-qemu_arm64-virt-gicv2.txt
HTML log: https://storage.kernelci.org//stable-rc/queue-5.4/v5.4.238-109-g98dfb0f6675c/arm64/defconfig+arm64-chromebook/gcc-10/lab-broonie/baseline-qemu_arm64-virt-gicv2.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230324.0/arm64/rootfs.cpio.gz
* baseline.login: https://kernelci.org/test/case/id/642da9f1ffbd374d2f79e98a
failing since 330 days (last pass: v5.4.191-84-g56ce42d78d96, first fail: v5.4.191-125-g5917d1547e6e)
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+---------------+----------+------------------------------+------------
qemu_arm64-virt-gicv2 | arm64 | lab-broonie | gcc-10 | defconfig | 1
Details: https://kernelci.org/test/plan/id/642daa06ae81d2c35b79e92c
Results: 0 PASS, 1 FAIL, 0 SKIP
Full config: defconfig
Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//stable-rc/queue-5.4/v5.4.238-109-g98dfb0f6675c/arm64/defconfig/gcc-10/lab-broonie/baseline-qemu_arm64-virt-gicv2.txt
HTML log: https://storage.kernelci.org//stable-rc/queue-5.4/v5.4.238-109-g98dfb0f6675c/arm64/defconfig/gcc-10/lab-broonie/baseline-qemu_arm64-virt-gicv2.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230324.0/arm64/rootfs.cpio.gz
* baseline.login: https://kernelci.org/test/case/id/642daa06ae81d2c35b79e92d
failing since 330 days (last pass: v5.4.191-77-g1a3b249e415b, first fail: v5.4.191-125-g5917d1547e6e)
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+---------------+----------+------------------------------+------------
qemu_arm64-virt-gicv2 | arm64 | lab-collabora | gcc-10 | defconfig+arm64-chromebook | 1
Details: https://kernelci.org/test/plan/id/642da64ef47ed2103779e9fb
Results: 0 PASS, 1 FAIL, 0 SKIP
Full config: defconfig+arm64-chromebook
Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//stable-rc/queue-5.4/v5.4.238-109-g98dfb0f6675c/arm64/defconfig+arm64-chromebook/gcc-10/lab-collabora/baseline-qemu_arm64-virt-gicv2.txt
HTML log: https://storage.kernelci.org//stable-rc/queue-5.4/v5.4.238-109-g98dfb0f6675c/arm64/defconfig+arm64-chromebook/gcc-10/lab-collabora/baseline-qemu_arm64-virt-gicv2.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230324.0/arm64/rootfs.cpio.gz
* baseline.login: https://kernelci.org/test/case/id/642da64ef47ed2103779e9fc
failing since 330 days (last pass: v5.4.191-84-g56ce42d78d96, first fail: v5.4.191-125-g5917d1547e6e)
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+---------------+----------+------------------------------+------------
qemu_arm64-virt-gicv2 | arm64 | lab-collabora | gcc-10 | defconfig | 1
Details: https://kernelci.org/test/plan/id/642da69e5efd73351a79e923
Results: 0 PASS, 1 FAIL, 0 SKIP
Full config: defconfig
Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//stable-rc/queue-5.4/v5.4.238-109-g98dfb0f6675c/arm64/defconfig/gcc-10/lab-collabora/baseline-qemu_arm64-virt-gicv2.txt
HTML log: https://storage.kernelci.org//stable-rc/queue-5.4/v5.4.238-109-g98dfb0f6675c/arm64/defconfig/gcc-10/lab-collabora/baseline-qemu_arm64-virt-gicv2.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230324.0/arm64/rootfs.cpio.gz
* baseline.login: https://kernelci.org/test/case/id/642da69e5efd73351a79e924
failing since 330 days (last pass: v5.4.191-77-g1a3b249e415b, first fail: v5.4.191-125-g5917d1547e6e)
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+---------------+----------+------------------------------+------------
qemu_arm64-virt-gicv2-uefi | arm64 | lab-baylibre | gcc-10 | defconfig+arm64-chromebook | 1
Details: https://kernelci.org/test/plan/id/642da5c5ae0b6f310379e939
Results: 0 PASS, 1 FAIL, 0 SKIP
Full config: defconfig+arm64-chromebook
Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//stable-rc/queue-5.4/v5.4.238-109-g98dfb0f6675c/arm64/defconfig+arm64-chromebook/gcc-10/lab-baylibre/baseline-qemu_arm64-virt-gicv2-uefi.txt
HTML log: https://storage.kernelci.org//stable-rc/queue-5.4/v5.4.238-109-g98dfb0f6675c/arm64/defconfig+arm64-chromebook/gcc-10/lab-baylibre/baseline-qemu_arm64-virt-gicv2-uefi.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230324.0/arm64/rootfs.cpio.gz
* baseline.login: https://kernelci.org/test/case/id/642da5c5ae0b6f310379e93a
failing since 330 days (last pass: v5.4.191-84-g56ce42d78d96, first fail: v5.4.191-125-g5917d1547e6e)
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+---------------+----------+------------------------------+------------
qemu_arm64-virt-gicv2-uefi | arm64 | lab-baylibre | gcc-10 | defconfig | 1
Details: https://kernelci.org/test/plan/id/642da6b55efd73351a79e9ae
Results: 0 PASS, 1 FAIL, 0 SKIP
Full config: defconfig
Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//stable-rc/queue-5.4/v5.4.238-109-g98dfb0f6675c/arm64/defconfig/gcc-10/lab-baylibre/baseline-qemu_arm64-virt-gicv2-uefi.txt
HTML log: https://storage.kernelci.org//stable-rc/queue-5.4/v5.4.238-109-g98dfb0f6675c/arm64/defconfig/gcc-10/lab-baylibre/baseline-qemu_arm64-virt-gicv2-uefi.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230324.0/arm64/rootfs.cpio.gz
* baseline.login: https://kernelci.org/test/case/id/642da6b55efd73351a79e9af
failing since 330 days (last pass: v5.4.191-77-g1a3b249e415b, first fail: v5.4.191-125-g5917d1547e6e)
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+---------------+----------+------------------------------+------------
qemu_arm64-virt-gicv2-uefi | arm64 | lab-broonie | gcc-10 | defconfig+arm64-chromebook | 1
Details: https://kernelci.org/test/plan/id/642da9e0d1732d0a9579e92d
Results: 0 PASS, 1 FAIL, 0 SKIP
Full config: defconfig+arm64-chromebook
Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//stable-rc/queue-5.4/v5.4.238-109-g98dfb0f6675c/arm64/defconfig+arm64-chromebook/gcc-10/lab-broonie/baseline-qemu_arm64-virt-gicv2-uefi.txt
HTML log: https://storage.kernelci.org//stable-rc/queue-5.4/v5.4.238-109-g98dfb0f6675c/arm64/defconfig+arm64-chromebook/gcc-10/lab-broonie/baseline-qemu_arm64-virt-gicv2-uefi.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230324.0/arm64/rootfs.cpio.gz
* baseline.login: https://kernelci.org/test/case/id/642da9e0d1732d0a9579e92e
failing since 330 days (last pass: v5.4.191-84-g56ce42d78d96, first fail: v5.4.191-125-g5917d1547e6e)
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+---------------+----------+------------------------------+------------
qemu_arm64-virt-gicv2-uefi | arm64 | lab-broonie | gcc-10 | defconfig | 1
Details: https://kernelci.org/test/plan/id/642dab45a1f8674d3679e929
Results: 0 PASS, 1 FAIL, 0 SKIP
Full config: defconfig
Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//stable-rc/queue-5.4/v5.4.238-109-g98dfb0f6675c/arm64/defconfig/gcc-10/lab-broonie/baseline-qemu_arm64-virt-gicv2-uefi.txt
HTML log: https://storage.kernelci.org//stable-rc/queue-5.4/v5.4.238-109-g98dfb0f6675c/arm64/defconfig/gcc-10/lab-broonie/baseline-qemu_arm64-virt-gicv2-uefi.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230324.0/arm64/rootfs.cpio.gz
* baseline.login: https://kernelci.org/test/case/id/642dab45a1f8674d3679e92a
failing since 330 days (last pass: v5.4.191-77-g1a3b249e415b, first fail: v5.4.191-125-g5917d1547e6e)
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+---------------+----------+------------------------------+------------
qemu_arm64-virt-gicv2-uefi | arm64 | lab-collabora | gcc-10 | defconfig+arm64-chromebook | 1
Details: https://kernelci.org/test/plan/id/642da5de12fec6bd7179e927
Results: 0 PASS, 1 FAIL, 0 SKIP
Full config: defconfig+arm64-chromebook
Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//stable-rc/queue-5.4/v5.4.238-109-g98dfb0f6675c/arm64/defconfig+arm64-chromebook/gcc-10/lab-collabora/baseline-qemu_arm64-virt-gicv2-uefi.txt
HTML log: https://storage.kernelci.org//stable-rc/queue-5.4/v5.4.238-109-g98dfb0f6675c/arm64/defconfig+arm64-chromebook/gcc-10/lab-collabora/baseline-qemu_arm64-virt-gicv2-uefi.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230324.0/arm64/rootfs.cpio.gz
* baseline.login: https://kernelci.org/test/case/id/642da5de12fec6bd7179e928
failing since 330 days (last pass: v5.4.191-84-g56ce42d78d96, first fail: v5.4.191-125-g5917d1547e6e)
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+---------------+----------+------------------------------+------------
qemu_arm64-virt-gicv2-uefi | arm64 | lab-collabora | gcc-10 | defconfig | 1
Details: https://kernelci.org/test/plan/id/642da6ce3f15ddbadc79e94b
Results: 0 PASS, 1 FAIL, 0 SKIP
Full config: defconfig
Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//stable-rc/queue-5.4/v5.4.238-109-g98dfb0f6675c/arm64/defconfig/gcc-10/lab-collabora/baseline-qemu_arm64-virt-gicv2-uefi.txt
HTML log: https://storage.kernelci.org//stable-rc/queue-5.4/v5.4.238-109-g98dfb0f6675c/arm64/defconfig/gcc-10/lab-collabora/baseline-qemu_arm64-virt-gicv2-uefi.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230324.0/arm64/rootfs.cpio.gz
* baseline.login: https://kernelci.org/test/case/id/642da6ce3f15ddbadc79e94c
failing since 330 days (last pass: v5.4.191-77-g1a3b249e415b, first fail: v5.4.191-125-g5917d1547e6e)
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+---------------+----------+------------------------------+------------
qemu_arm64-virt-gicv3 | arm64 | lab-baylibre | gcc-10 | defconfig+arm64-chromebook | 1
Details: https://kernelci.org/test/plan/id/642da5c253d0b65f8d79e972
Results: 0 PASS, 1 FAIL, 0 SKIP
Full config: defconfig+arm64-chromebook
Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//stable-rc/queue-5.4/v5.4.238-109-g98dfb0f6675c/arm64/defconfig+arm64-chromebook/gcc-10/lab-baylibre/baseline-qemu_arm64-virt-gicv3.txt
HTML log: https://storage.kernelci.org//stable-rc/queue-5.4/v5.4.238-109-g98dfb0f6675c/arm64/defconfig+arm64-chromebook/gcc-10/lab-baylibre/baseline-qemu_arm64-virt-gicv3.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230324.0/arm64/rootfs.cpio.gz
* baseline.login: https://kernelci.org/test/case/id/642da5c253d0b65f8d79e973
failing since 330 days (last pass: v5.4.191-84-g56ce42d78d96, first fail: v5.4.191-125-g5917d1547e6e)
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+---------------+----------+------------------------------+------------
qemu_arm64-virt-gicv3 | arm64 | lab-baylibre | gcc-10 | defconfig | 1
Details: https://kernelci.org/test/plan/id/642da68ae40132689a79e973
Results: 0 PASS, 1 FAIL, 0 SKIP
Full config: defconfig
Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//stable-rc/queue-5.4/v5.4.238-109-g98dfb0f6675c/arm64/defconfig/gcc-10/lab-baylibre/baseline-qemu_arm64-virt-gicv3.txt
HTML log: https://storage.kernelci.org//stable-rc/queue-5.4/v5.4.238-109-g98dfb0f6675c/arm64/defconfig/gcc-10/lab-baylibre/baseline-qemu_arm64-virt-gicv3.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230324.0/arm64/rootfs.cpio.gz
* baseline.login: https://kernelci.org/test/case/id/642da68ae40132689a79e974
failing since 253 days (last pass: v5.4.180-77-g7de29e82b9db, first fail: v5.4.207-73-ga2480f1b1dda1)
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+---------------+----------+------------------------------+------------
qemu_arm64-virt-gicv3 | arm64 | lab-broonie | gcc-10 | defconfig+arm64-chromebook | 1
Details: https://kernelci.org/test/plan/id/642da9dd46aa31d12479e982
Results: 0 PASS, 1 FAIL, 0 SKIP
Full config: defconfig+arm64-chromebook
Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//stable-rc/queue-5.4/v5.4.238-109-g98dfb0f6675c/arm64/defconfig+arm64-chromebook/gcc-10/lab-broonie/baseline-qemu_arm64-virt-gicv3.txt
HTML log: https://storage.kernelci.org//stable-rc/queue-5.4/v5.4.238-109-g98dfb0f6675c/arm64/defconfig+arm64-chromebook/gcc-10/lab-broonie/baseline-qemu_arm64-virt-gicv3.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230324.0/arm64/rootfs.cpio.gz
* baseline.login: https://kernelci.org/test/case/id/642da9dd46aa31d12479e983
failing since 330 days (last pass: v5.4.191-84-g56ce42d78d96, first fail: v5.4.191-125-g5917d1547e6e)
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+---------------+----------+------------------------------+------------
qemu_arm64-virt-gicv3 | arm64 | lab-broonie | gcc-10 | defconfig | 1
Details: https://kernelci.org/test/plan/id/642daa05fa5f1cf25779e933
Results: 0 PASS, 1 FAIL, 0 SKIP
Full config: defconfig
Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//stable-rc/queue-5.4/v5.4.238-109-g98dfb0f6675c/arm64/defconfig/gcc-10/lab-broonie/baseline-qemu_arm64-virt-gicv3.txt
HTML log: https://storage.kernelci.org//stable-rc/queue-5.4/v5.4.238-109-g98dfb0f6675c/arm64/defconfig/gcc-10/lab-broonie/baseline-qemu_arm64-virt-gicv3.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230324.0/arm64/rootfs.cpio.gz
* baseline.login: https://kernelci.org/test/case/id/642daa05fa5f1cf25779e934
failing since 253 days (last pass: v5.4.180-77-g7de29e82b9db, first fail: v5.4.207-73-ga2480f1b1dda1)
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+---------------+----------+------------------------------+------------
qemu_arm64-virt-gicv3 | arm64 | lab-collabora | gcc-10 | defconfig+arm64-chromebook | 1
Details: https://kernelci.org/test/plan/id/642da5d6d18edf47ae79e954
Results: 0 PASS, 1 FAIL, 0 SKIP
Full config: defconfig+arm64-chromebook
Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//stable-rc/queue-5.4/v5.4.238-109-g98dfb0f6675c/arm64/defconfig+arm64-chromebook/gcc-10/lab-collabora/baseline-qemu_arm64-virt-gicv3.txt
HTML log: https://storage.kernelci.org//stable-rc/queue-5.4/v5.4.238-109-g98dfb0f6675c/arm64/defconfig+arm64-chromebook/gcc-10/lab-collabora/baseline-qemu_arm64-virt-gicv3.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230324.0/arm64/rootfs.cpio.gz
* baseline.login: https://kernelci.org/test/case/id/642da5d6d18edf47ae79e955
failing since 330 days (last pass: v5.4.191-84-g56ce42d78d96, first fail: v5.4.191-125-g5917d1547e6e)
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+---------------+----------+------------------------------+------------
qemu_arm64-virt-gicv3 | arm64 | lab-collabora | gcc-10 | defconfig | 1
Details: https://kernelci.org/test/plan/id/642da68ae40132689a79e976
Results: 0 PASS, 1 FAIL, 0 SKIP
Full config: defconfig
Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//stable-rc/queue-5.4/v5.4.238-109-g98dfb0f6675c/arm64/defconfig/gcc-10/lab-collabora/baseline-qemu_arm64-virt-gicv3.txt
HTML log: https://storage.kernelci.org//stable-rc/queue-5.4/v5.4.238-109-g98dfb0f6675c/arm64/defconfig/gcc-10/lab-collabora/baseline-qemu_arm64-virt-gicv3.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230324.0/arm64/rootfs.cpio.gz
* baseline.login: https://kernelci.org/test/case/id/642da68ae40132689a79e977
failing since 253 days (last pass: v5.4.180-77-g7de29e82b9db, first fail: v5.4.207-73-ga2480f1b1dda1)
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+---------------+----------+------------------------------+------------
qemu_arm64-virt-gicv3-uefi | arm64 | lab-baylibre | gcc-10 | defconfig+arm64-chromebook | 1
Details: https://kernelci.org/test/plan/id/642da5c3ae0b6f310379e936
Results: 0 PASS, 1 FAIL, 0 SKIP
Full config: defconfig+arm64-chromebook
Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//stable-rc/queue-5.4/v5.4.238-109-g98dfb0f6675c/arm64/defconfig+arm64-chromebook/gcc-10/lab-baylibre/baseline-qemu_arm64-virt-gicv3-uefi.txt
HTML log: https://storage.kernelci.org//stable-rc/queue-5.4/v5.4.238-109-g98dfb0f6675c/arm64/defconfig+arm64-chromebook/gcc-10/lab-baylibre/baseline-qemu_arm64-virt-gicv3-uefi.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230324.0/arm64/rootfs.cpio.gz
* baseline.login: https://kernelci.org/test/case/id/642da5c3ae0b6f310379e937
failing since 330 days (last pass: v5.4.191-84-g56ce42d78d96, first fail: v5.4.191-125-g5917d1547e6e)
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+---------------+----------+------------------------------+------------
qemu_arm64-virt-gicv3-uefi | arm64 | lab-baylibre | gcc-10 | defconfig | 1
Details: https://kernelci.org/test/plan/id/642da6b73f15ddbadc79e924
Results: 0 PASS, 1 FAIL, 0 SKIP
Full config: defconfig
Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//stable-rc/queue-5.4/v5.4.238-109-g98dfb0f6675c/arm64/defconfig/gcc-10/lab-baylibre/baseline-qemu_arm64-virt-gicv3-uefi.txt
HTML log: https://storage.kernelci.org//stable-rc/queue-5.4/v5.4.238-109-g98dfb0f6675c/arm64/defconfig/gcc-10/lab-baylibre/baseline-qemu_arm64-virt-gicv3-uefi.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230324.0/arm64/rootfs.cpio.gz
* baseline.login: https://kernelci.org/test/case/id/642da6b73f15ddbadc79e925
failing since 330 days (last pass: v5.4.191-77-g1a3b249e415b, first fail: v5.4.191-125-g5917d1547e6e)
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+---------------+----------+------------------------------+------------
qemu_arm64-virt-gicv3-uefi | arm64 | lab-broonie | gcc-10 | defconfig+arm64-chromebook | 1
Details: https://kernelci.org/test/plan/id/642da9dea844f11d4679e922
Results: 0 PASS, 1 FAIL, 0 SKIP
Full config: defconfig+arm64-chromebook
Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//stable-rc/queue-5.4/v5.4.238-109-g98dfb0f6675c/arm64/defconfig+arm64-chromebook/gcc-10/lab-broonie/baseline-qemu_arm64-virt-gicv3-uefi.txt
HTML log: https://storage.kernelci.org//stable-rc/queue-5.4/v5.4.238-109-g98dfb0f6675c/arm64/defconfig+arm64-chromebook/gcc-10/lab-broonie/baseline-qemu_arm64-virt-gicv3-uefi.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230324.0/arm64/rootfs.cpio.gz
* baseline.login: https://kernelci.org/test/case/id/642da9dea844f11d4679e923
failing since 330 days (last pass: v5.4.191-84-g56ce42d78d96, first fail: v5.4.191-125-g5917d1547e6e)
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+---------------+----------+------------------------------+------------
qemu_arm64-virt-gicv3-uefi | arm64 | lab-broonie | gcc-10 | defconfig | 1
Details: https://kernelci.org/test/plan/id/642dab5912e86ffac279e93e
Results: 0 PASS, 1 FAIL, 0 SKIP
Full config: defconfig
Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//stable-rc/queue-5.4/v5.4.238-109-g98dfb0f6675c/arm64/defconfig/gcc-10/lab-broonie/baseline-qemu_arm64-virt-gicv3-uefi.txt
HTML log: https://storage.kernelci.org//stable-rc/queue-5.4/v5.4.238-109-g98dfb0f6675c/arm64/defconfig/gcc-10/lab-broonie/baseline-qemu_arm64-virt-gicv3-uefi.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230324.0/arm64/rootfs.cpio.gz
* baseline.login: https://kernelci.org/test/case/id/642dab5912e86ffac279e93f
failing since 330 days (last pass: v5.4.191-77-g1a3b249e415b, first fail: v5.4.191-125-g5917d1547e6e)
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+---------------+----------+------------------------------+------------
qemu_arm64-virt-gicv3-uefi | arm64 | lab-collabora | gcc-10 | defconfig+arm64-chromebook | 1
Details: https://kernelci.org/test/plan/id/642da5ea12fec6bd7179e946
Results: 0 PASS, 1 FAIL, 0 SKIP
Full config: defconfig+arm64-chromebook
Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//stable-rc/queue-5.4/v5.4.238-109-g98dfb0f6675c/arm64/defconfig+arm64-chromebook/gcc-10/lab-collabora/baseline-qemu_arm64-virt-gicv3-uefi.txt
HTML log: https://storage.kernelci.org//stable-rc/queue-5.4/v5.4.238-109-g98dfb0f6675c/arm64/defconfig+arm64-chromebook/gcc-10/lab-collabora/baseline-qemu_arm64-virt-gicv3-uefi.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230324.0/arm64/rootfs.cpio.gz
* baseline.login: https://kernelci.org/test/case/id/642da5ea12fec6bd7179e947
failing since 330 days (last pass: v5.4.191-84-g56ce42d78d96, first fail: v5.4.191-125-g5917d1547e6e)
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+---------------+----------+------------------------------+------------
qemu_arm64-virt-gicv3-uefi | arm64 | lab-collabora | gcc-10 | defconfig | 1
Details: https://kernelci.org/test/plan/id/642da6eed91c2c3e4279e97b
Results: 0 PASS, 1 FAIL, 0 SKIP
Full config: defconfig
Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//stable-rc/queue-5.4/v5.4.238-109-g98dfb0f6675c/arm64/defconfig/gcc-10/lab-collabora/baseline-qemu_arm64-virt-gicv3-uefi.txt
HTML log: https://storage.kernelci.org//stable-rc/queue-5.4/v5.4.238-109-g98dfb0f6675c/arm64/defconfig/gcc-10/lab-collabora/baseline-qemu_arm64-virt-gicv3-uefi.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230324.0/arm64/rootfs.cpio.gz
* baseline.login: https://kernelci.org/test/case/id/642da6eed91c2c3e4279e97c
failing since 330 days (last pass: v5.4.191-77-g1a3b249e415b, first fail: v5.4.191-125-g5917d1547e6e)
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+---------------+----------+------------------------------+------------
sun8i-h3-libretech-all-h3-cc | arm | lab-baylibre | gcc-10 | multi_v7_defconfig | 1
Details: https://kernelci.org/test/plan/id/642da48953de883d2e79e922
Results: 5 PASS, 1 FAIL, 1 SKIP
Full config: multi_v7_defconfig
Compiler: gcc-10 (arm-linux-gnueabihf-gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//stable-rc/queue-5.4/v5.4.238-109-g98dfb0f6675c/arm/multi_v7_defconfig/gcc-10/lab-baylibre/baseline-sun8i-h3-libretech-all-h3-cc.txt
HTML log: https://storage.kernelci.org//stable-rc/queue-5.4/v5.4.238-109-g98dfb0f6675c/arm/multi_v7_defconfig/gcc-10/lab-baylibre/baseline-sun8i-h3-libretech-all-h3-cc.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230324.0/armel/rootfs.cpio.gz
* baseline.bootrr.deferred-probe-empty: https://kernelci.org/test/case/id/642da48953de883d2e79e927
failing since 63 days (last pass: v5.4.230-108-g761a8268d868, first fail: v5.4.230-109-g0a6085bff265)
2023-04-05T16:40:16.273425 / # #
2023-04-05T16:40:16.375172 export SHELL=/bin/sh
2023-04-05T16:40:16.375524 #
2023-04-05T16:40:16.476844 / # export SHELL=/bin/sh. /lava-3473996/environment
2023-04-05T16:40:16.477194
2023-04-05T16:40:16.578546 / # . /lava-3473996/environment/lava-3473996/bin/lava-test-runner /lava-3473996/1
2023-04-05T16:40:16.579182
2023-04-05T16:40:16.584383 / # /lava-3473996/bin/lava-test-runner /lava-3473996/1
2023-04-05T16:40:16.648607 + export 'TESTRUN_ID=1_bootrr'
2023-04-05T16:40:16.688210 + cd /lava-3473996/1/tests/1_bootrr
... (10 line(s) more)
^ permalink raw reply
* + mm-khugepaged-check-again-on-anon-uffd-wp-during-isolation.patch added to mm-hotfixes-unstable branch
From: Andrew Morton @ 2023-04-05 19:56 UTC (permalink / raw)
To: mm-commits, stable, shy828301, rppt, nadav.amit, david,
axelrasmussen, aarcange, peterx, akpm
The patch titled
Subject: mm/khugepaged: check again on anon uffd-wp during isolation
has been added to the -mm mm-hotfixes-unstable branch. Its filename is
mm-khugepaged-check-again-on-anon-uffd-wp-during-isolation.patch
This patch will shortly appear at
https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/mm-khugepaged-check-again-on-anon-uffd-wp-during-isolation.patch
This patch will later appear in the mm-hotfixes-unstable branch at
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next via the mm-everything
branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
and is updated there every 2-3 working days
------------------------------------------------------
From: Peter Xu <peterx@redhat.com>
Subject: mm/khugepaged: check again on anon uffd-wp during isolation
Date: Wed, 5 Apr 2023 11:51:20 -0400
Khugepaged collapse an anonymous thp in two rounds of scans. The 2nd
round done in __collapse_huge_page_isolate() after
hpage_collapse_scan_pmd(), during which all the locks will be released
temporarily. It means the pgtable can change during this phase before 2nd
round starts.
It's logically possible some ptes got wr-protected during this phase, and
we can errornously collapse a thp without noticing some ptes are
wr-protected by userfault. e1e267c7928f wanted to avoid it but it only
did that for the 1st phase, not the 2nd phase.
Since __collapse_huge_page_isolate() happens after a round of small page
swapins, we don't need to worry on any !present ptes - if it existed
khugepaged will already bail out. So we only need to check present ptes
with uffd-wp bit set there.
This is something I found only but never had a reproducer, I thought it
was one caused a bug in Muhammad's recent pagemap new ioctl work, but it
turns out it's not the cause of that but an userspace bug. However this
seems to still be a real bug even with a very small race window, still
worth to have it fixed and copy stable.
Link: https://lkml.kernel.org/r/20230405155120.3608140-1-peterx@redhat.com
Fixes: e1e267c7928f ("khugepaged: skip collapse if uffd-wp detected")
Signed-off-by: Peter Xu <peterx@redhat.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Yang Shi <shy828301@gmail.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Axel Rasmussen <axelrasmussen@google.com>
Cc: Mike Rapoport <rppt@linux.vnet.ibm.com>
Cc: Nadav Amit <nadav.amit@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/khugepaged.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/mm/khugepaged.c~mm-khugepaged-check-again-on-anon-uffd-wp-during-isolation
+++ a/mm/khugepaged.c
@@ -573,6 +573,10 @@ static int __collapse_huge_page_isolate(
result = SCAN_PTE_NON_PRESENT;
goto out;
}
+ if (pte_uffd_wp(pteval)) {
+ result = SCAN_PTE_UFFD_WP;
+ goto out;
+ }
page = vm_normal_page(vma, address, pteval);
if (unlikely(!page) || unlikely(is_zone_device_page(page))) {
result = SCAN_PAGE_NULL;
_
Patches currently in -mm which might be from peterx@redhat.com are
mm-hugetlb-fix-uffd-wr-protection-for-cow-optimization-path.patch
mm-hugetlb-fix-uffd-wr-protection-for-cow-optimization-path-v2.patch
mm-hugetlb-fix-uffd-wr-protection-for-cow-optimization-path-v3.patch
mm-khugepaged-check-again-on-anon-uffd-wp-during-isolation.patch
mm-uffd-uffd_feature_wp_unpopulated.patch
mm-uffd-uffd_feature_wp_unpopulated-fix.patch
selftests-mm-smoke-test-uffd_feature_wp_unpopulated.patch
^ permalink raw reply
* + mm-userfaultfd-fix-uffd-wp-handling-for-thp-migration-entries.patch added to mm-hotfixes-unstable branch
From: Andrew Morton @ 2023-04-05 19:54 UTC (permalink / raw)
To: mm-commits, usama.anjum, stable, peterx, david, akpm
The patch titled
Subject: mm/userfaultfd: fix uffd-wp handling for THP migration entries
has been added to the -mm mm-hotfixes-unstable branch. Its filename is
mm-userfaultfd-fix-uffd-wp-handling-for-thp-migration-entries.patch
This patch will shortly appear at
https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/mm-userfaultfd-fix-uffd-wp-handling-for-thp-migration-entries.patch
This patch will later appear in the mm-hotfixes-unstable branch at
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next via the mm-everything
branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
and is updated there every 2-3 working days
------------------------------------------------------
From: David Hildenbrand <david@redhat.com>
Subject: mm/userfaultfd: fix uffd-wp handling for THP migration entries
Date: Wed, 5 Apr 2023 18:02:35 +0200
Looks like what we fixed for hugetlb in commit 44f86392bdd1 ("mm/hugetlb:
fix uffd-wp handling for migration entries in
hugetlb_change_protection()") similarly applies to THP.
Setting/clearing uffd-wp on THP migration entries is not implemented
properly. Further, while removing migration PMDs considers the uffd-wp
bit, inserting migration PMDs does not consider the uffd-wp bit.
We have to set/clear independently of the migration entry type in
change_huge_pmd() and properly copy the uffd-wp bit in
set_pmd_migration_entry().
Verified using a simple reproducer that triggers migration of a THP, that
the set_pmd_migration_entry() no longer loses the uffd-wp bit.
Link: https://lkml.kernel.org/r/20230405160236.587705-2-david@redhat.com
Fixes: f45ec5ff16a7 ("userfaultfd: wp: support swap and page migration")
Signed-off-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
Cc: <stable@vger.kernel.org>
Cc: Muhammad Usama Anjum <usama.anjum@collabora.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/huge_memory.c | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
--- a/mm/huge_memory.c~mm-userfaultfd-fix-uffd-wp-handling-for-thp-migration-entries
+++ a/mm/huge_memory.c
@@ -1838,10 +1838,10 @@ int change_huge_pmd(struct mmu_gather *t
if (is_swap_pmd(*pmd)) {
swp_entry_t entry = pmd_to_swp_entry(*pmd);
struct page *page = pfn_swap_entry_to_page(entry);
+ pmd_t newpmd;
VM_BUG_ON(!is_pmd_migration_entry(*pmd));
if (is_writable_migration_entry(entry)) {
- pmd_t newpmd;
/*
* A protection check is difficult so
* just be safe and disable write
@@ -1855,8 +1855,16 @@ int change_huge_pmd(struct mmu_gather *t
newpmd = pmd_swp_mksoft_dirty(newpmd);
if (pmd_swp_uffd_wp(*pmd))
newpmd = pmd_swp_mkuffd_wp(newpmd);
- set_pmd_at(mm, addr, pmd, newpmd);
+ } else {
+ newpmd = *pmd;
}
+
+ if (uffd_wp)
+ newpmd = pmd_swp_mkuffd_wp(newpmd);
+ else if (uffd_wp_resolve)
+ newpmd = pmd_swp_clear_uffd_wp(newpmd);
+ if (!pmd_same(*pmd, newpmd))
+ set_pmd_at(mm, addr, pmd, newpmd);
goto unlock;
}
#endif
@@ -3251,6 +3259,8 @@ int set_pmd_migration_entry(struct page_
pmdswp = swp_entry_to_pmd(entry);
if (pmd_soft_dirty(pmdval))
pmdswp = pmd_swp_mksoft_dirty(pmdswp);
+ if (pmd_uffd_wp(pmdval))
+ pmdswp = pmd_swp_mkuffd_wp(pmdswp);
set_pmd_at(mm, address, pvmw->pmd, pmdswp);
page_remove_rmap(page, vma, true);
put_page(page);
_
Patches currently in -mm which might be from david@redhat.com are
mm-userfaultfd-fix-uffd-wp-handling-for-thp-migration-entries.patch
m68k-mm-use-correct-bit-number-in-_page_swp_exclusive-comment.patch
mm-userfaultfd-dont-consider-uffd-wp-bit-of-writable-migration-entries.patch
^ permalink raw reply
* Re: [PATCH 5.4 000/104] 5.4.240-rc1 review
From: Tom Saeger @ 2023-04-05 19:50 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: stable, patches, linux-kernel, torvalds, akpm, linux, shuah,
patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, srw, rwarsow
In-Reply-To: <2023040516-flirt-provolone-d254@gregkh>
On Wed, Apr 05, 2023 at 11:33:35AM +0200, Greg Kroah-Hartman wrote:
> On Tue, Apr 04, 2023 at 02:33:12PM -0600, Tom Saeger wrote:
> > On Mon, Apr 03, 2023 at 04:07:52PM +0200, Greg Kroah-Hartman wrote:
> > > This is the start of the stable review cycle for the 5.4.240 release.
> > > There are 104 patches in this series, all will be posted as a response
> > > to this one. If anyone has any issues with these being applied, please
> > > let me know.
> > >
> > > Responses should be made by Wed, 05 Apr 2023 14:03:18 +0000.
> > > Anything received after that time might be too late.
> > >
> > > The whole patch series can be found in one patch at:
> > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.240-rc1.gz
> > > or in the git tree and branch at:
> > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.4.y
> > > and the diffstat can be found below.
> > >
> > > thanks,
> > >
> > > greg k-h
> > >
> >
> > Hey Greg,
> >
> > This still reproduces:
> >
> >
> > cp arch/mips/configs/lasat_defconfig .config
> > make ARCH=mips olddefconfig
> > make ARCH=mips
> >
> >
> > .../linux-stable-5.4/arch/mips/lasat/picvue_proc.c:42:44: error: expected ')' before '&' token
> > 42 | static DECLARE_TASKLET(pvc_display_tasklet, &pvc_display, 0);
> > | ^~
> > | )
> > .../linux-stable-5.4/arch/mips/lasat/picvue_proc.c: In function 'pvc_line_proc_write':
> > .../linux-stable-5.4/arch/mips/lasat/picvue_proc.c:87:20: error: 'pvc_display_tasklet' undeclared (first use in this function)
> > 87 | tasklet_schedule(&pvc_display_tasklet);
> > | ^~~~~~~~~~~~~~~~~~~
> > .../linux-stable-5.4/arch/mips/lasat/picvue_proc.c:87:20: note: each undeclared identifier is reported only once for each function it appears in
> > At top level:
> > .../linux-stable-5.4/arch/mips/lasat/picvue_proc.c:33:13: error: 'pvc_display' defined but not used [-Werror=unused-function]
> > 33 | static void pvc_display(unsigned long data)
> > | ^~~~~~~~~~~
> > cc1: all warnings being treated as errors
> >
> > Attached is mbox of fixed-up revert/backports.
>
> Odd that no one else is reporting this. Thanks for the patches, I've
> queued them up for the next 5.4.y release.
>
Found it reported most recently here:
https://lore.kernel.org/stable/642d5611.630a0220.6455f.2988@mx.google.com/
Thanks taking them!
--Tom
^ permalink raw reply
* [PATCH 6.1.y 1/2] drm/display/dp_mst: Handle old/new payload states in drm_dp_remove_payload()
From: Mario Limonciello @ 2023-04-05 19:37 UTC (permalink / raw)
To: stable
In-Reply-To: <20230405193707.8184-1-mario.limonciello@amd.com>
From: Imre Deak <imre.deak@intel.com>
Atm, drm_dp_remove_payload() uses the same payload state to both get the
vc_start_slot required for the payload removal DPCD message and to
deduct time_slots from vc_start_slot of all payloads after the one being
removed.
The above isn't always correct, as vc_start_slot must be the up-to-date
version contained in the new payload state, but time_slots must be the
one used when the payload was previously added, contained in the old
payload state. The new payload's time_slots can change vs. the old one
if the current atomic commit changes the corresponding mode.
This patch let's drivers pass the old and new payload states to
drm_dp_remove_payload(), but keeps these the same for now in all drivers
not to change the behavior. A follow-up i915 patch will pass in that
driver the correct old and new states to the function.
Cc: Lyude Paul <lyude@redhat.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Karol Herbst <kherbst@redhat.com>
Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Wayne Lin <Wayne.Lin@amd.com>
Cc: stable@vger.kernel.org # 6.1
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Acked-by: Lyude Paul <lyude@redhat.com>
Acked-by: Daniel Vetter <daniel@ffwll.ch>
Acked-by: Wayne Lin <wayne.lin@amd.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230206114856.2665066-2-imre.deak@intel.com
(cherry picked from commit e761cc20946a0094df71cb31a565a6a0d03bd8be)
Hand modified for missing 8c7d980da9ba3eb67a1b40fd4b33bcf49397084b
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
---
.../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 2 +-
drivers/gpu/drm/display/drm_dp_mst_topology.c | 26 ++++++++++---------
drivers/gpu/drm/i915/display/intel_dp_mst.c | 4 ++-
drivers/gpu/drm/nouveau/dispnv50/disp.c | 2 +-
include/drm/display/drm_dp_mst_helper.h | 3 ++-
5 files changed, 21 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
index 57454967617f..6bd7e4537014 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
@@ -206,7 +206,7 @@ bool dm_helpers_dp_mst_write_payload_allocation_table(
if (enable)
drm_dp_add_payload_part1(mst_mgr, mst_state, payload);
else
- drm_dp_remove_payload(mst_mgr, mst_state, payload);
+ drm_dp_remove_payload(mst_mgr, mst_state, payload, payload);
/* mst_mgr->->payloads are VC payload notify MST branch using DPCD or
* AUX message. The sequence is slot 1-63 allocated sequence for each
diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c b/drivers/gpu/drm/display/drm_dp_mst_topology.c
index e77c674b37ca..38dab76ae69e 100644
--- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
@@ -3342,7 +3342,8 @@ EXPORT_SYMBOL(drm_dp_add_payload_part1);
* drm_dp_remove_payload() - Remove an MST payload
* @mgr: Manager to use.
* @mst_state: The MST atomic state
- * @payload: The payload to write
+ * @old_payload: The payload with its old state
+ * @new_payload: The payload to write
*
* Removes a payload from an MST topology if it was successfully assigned a start slot. Also updates
* the starting time slots of all other payloads which would have been shifted towards the start of
@@ -3350,36 +3351,37 @@ EXPORT_SYMBOL(drm_dp_add_payload_part1);
*/
void drm_dp_remove_payload(struct drm_dp_mst_topology_mgr *mgr,
struct drm_dp_mst_topology_state *mst_state,
- struct drm_dp_mst_atomic_payload *payload)
+ const struct drm_dp_mst_atomic_payload *old_payload,
+ struct drm_dp_mst_atomic_payload *new_payload)
{
struct drm_dp_mst_atomic_payload *pos;
bool send_remove = false;
/* We failed to make the payload, so nothing to do */
- if (payload->vc_start_slot == -1)
+ if (new_payload->vc_start_slot == -1)
return;
mutex_lock(&mgr->lock);
- send_remove = drm_dp_mst_port_downstream_of_branch(payload->port, mgr->mst_primary);
+ send_remove = drm_dp_mst_port_downstream_of_branch(new_payload->port, mgr->mst_primary);
mutex_unlock(&mgr->lock);
if (send_remove)
- drm_dp_destroy_payload_step1(mgr, mst_state, payload);
+ drm_dp_destroy_payload_step1(mgr, mst_state, new_payload);
else
drm_dbg_kms(mgr->dev, "Payload for VCPI %d not in topology, not sending remove\n",
- payload->vcpi);
+ new_payload->vcpi);
list_for_each_entry(pos, &mst_state->payloads, next) {
- if (pos != payload && pos->vc_start_slot > payload->vc_start_slot)
- pos->vc_start_slot -= payload->time_slots;
+ if (pos != new_payload && pos->vc_start_slot > new_payload->vc_start_slot)
+ pos->vc_start_slot -= old_payload->time_slots;
}
- payload->vc_start_slot = -1;
+ new_payload->vc_start_slot = -1;
mgr->payload_count--;
- mgr->next_start_slot -= payload->time_slots;
+ mgr->next_start_slot -= old_payload->time_slots;
- if (payload->delete)
- drm_dp_mst_put_port_malloc(payload->port);
+ if (new_payload->delete)
+ drm_dp_mst_put_port_malloc(new_payload->port);
}
EXPORT_SYMBOL(drm_dp_remove_payload);
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index 27c2098dd707..256afff75b0a 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -366,6 +366,8 @@ static void intel_mst_disable_dp(struct intel_atomic_state *state,
to_intel_connector(old_conn_state->connector);
struct drm_dp_mst_topology_state *mst_state =
drm_atomic_get_mst_topology_state(&state->base, &intel_dp->mst_mgr);
+ struct drm_dp_mst_atomic_payload *payload =
+ drm_atomic_get_mst_payload_state(mst_state, connector->port);
struct drm_i915_private *i915 = to_i915(connector->base.dev);
drm_dbg_kms(&i915->drm, "active links %d\n",
@@ -374,7 +376,7 @@ static void intel_mst_disable_dp(struct intel_atomic_state *state,
intel_hdcp_disable(intel_mst->connector);
drm_dp_remove_payload(&intel_dp->mst_mgr, mst_state,
- drm_atomic_get_mst_payload_state(mst_state, connector->port));
+ payload, payload);
intel_audio_codec_disable(encoder, old_crtc_state, old_conn_state);
}
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 33c97d510999..4f1bf1cb9e0c 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -996,7 +996,7 @@ nv50_msto_prepare(struct drm_atomic_state *state,
// TODO: Figure out if we want to do a better job of handling VCPI allocation failures here?
if (msto->disabled) {
- drm_dp_remove_payload(mgr, mst_state, payload);
+ drm_dp_remove_payload(mgr, mst_state, payload, payload);
} else {
if (msto->enabled)
drm_dp_add_payload_part1(mgr, mst_state, payload);
diff --git a/include/drm/display/drm_dp_mst_helper.h b/include/drm/display/drm_dp_mst_helper.h
index 6c0c3dc3d3ac..32c764fb9cb5 100644
--- a/include/drm/display/drm_dp_mst_helper.h
+++ b/include/drm/display/drm_dp_mst_helper.h
@@ -841,7 +841,8 @@ int drm_dp_add_payload_part2(struct drm_dp_mst_topology_mgr *mgr,
struct drm_dp_mst_atomic_payload *payload);
void drm_dp_remove_payload(struct drm_dp_mst_topology_mgr *mgr,
struct drm_dp_mst_topology_state *mst_state,
- struct drm_dp_mst_atomic_payload *payload);
+ const struct drm_dp_mst_atomic_payload *old_payload,
+ struct drm_dp_mst_atomic_payload *new_payload);
int drm_dp_check_act_status(struct drm_dp_mst_topology_mgr *mgr);
--
2.34.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox