All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v2] xen/timers: Fix memory leak with cpu unplug/plug
@ 2019-04-08  9:39 Andrew Cooper
  2019-04-08  9:56 ` Jan Beulich
  2019-04-08 10:39 ` Julien Grall
  0 siblings, 2 replies; 9+ messages in thread
From: Andrew Cooper @ 2019-04-08  9:39 UTC (permalink / raw)
  To: Xen-devel
  Cc: Stefano Stabellini, Wei Liu, Konrad Rzeszutek Wilk,
	George Dunlap, Andrew Cooper, Tim Deegan, Julien Grall,
	Jan Beulich, Ian Jackson

timer_softirq_action() realloc's itself a larger timer heap whenever
necessary, which includes bootstrapping from the empty dummy_heap.  Nothing
ever freed this allocation.

CPU plug and unplug has the side effect of zeroing the percpu data area, which
clears ts->heap.  This in turn causes new timers to be put on the list rather
than the heap, and for timer_softirq_action() to bootstrap itself again.

This in practice leaks ts->heap every time a CPU is unplugged and replugged.

Implement free_percpu_timers() which includes freeing ts->heap when
appropriate, and update the notifier callback with the recent cpu parking
logic and free-avoidance across suspend.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: George Dunlap <George.Dunlap@eu.citrix.com>
CC: Ian Jackson <ian.jackson@citrix.com>
CC: Jan Beulich <JBeulich@suse.com>
CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
CC: Stefano Stabellini <sstabellini@kernel.org>
CC: Tim Deegan <tim@xen.org>
CC: Wei Liu <wei.liu2@citrix.com>
CC: Julien Grall <julien.grall@arm.com>

v2:
 * Rebase over Juergen's free-avoidance series.

This texturally depends on "xen/timers: Document and improve the
representation of the timer heap metadata" which was necessary to understand
the problem well enough to fix it, but isn't backporting over this change
isn't too complicated (should the cleanup patch not want to be backported).
---
 xen/common/timer.c | 27 ++++++++++++++++++++++++++-
 1 file changed, 26 insertions(+), 1 deletion(-)

diff --git a/xen/common/timer.c b/xen/common/timer.c
index 98f2c48..f265a36 100644
--- a/xen/common/timer.c
+++ b/xen/common/timer.c
@@ -615,6 +615,22 @@ static void migrate_timers_from_cpu(unsigned int old_cpu)
  */
 static struct timer *dummy_heap[1];
 
