Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1755109Ab2H0Xrf (ORCPT <rfc822;w@1wt.eu>);
	Mon, 27 Aug 2012 19:47:35 -0400
Received: from mga11.intel.com ([192.55.52.93]:49998 "EHLO mga11.intel.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1754814Ab2H0Xre convert rfc822-to-8bit (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 27 Aug 2012 19:47:34 -0400
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,322,1344236400"; 
   d="scan'208";a="214029780"
From: "Liu, Chuansheng" <chuansheng.liu@intel.com>
To: "Gross, Mark" <mark.gross@intel.com>,
        "'linux-kernel@vger.kernel.org' (linux-kernel@vger.kernel.org)" 
	<linux-kernel@vger.kernel.org>
CC: "hpa@linux.intel.com" <hpa@linux.intel.com>,
        "alan@linux.intel.com" <alan@linux.intel.com>,
        "Pan, Jacob jun" <jacob.jun.pan@intel.com>
Subject: RE: [PATCH RESEND] x86_dump_trace: avoiding endless " <IRQ> " is
 printed
Thread-Topic: [PATCH RESEND] x86_dump_trace: avoiding endless " <IRQ> " is
 printed
Thread-Index: Ac2D9xtDBkCP/QDsRbSYlkNzzpgV2AAcy6GQABDdPHA=
Date: Mon, 27 Aug 2012 23:47:11 +0000
Message-ID: <27240C0AC20F114CBF8149A2696CBE4A170708@SHSMSX101.ccr.corp.intel.com>
References: <27240C0AC20F114CBF8149A2696CBE4A16FBD5@SHSMSX101.ccr.corp.intel.com>
 <BD75D217E5BAC84080F8EFB25829763746C926C7@ORSMSX101.amr.corp.intel.com>
In-Reply-To: <BD75D217E5BAC84080F8EFB25829763746C926C7@ORSMSX101.amr.corp.intel.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 8BIT
MIME-Version: 1.0
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 3857
Lines: 101

> Do you think we should add the same change to dumpstack_64.c too.
Feels dumpstack_64.c has different with dumpstack_32 which just has three types stacks for normal thread, hardirq and softirq,
so just want to use this patch to cover x86_32 case and it is the real case I meet also, thanks.

> -----Original Message-----
> From: Gross, Mark
> Sent: Monday, August 27, 2012 11:50 PM
> To: Liu, Chuansheng; 'linux-kernel@vger.kernel.org'
> (linux-kernel@vger.kernel.org)
> Cc: hpa@linux.intel.com; alan@linux.intel.com; Pan, Jacob jun
> Subject: RE: [PATCH RESEND] x86_dump_trace: avoiding endless " <IRQ> " is
> printed
> 
> Do you think we should add the same change to dumpstack_64.c too.
> 
> Looks like you addressed Alan's comments already (i.e. use of unlikely not
> needed, us %p, and use pr_warn instead of printk)
> 
> --mark
> 
> > -----Original Message-----
> > From: Liu, Chuansheng
> > Sent: Sunday, August 26, 2012 6:56 PM
> > To: 'linux-kernel@vger.kernel.org' (linux-kernel@vger.kernel.org)
> > Cc: hpa@linux.intel.com; Gross, Mark; alan@linux.intel.com
> > Subject: [PATCH RESEND] x86_dump_trace: avoiding endless " <IRQ> " is
> > printed
> >
> > From: liu chuansheng <chuansheng.liu@intel.com>
> > Subject: [PATCH] x86_dump_trace: avoiding endless " <IRQ> " is printed
> >
> > Found the case that endless " <IRQ> " printing in dump_trace, and no
> > real meaningful stack traces are output, so there should be one rare
> > case that possibly context->previous_esp = context or other cases.
> >
> > The endless " <IRQ> " is as below:
> > ...
> > [   82.215244,0]  <IRQ>
> > [   82.215399,0]  <IRQ>
> > [   82.215554,0]  <IRQ>
> > [   82.215710,0]  <IRQ>
> > [   82.215865,0]  <IRQ>
> > [   82.216022,0]  <IRQ>
> > [   82.216178,0]  <IRQ>
> > [   82.216333,0]  <IRQ>
> > [   82.216488,0]  <IRQ>
> > [   82.216643,0]  <IRQ>
> > [   82.216798,0]  <IRQ>
> > [   82.216953,0]  <IRQ>
> > ...
> >
> > This patch aim is:
> > 1/ Limiting the " <IRQ> " outputing, currently the max IRQ contexts is
> > 2(softirq+harirq combination); 2/ When the max IRQ contexts 2 is
> > reached, print the context content to confirm;
> >
> > Change-Id: I6d72aa71c4c5ff8f9e6ae133b3f6bfec8887750d
> > Signed-off-by: liu chuansheng <chuansheng.liu@intel.com>
> > ---
> >  arch/x86/kernel/dumpstack_32.c |   11 +++++++++++
> >  1 files changed, 11 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/x86/kernel/dumpstack_32.c
> > b/arch/x86/kernel/dumpstack_32.c index 1038a41..410fa38 100644
> > --- a/arch/x86/kernel/dumpstack_32.c
> > +++ b/arch/x86/kernel/dumpstack_32.c
> > @@ -22,6 +22,7 @@ void dump_trace(struct task_struct *task, struct
> > pt_regs *regs,
> >                 const struct stacktrace_ops *ops, void *data)  {
> >         int graph = 0;
> > +       int dump_irq_count = 0;
> >
> >         if (!task)
> >                 task = current;
> > @@ -47,8 +48,18 @@ void dump_trace(struct task_struct *task, struct
> > pt_regs *regs,
> >                 stack = (unsigned long *)context->previous_esp;
> >                 if (!stack)
> >                         break;
> > +
> > +               if (dump_irq_count > 2) {
> > +                       pr_warn("break multi-IRQ print,"
> > +                               "context=%p, stack=%p\n",
> > +                               context,
> > +                               stack);
> > +                       break;
> > +               }
> > +
> >                 if (ops->stack(data, "IRQ") < 0)
> >                         break;
> > +               dump_irq_count++;
> >                 touch_nmi_watchdog();
> >         }
> >  }
> > --
> > 1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/