>>> On 13.08.10 at 09:10, Keir Fraser <keir.fraser@xxxxxxxxxxxxx> wrote:
> On 13/08/2010 08:06, "Jan Beulich" <JBeulich@xxxxxxxxxx> wrote:
>
>>>> But then, to avoid a hanging system, these should be trylock-s
>>>> rather than plain locks, shouldn't they?
>>>
>>> Why? The handler is called in softirq context. It should be safe to spin.
>>
>> Hmm, indeed. I was looking at others, and at least
>> domain_dump_evtchn_info() also uses a trylock - apparently for
>> no good reason.
>
> Well, since you wrote that function, would you like me to switch
> domain_dump_evtchn_info() to do a proper spin_lock()?
Yes. I'd want to do a little cleanup to the initial printk()-s at once,
like in the patch below.
Jan
Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx>
--- 2010-08-12.orig/xen/common/event_channel.c
+++ 2010-08-12/xen/common/event_channel.c
@@ -1123,14 +1123,11 @@ static void domain_dump_evtchn_info(stru
bitmap_scnlistprintf(keyhandler_scratch, sizeof(keyhandler_scratch),
d->poll_mask, d->max_vcpus);
- printk("Domain %d polling vCPUs: {%s}\n",
- d->domain_id, keyhandler_scratch);
-
- if ( !spin_trylock(&d->event_lock) )
- return;
-
printk("Event channel information for domain %d:\n"
- " port [p/m]\n", d->domain_id);
+ "Polling vCPUs: {%s}\n"
+ " port [p/m]\n", d->domain_id, keyhandler_scratch);
+
+ spin_lock(&d->event_lock);
for ( port = 1; port < MAX_EVTCHNS(d); ++port )
{
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home