+static void free_percpu_timers(unsigned int cpu)
+{
+    struct timers *ts = &per_cpu(timers, cpu);
+
+    migrate_timers_from_cpu(cpu);
+
+    ASSERT(heap_metadata(ts->heap)->size == 0);
+    if ( heap_metadata(ts->heap)->limit )
+    {
+        xfree(ts->heap);
+        ts->heap = dummy_heap;
+    }
+    else
+        ASSERT(ts->heap == dummy_heap);
+}
+
 static int cpu_callback(
     struct notifier_block *nfb, unsigned long action, void *hcpu)
 {
@@ -628,10 +644,19 @@ static int cpu_callback(
         spin_lock_init(&ts->lock);
         ts->heap = dummy_heap;
         break;
+
     case CPU_UP_CANCELED:
     case CPU_DEAD:
-        migrate_timers_from_cpu(cpu);
+    case CPU_RESUME_FAILED:
+        if ( !park_offline_cpus && system_state != SYS_STATE_suspend )
+            free_percpu_timers(cpu);
         break;
+
+    case CPU_REMOVE:
+        if ( park_offline_cpus )
+            free_percpu_timers(cpu);
+        break;
+
     default:
         break;
     }
-- 
2.1.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply related	[flat|nested] 9+ messages in thread

* Re: [PATCH v2] xen/timers: Fix memory leak with cpu unplug/plug
  2019-04-08  9:39 [PATCH v2] xen/timers: Fix memory leak with cpu unplug/plug Andrew Cooper
@ 2019-04-08  9:56 ` Jan Beulich
  2019-04-08 10:39 ` Julien Grall
  1 sibling, 0 replies; 9+ messages in thread
From: Jan Beulich @ 2019-04-08  9:56 UTC (permalink / raw)
  To: Andrew Cooper
  Cc: Stefano Stabellini, Wei Liu, Konrad Rzeszutek Wilk,
	George Dunlap, Tim Deegan, Xen-devel, Julien Grall, Ian Jackson

>>> On 08.04.19 at 11:39, <andrew.cooper3@citrix.com> wrote:
> timer_softirq_action() realloc's itself a larger timer heap whenever
> necessary, which includes bootstrapping from the empty dummy_heap.  Nothing
> ever freed this allocation.
> 
> CPU plug and unplug has the side effect of zeroing the percpu data area, which
> clears ts->heap.  This in turn causes new timers to be put on the list rather
> than the heap, and for timer_softirq_action() to bootstrap itself again.
> 
> This in practice leaks ts->heap every time a CPU is unplugged and replugged.
> 
> Implement free_percpu_timers() which includes freeing ts->heap when
> appropriate, and update the notifier callback with the recent cpu parking
> logic and free-avoidance across suspend.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

Reviewed-by: Jan Beulich <jbeulich@suse.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v2] xen/timers: Fix memory leak with cpu unplug/plug
  2019-04-08  9:39 [PATCH v2] xen/timers: Fix memory leak with cpu unplug/plug Andrew Cooper
  2019-04-08  9:56 ` Jan Beulich
@ 2019-04-08 10:39 ` Julien Grall
  2019-04-08 10:47   ` Andrew Cooper
  1 sibling, 1 reply; 9+ messages in thread
From: Julien Grall @ 2019-04-08 10:39 UTC (permalink / raw)
  To: Andrew Cooper, Xen-devel
  Cc: Stefano Stabellini, Wei Liu, Konrad Rzeszutek Wilk,
	George Dunlap, Tim Deegan, Jan Beulich, Ian Jackson

Hi,

On 4/8/19 10:39 AM, Andrew Cooper wrote:
> +    case CPU_RESUME_FAILED:
> +        if ( !park_offline_cpus && system_state != SYS_STATE_suspend )

This patch breaks compilation on arm32/arm64 because park_offline_cpus 
is not defined:

timer.c: In function 'cpu_callback':
timer.c:651:15: error: 'park_offline_cpus' undeclared (first use in this 
function)
          if ( !park_offline_cpus && system_state != SYS_STATE_suspend )
                ^~~~~~~~~~~~~~~~~

What is the purpose of park_offline_cpus?

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v2] xen/timers: Fix memory leak with cpu unplug/plug
  2019-04-08 10:39 ` Julien Grall
@ 2019-04-08 10:47   ` Andrew Cooper
  2019-04-08 11:38     ` Julien Grall
  0 siblings, 1 reply; 9+ messages in thread
From: Andrew Cooper @ 2019-04-08 10:47 UTC (permalink / raw)
  To: Julien Grall, Xen-devel
  Cc: Stefano Stabellini, Wei Liu, Konrad Rzeszutek Wilk,
	George Dunlap, Tim Deegan, Jan Beulich, Ian Jackson

On 08/04/2019 11:39, Julien Grall wrote:
> Hi,
>
> On 4/8/19 10:39 AM, Andrew Cooper wrote:
>> +    case CPU_RESUME_FAILED:
>> +        if ( !park_offline_cpus && system_state != SYS_STATE_suspend )
>
> This patch breaks compilation on arm32/arm64 because park_offline_cpus
> is not defined:
>
> timer.c: In function 'cpu_callback':
> timer.c:651:15: error: 'park_offline_cpus' undeclared (first use in
> this function)
>          if ( !park_offline_cpus && system_state != SYS_STATE_suspend )
>                ^~~~~~~~~~~~~~~~~
>
> What is the purpose of park_offline_cpus?

