All of lore.kernel.org
 help / color / mirror / Atom feed
From: NISHIGUCHI Naoki <nisiguti@jp.fujitsu.com>
To: Atsushi SAKAI <sakaia@jp.fujitsu.com>, xen-devel@lists.xensource.com
Subject: Re: [PATCH] Fix deadlock in schedule.c at TRACE mode
Date: Thu, 24 Apr 2008 16:03:04 +0900	[thread overview]
Message-ID: <481030A8.7080506@jp.fujitsu.com> (raw)
In-Reply-To: <200804240542.m3O5gswi016365@fjmscan502.ms.jp.fujitsu.com>

[-- Attachment #1: Type: text/plain, Size: 859 bytes --]

Hi, Atsushi

Atsushi SAKAI wrote:
> I have two questions about this.
> 
> 1)How to reproduce your deadlock ?
>   Would you give me your test environment to reproduce this deadlock?
>   Is it easily reproduced by running xenmon.py or xentrace 
>   with one or two guest domain(s)?
>  or Any additional condition needed?

This deadlock can be easily reproduced by running xenmon.py without
guest domain.
Furthermore, this deadlock occurs easier by applying my patch to xenbaked.c.

Subject of my patch is "[PATCH] Fix access to trace buffer after
xentrace changes".

> 2)About fixing code,
>   I think __trace_var() should fix for this issue not schedule()
>   This issue cannot be fixed by modify the __trace_var()?

Thanks for your advise.
I agree with you.
I fixed this deadlock using tasklet in trace.c.

Here is the patch.

Thanks,
Naoki Nishiguchi

[-- Attachment #2: trace.patch --]
[-- Type: text/plain, Size: 890 bytes --]

diff -r 77dec8732cde xen/common/trace.c
--- a/xen/common/trace.c	Wed Apr 23 16:58:44 2008 +0100
+++ b/xen/common/trace.c	Thu Apr 24 15:56:37 2008 +0900
@@ -69,6 +69,13 @@ static cpumask_t tb_cpu_mask = CPU_MASK_
 /* which tracing events are enabled */
 static u32 tb_event_mask = TRC_ALL;
 
+static void trace_notify_guest(unsigned long unused)
+{
+    send_guest_global_virq(dom0, VIRQ_TBUF);
+}
+
+static DECLARE_TASKLET(trace_tasklet, trace_notify_guest, 0);
+
 /**
  * alloc_trace_bufs - performs initialization of the per-cpu trace buffers.
  *
@@ -506,7 +513,7 @@ void __trace_var(u32 event, int cycles, 
     /* Notify trace buffer consumer that we've crossed the high water mark. */
     if ( started_below_highwater &&
          (calc_unconsumed_bytes(buf) >= t_buf_highwater) )
-        send_guest_global_virq(dom0, VIRQ_TBUF);
+        tasklet_schedule(&trace_tasklet);
 }
 
 /*

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

  reply	other threads:[~2008-04-24  7:03 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-24  4:34 [PATCH] Fix deadlock in schedule.c at TRACE mode NISHIGUCHI Naoki
2008-04-24  5:42 ` Atsushi SAKAI
2008-04-24  7:03   ` NISHIGUCHI Naoki [this message]
2008-04-24  7:29     ` Keir Fraser

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=481030A8.7080506@jp.fujitsu.com \
    --to=nisiguti@jp.fujitsu.com \
    --cc=sakaia@jp.fujitsu.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.