The patch titled
Subject: mm/vmalloc.c: switch to WARN_ON() and move it under unlink_va()
has been added to the -mm tree. Its filename is
mm-vmallocc-switch-to-warn_on-and-move-it-under-unlink_va.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mm-vmallocc-switch-to-warn_on-and-move-it-under-unlink_va.patch
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mm-vmallocc-switch-to-warn_on-and-move-it-under-unlink_va.patch
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 and is updated
there every 3-4 working days
------------------------------------------------------
From: "Uladzislau Rezki (Sony)" <urezki@xxxxxxxxx>
Subject: mm/vmalloc.c: switch to WARN_ON() and move it under unlink_va()
Trigger a warning if an object that is about to be freed is detached. We
used to have a BUG_ON(), but even though it is considered as faulty
behaviour that is not a good reason to break a system.
Link: http://lkml.kernel.org/r/20190606120411.8298-5-urezki@xxxxxxxxx
Signed-off-by: Uladzislau Rezki (Sony) <urezki@xxxxxxxxx>
Cc: Roman Gushchin <guro@xxxxxx>
Cc: Hillf Danton <hdanton@xxxxxxxx>
Cc: Michal Hocko <mhocko@xxxxxxxx>
Cc: Matthew Wilcox <willy@xxxxxxxxxxxxx>
Cc: Oleksiy Avramchenko <oleksiy.avramchenko@xxxxxxxxxxxxxx>
Cc: Steven Rostedt <rostedt@xxxxxxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
---
mm/vmalloc.c | 25 ++++++++++---------------
1 file changed, 10 insertions(+), 15 deletions(-)
--- a/mm/vmalloc.c~mm-vmallocc-switch-to-warn_on-and-move-it-under-unlink_va
+++ a/mm/vmalloc.c
@@ -534,20 +534,17 @@ link_va(struct vmap_area *va, struct rb_
static __always_inline void
unlink_va(struct vmap_area *va, struct rb_root *root)
{
- /*
- * During merging a VA node can be empty, therefore
- * not linked with the tree nor list. Just check it.
- */
- if (!RB_EMPTY_NODE(&va->rb_node)) {
- if (root == &free_vmap_area_root)
- rb_erase_augmented(&va->rb_node,
- root, &free_vmap_area_rb_augment_cb);
- else
- rb_erase(&va->rb_node, root);
+ if (WARN_ON(RB_EMPTY_NODE(&va->rb_node)))
+ return;
- list_del(&va->list);
- RB_CLEAR_NODE(&va->rb_node);
- }
+ if (root == &free_vmap_area_root)
+ rb_erase_augmented(&va->rb_node,
+ root, &free_vmap_area_rb_augment_cb);
+ else
+ rb_erase(&va->rb_node, root);
+
+ list_del(&va->list);
+ RB_CLEAR_NODE(&va->rb_node);
}
#if DEBUG_AUGMENT_PROPAGATE_CHECK
@@ -1162,8 +1159,6 @@ EXPORT_SYMBOL_GPL(unregister_vmap_purge_
static void __free_vmap_area(struct vmap_area *va)
{
- BUG_ON(RB_EMPTY_NODE(&va->rb_node));
-
/*
* Remove from the busy tree/list.
*/
_
Patches currently in -mm which might be from urezki@xxxxxxxxx are
mm-vmallocc-remove-node-argument.patch
mm-vmallocc-preload-a-cpu-with-one-object-for-split-purpose.patch
mm-vmallocc-get-rid-of-one-single-unlink_va-when-merge.patch
mm-vmallocc-switch-to-warn_on-and-move-it-under-unlink_va.patch
