Previous attempts to fix this leak failed to identify the root cause, and
ultimately failed. The cause is the CPU_UP_PREPARE case (re)initialising
ts->heap back to dummy_heap, which leaks the previous allocation.
Rearrange the logic to only initialise ts once. This also avoids the
redundant (but benign, due to ts->inactive always being empty) initialising of
the other ts fields.
Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com>
---
CC: George Dunlap <george.dun...@eu.citrix.com>
CC: Jan Beulich <jbeul...@suse.com>
CC: Konrad Rzeszutek Wilk <konrad.w...@oracle.com>
CC: Stefano Stabellini <sstabell...@kernel.org>
CC: Tim Deegan <t...@xen.org>
CC: Wei Liu <wei.l...@citrix.com>
CC: Julien Grall <julien.gr...@arm.com>
---
xen/common/timer.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/xen/common/timer.c b/xen/common/timer.c
index f60712a..650e398 100644
--- a/xen/common/timer.c
+++ b/xen/common/timer.c
@@ -657,9 +657,13 @@ static int cpu_callback(
switch ( action )
{
case CPU_UP_PREPARE:
- INIT_LIST_HEAD(&ts->inactive);
- spin_lock_init(&ts->lock);
- ts->heap = dummy_heap;
+ /* Only initialise ts once. */
+ if ( !ts->heap )
+ {
+ INIT_LIST_HEAD(&ts->inactive);
+ spin_lock_init(&ts->lock);
+ ts->heap = dummy_heap;
+ }
break;
case CPU_UP_CANCELED:
--
2.1.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