Sorry.  I should have waited for a full build test first.

park_offline_cpus is a workaround for Intel's MCE behaviour, where the
system will shut down rather than deliver an #MC if machine checking
isn't configured on all CPUs.

As a result, we have to start all CPUs, even beyond maxcpus= and set up
machine check handling, and never ever free their stacks, even if we'd
prefer the CPUs to be offline.

Are you happy with a

#define park_offline_cpus false

in ARM?

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v2] xen/timers: Fix memory leak with cpu unplug/plug
  2019-04-08 10:47   ` Andrew Cooper
@ 2019-04-08 11:38     ` Julien Grall
  2019-04-08 12:09       ` Andrew Cooper
  0 siblings, 1 reply; 9+ messages in thread
From: Julien Grall @ 2019-04-08 11:38 UTC (permalink / raw)
  To: Andrew Cooper, Xen-devel
  Cc: Stefano Stabellini, Wei Liu, Konrad Rzeszutek Wilk,
	George Dunlap, Tim Deegan, Jan Beulich, Ian Jackson

Hi,

On 4/8/19 11:47 AM, Andrew Cooper wrote:
> On 08/04/2019 11:39, Julien Grall wrote:
>> Hi,
>>
>> On 4/8/19 10:39 AM, Andrew Cooper wrote:
>>> +    case CPU_RESUME_FAILED:
>>> +        if ( !park_offline_cpus && system_state != SYS_STATE_suspend )
>>
>> This patch breaks compilation on arm32/arm64 because park_offline_cpus
>> is not defined:
>>
>> timer.c: In function 'cpu_callback':
>> timer.c:651:15: error: 'park_offline_cpus' undeclared (first use in
>> this function)
>>           if ( !park_offline_cpus && system_state != SYS_STATE_suspend )
>>                 ^~~~~~~~~~~~~~~~~
>>
>> What is the purpose of park_offline_cpus?
> 
> Sorry.  I should have waited for a full build test first.
> 
> park_offline_cpus is a workaround for Intel's MCE behaviour, where the
> system will shut down rather than deliver an #MC if machine checking
> isn't configured on all CPUs.
> 
> As a result, we have to start all CPUs, even beyond maxcpus= and set up
> machine check handling, and never ever free their stacks, even if we'd
> prefer the CPUs to be offline.

I am a bit confused, why this is necessary now for the timer and not in 
other places of the common code?

> 
> Are you happy with a
> 
> #define park_offline_cpus false >
> in ARM?

The name is fairly confusing if you don't know the background.

But I have to admit that even with your explanation above, I still don't 
understand why you need to check park_offline_cpus in the timers.

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v2] xen/timers: Fix memory leak with cpu unplug/plug
  2019-04-08 11:38     ` Julien Grall
@ 2019-04-08 12:09       ` Andrew Cooper
  2019-04-08 13:53         ` Julien Grall
  0 siblings, 1 reply; 9+ messages in thread
From: Andrew Cooper @ 2019-04-08 12:09 UTC (permalink / raw)
  To: Julien Grall, Xen-devel
  Cc: Stefano Stabellini, Wei Liu, Konrad Rzeszutek Wilk,
	George Dunlap, Tim Deegan, Jan Beulich, Ian Jackson

On 08/04/2019 12:38, Julien Grall wrote:
> Hi,
>
> On 4/8/19 11:47 AM, Andrew Cooper wrote:
>> On 08/04/2019 11:39, Julien Grall wrote:
>>> Hi,
>>>
>>> On 4/8/19 10:39 AM, Andrew Cooper wrote:
>>>> +    case CPU_RESUME_FAILED:
>>>> +        if ( !park_offline_cpus && system_state !=
>>>> SYS_STATE_suspend )
>>>
>>> This patch breaks compilation on arm32/arm64 because park_offline_cpus
>>> is not defined:
>>>
>>> timer.c: In function 'cpu_callback':
>>> timer.c:651:15: error: 'park_offline_cpus' undeclared (first use in
>>> this function)
>>>           if ( !park_offline_cpus && system_state !=
>>> SYS_STATE_suspend )
>>>                 ^~~~~~~~~~~~~~~~~
>>>
>>> What is the purpose of park_offline_cpus?
>>
>> Sorry.  I should have waited for a full build test first.
>>
>> park_offline_cpus is a workaround for Intel's MCE behaviour, where the
>> system will shut down rather than deliver an #MC if machine checking
>> isn't configured on all CPUs.
>>
>> As a result, we have to start all CPUs, even beyond maxcpus= and set up
>> machine check handling, and never ever free their stacks, even if we'd
>> prefer the CPUs to be offline.
>
> I am a bit confused, why this is necessary now for the timer and not
> in other places of the common code?
>
>>
>> Are you happy with a
>>
>> #define park_offline_cpus false >
>> in ARM?
>
> The name is fairly confusing if you don't know the background.
>
> But I have to admit that even with your explanation above, I still
> don't understand why you need to check park_offline_cpus in the timers.

It is all to do with how/when we free per-cpu data.

Technically speaking (with the memory leak fixed) the old arrangement
ought to function correctly, but the new arrangement is more efficient.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v2] xen/timers: Fix memory leak with cpu unplug/plug
  2019-04-08 12:09       ` Andrew Cooper
@ 2019-04-08 13:53         ` Julien Grall
  2019-04-08 14:33           ` Andrew Cooper
  0 siblings, 1 reply; 9+ messages in thread
From: Julien Grall @ 2019-04-08 13:53 UTC (permalink / raw)
  To: Andrew Cooper, Xen-devel
  Cc: Stefano Stabellini, Wei Liu, Konrad Rzeszutek Wilk,
	George Dunlap, Tim Deegan, Jan Beulich, Ian Jackson

Hi Andrew,

On 4/8/19 1:09 PM, Andrew Cooper wrote:
> On 08/04/2019 12:38, Julien Grall wrote:
>> Hi,
>>
>> On 4/8/19 11:47 AM, Andrew Cooper wrote:
>>> On 08/04/2019 11:39, Julien Grall wrote:
>>>> Hi,
>>>>
>>>> On 4/8/19 10:39 AM, Andrew Cooper wrote:
>>>>> +    case CPU_RESUME_FAILED:
>>>>> +        if ( !park_offline_cpus && system_state !=
>>>>> SYS_STATE_suspend )
>>>>
>>>> This patch breaks compilation on arm32/arm64 because park_offline_cpus
>>>> is not defined:
>>>>
>>>> timer.c: In function 'cpu_callback':
>>>> timer.c:651:15: error: 'park_offline_cpus' undeclared (first use in
>>>> this function)
>>>>            if ( !park_offline_cpus && system_state !=
>>>> SYS_STATE_suspend )
>>>>                  ^~~~~~~~~~~~~~~~~
>>>>
>>>> What is the purpose of park_offline_cpus?
>>>
>>> Sorry.  I should have waited for a full build test first.
>>>
>>> park_offline_cpus is a workaround for Intel's MCE behaviour, where the
>>> system will shut down rather than deliver an #MC if machine checking
>>> isn't configured on all CPUs.
>>>
>>> As a result, we have to start all CPUs, even beyond maxcpus= and set up
>>> machine check handling, and never ever free their stacks, even if we'd
>>> prefer the CPUs to be offline.
>>
>> I am a bit confused, why this is necessary now for the timer and not
>> in other places of the common code?
>>
>>>
>>> Are you happy with a
>>>
>>> #define park_offline_cpus false >
>>> in ARM?
>>
>> The name is fairly confusing if you don't know the background.
>>
>> But I have to admit that even with your explanation above, I still
>> don't understand why you need to check park_offline_cpus in the timers.
> 
> It is all to do with how/when we free per-cpu data.
> 
> Technically speaking (with the memory leak fixed) the old arrangement
> ought to function correctly, but the new arrangement is more efficient.
Where would the free happen in the "less efficient" way?

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v2] xen/timers: Fix memory leak with cpu unplug/plug
  2019-04-08 13:53         ` Julien Grall
@ 2019-04-08 14:33           ` Andrew Cooper
  2019-04-08 16:16             ` Julien Grall
  0 siblings, 1 reply; 9+ messages in thread
From: Andrew Cooper @ 2019-04-08 14:33 UTC (permalink / raw)
  To: Julien Grall, Xen-devel
  Cc: Stefano Stabellini, Wei Liu, Konrad Rzeszutek Wilk,
	George Dunlap, Tim Deegan, Jan Beulich, Ian Jackson

On 08/04/2019 14:53, Julien Grall wrote:
> Hi Andrew,
>
> On 4/8/19 1:09 PM, Andrew Cooper wrote:
>> On 08/04/2019 12:38, Julien Grall wrote:
>>> Hi,
>>>
>>> On 4/8/19 11:47 AM, Andrew Cooper wrote:
>>>> On 08/04/2019 11:39, Julien Grall wrote:
>>>>> Hi,
>>>>>
>>>>> On 4/8/19 10:39 AM, Andrew Cooper wrote:
>>>>>> +    case CPU_RESUME_FAILED:
>>>>>> +        if ( !park_offline_cpus && system_state !=
>>>>>> SYS_STATE_suspend )
>>>>>
>>>>> This patch breaks compilation on arm32/arm64 because
>>>>> park_offline_cpus
>>>>> is not defined:
>>>>>
>>>>> timer.c: In function 'cpu_callback':
>>>>> timer.c:651:15: error: 'park_offline_cpus' undeclared (first use in
>>>>> this function)
>>>>>            if ( !park_offline_cpus && system_state !=
>>>>> SYS_STATE_suspend )
>>>>>                  ^~~~~~~~~~~~~~~~~
>>>>>
>>>>> What is the purpose of park_offline_cpus?
>>>>
>>>> Sorry.  I should have waited for a full build test first.
>>>>
>>>> park_offline_cpus is a workaround for Intel's MCE behaviour, where the
>>>> system will shut down rather than deliver an #MC if machine checking
>>>> isn't configured on all CPUs.
>>>>
>>>> As a result, we have to start all CPUs, even beyond maxcpus= and
>>>> set up
>>>> machine check handling, and never ever free their stacks, even if we'd
>>>> prefer the CPUs to be offline.
>>>
>>> I am a bit confused, why this is necessary now for the timer and not
>>> in other places of the common code?
>>>
>>>>
>>>> Are you happy with a
>>>>
>>>> #define park_offline_cpus false >
>>>> in ARM?
>>>
>>> The name is fairly confusing if you don't know the background.
>>>
>>> But I have to admit that even with your explanation above, I still
>>> don't understand why you need to check park_offline_cpus in the timers.
>>
>> It is all to do with how/when we free per-cpu data.
>>
>> Technically speaking (with the memory leak fixed) the old arrangement
>> ought to function correctly, but the new arrangement is more efficient.
> Where would the free happen in the "less efficient" way?

I don't quite understand the question.

https://lists.xenproject.org/archives/html/xen-devel/2019-03/msg02252.html
is the v1 patch, but that has already been rejected for not using the
up-to-date notifier layout.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v2] xen/timers: Fix memory leak with cpu unplug/plug
  2019-04-08 14:33           ` Andrew Cooper
@ 2019-04-08 16:16             ` Julien Grall
  0 siblings, 0 replies; 9+ messages in thread
From: Julien Grall @ 2019-04-08 16:16 UTC (permalink / raw)
  To: Andrew Cooper, Xen-devel
  Cc: Stefano Stabellini, Wei Liu, Konrad Rzeszutek Wilk,
	George Dunlap, Tim Deegan, Jan Beulich, Ian Jackson

Hi,

On 4/8/19 3:33 PM, Andrew Cooper wrote:
> On 08/04/2019 14:53, Julien Grall wrote:
>> Hi Andrew,
>>
>> On 4/8/19 1:09 PM, Andrew Cooper wrote:
>>> On 08/04/2019 12:38, Julien Grall wrote:
>>>> Hi,
>>>>
>>>> On 4/8/19 11:47 AM, Andrew Cooper wrote:
>>>>> On 08/04/2019 11:39, Julien Grall wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 4/8/19 10:39 AM, Andrew Cooper wrote:
>>>>>>> +    case CPU_RESUME_FAILED:
>>>>>>> +        if ( !park_offline_cpus && system_state !=
>>>>>>> SYS_STATE_suspend )
>>>>>>
>>>>>> This patch breaks compilation on arm32/arm64 because
>>>>>> park_offline_cpus
>>>>>> is not defined:
>>>>>>
>>>>>> timer.c: In function 'cpu_callback':
>>>>>> timer.c:651:15: error: 'park_offline_cpus' undeclared (first use in
>>>>>> this function)
>>>>>>             if ( !park_offline_cpus && system_state !=
>>>>>> SYS_STATE_suspend )
>>>>>>                   ^~~~~~~~~~~~~~~~~
>>>>>>
>>>>>> What is the purpose of park_offline_cpus?
>>>>>
>>>>> Sorry.  I should have waited for a full build test first.
>>>>>
>>>>> park_offline_cpus is a workaround for Intel's MCE behaviour, where the
>>>>> system will shut down rather than deliver an #MC if machine checking
>>>>> isn't configured on all CPUs.
>>>>>
>>>>> As a result, we have to start all CPUs, even beyond maxcpus= and
>>>>> set up
>>>>> machine check handling, and never ever free their stacks, even if we'd
>>>>> prefer the CPUs to be offline.
>>>>
>>>> I am a bit confused, why this is necessary now for the timer and not
>>>> in other places of the common code?
>>>>
>>>>>
>>>>> Are you happy with a
>>>>>
>>>>> #define park_offline_cpus false >
>>>>> in ARM?
>>>>
>>>> The name is fairly confusing if you don't know the background.
>>>>
>>>> But I have to admit that even with your explanation above, I still
>>>> don't understand why you need to check park_offline_cpus in the timers.
>>>
>>> It is all to do with how/when we free per-cpu data.
>>>
>>> Technically speaking (with the memory leak fixed) the old arrangement
>>> ought to function correctly, but the new arrangement is more efficient.
>> Where would the free happen in the "less efficient" way?
> 
> I don't quite understand the question.

You mention that this new arrangement is "more efficient". So I was 
asking what was the previous solution.

> 
> https://lists.xenproject.org/archives/html/xen-devel/2019-03/msg02252.html
> is the v1 patch, but that has already been rejected for not using the
> up-to-date notifier layout.

At the expense of introducing an undocumented x86-ism in common code. I 
would have nacked such patch if I had time too (only hour between post 
and commit). For common code, could I request a bit more time to allow 
other of the maintainers give an opinion if they have?

I don't have a better name for park_offline_cpus, but we at least need 
more documentation for someone to understand the purpose of it without 
looking at x86. Then, I would be able to understand what is the correct 
fix for Arm.

For time being, I would just revert this patch.

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2019-04-08 16:16 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-04-08  9:39 [PATCH v2] xen/timers: Fix memory leak with cpu unplug/plug Andrew Cooper
2019-04-08  9:56 ` Jan Beulich
2019-04-08 10:39 ` Julien Grall
2019-04-08 10:47   ` Andrew Cooper
2019-04-08 11:38     ` Julien Grall
2019-04-08 12:09       ` Andrew Cooper
2019-04-08 13:53         ` Julien Grall
2019-04-08 14:33           ` Andrew Cooper
2019-04-08 16:16             ` Julien Grall

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.