From: Tejun Heo <tj@kernel.org>
To: Vineet Gupta <Vineet.Gupta1@synopsys.com>
Cc: linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org,
akpm@linux-foundation.org, mingo@redhat.com, x86@kernel.org,
rth@twiddle.net, linux@arm.linux.org.uk, msalter@redhat.com,
starvik@axis.com, dhowells@redhat.com, tony.luck@intel.com,
benh@kernel.crashing.org, takata@linux-m32r.org,
geert@linux-m68k.org, james.hogan@imgtec.com, monstr@monstr.eu,
ralf@linux-mips.org, jonas@southpole.se, rkuo@codeaurora.org,
schwidefsky@de.ibm.com, liqin.chen@sunplusct.com,
davem@davemloft.net, lethal@linux-sh.org, chris@zankel.net,
cmetcalf@tilera.com, ysato@users.sourceforge.jp,
gxt@mprc.pku.edu.cn, jdike@addtoit.com
Subject: Re: [PATCH v2 5/5] dump_stack: unify debug information printed by show_regs()
Date: Tue, 2 Apr 2013 11:07:50 -0700 [thread overview]
Message-ID: <20130402180750.GA6185@htj.dyndns.org> (raw)
In-Reply-To: <51568277.8000404@synopsys.com>
Hello, Vineet.
On Sat, Mar 30, 2013 at 11:43:11AM +0530, Vineet Gupta wrote:
> Although in line [2], ARC trouble-shooting code prints the task path (rather than
> comm). This was done to help identify faulting LTP open posix tests with same name
> in different directories: e.g. fork/6-1, sigqueue/6-1 ....
> Is this something you want to add to generic code as well - although it's slightly
> involved due to tsk/mm locking etc.
I don't think that'd be a particularly good idea. Paths can be pretty
long and in general we want to limit the scope of unsafe accesses from
dump functions. dump could easily be called from deep inside mmap
paths and you definitely don't wanna do get_mm_exec_file() which
involves read-locking mm->mmap_sem.
While it could be useful for arc where, supposedly, not a lot of
generic development and debugging would happen and flushing out bugs
in arch code is much more important, I don't really think it's a good
idea in general.
> Also I personally prefer the more compact <task-nm>/<tgid> format of [1] vs. [3].
It's taken from x86 messages which should be familiar to most number
of devs. Given that it's a last-resort debug thing, we can change
things but there's no reason to disturb more than necessary.
> Anyhow, can you please fold the following into your patchset to reduce above
> duplication.
Sure thing.
Thanks!
--
tejun
next prev parent reply other threads:[~2013-04-02 18:07 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-30 2:27 [PATCHSET] arch: unify task dump debug info Tejun Heo
2013-03-30 2:27 ` [PATCH 1/5] x86: don't show trace beyond show_stack(NULL, NULL) Tejun Heo
2013-03-30 2:27 ` [PATCH 2/5] sparc32: make show_stack() acquire %fp if @_ksp is not specified Tejun Heo
2013-03-30 3:29 ` David Miller
2013-03-30 2:27 ` [PATCH 3/5] dump_stack: consolidate dump_stack() implementations and unify their behaviors Tejun Heo
2013-03-30 2:27 ` Tejun Heo
2013-03-30 3:30 ` David Miller
2013-03-30 5:27 ` Vineet Gupta
2013-03-30 11:45 ` Heiko Carstens
2013-04-02 6:48 ` Martin Schwidefsky
2013-04-02 18:26 ` Tejun Heo
2013-04-02 9:22 ` Jesper Nilsson
2013-04-16 14:59 ` James Hogan
2013-03-30 2:27 ` [PATCH 4/5] dump_stack: implement arch-specific hardware description in task dumps Tejun Heo
2013-03-30 2:27 ` Tejun Heo
2013-04-01 18:11 ` Bjorn Helgaas
2013-04-01 18:11 ` Bjorn Helgaas
2013-04-02 18:24 ` Tejun Heo
2013-04-02 18:24 ` Tejun Heo
2013-03-30 2:27 ` [PATCH 5/5] dump_stack: unify debug information printed by show_regs() Tejun Heo
2013-03-30 2:27 ` Tejun Heo
2013-03-30 3:24 ` [PATCH v2 " Tejun Heo
2013-03-30 3:30 ` David Miller
2013-03-30 6:13 ` Vineet Gupta
2013-04-02 18:07 ` Tejun Heo [this message]
2013-04-02 9:21 ` Jesper Nilsson
2013-04-02 9:21 ` Jesper Nilsson
2013-04-03 4:57 ` Vineet Gupta
2013-04-16 15:05 ` James Hogan
2013-04-02 9:24 ` [PATCHSET] arch: unify task dump debug info David Howells
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=20130402180750.GA6185@htj.dyndns.org \
--to=tj@kernel.org \
--cc=Vineet.Gupta1@synopsys.com \
--cc=akpm@linux-foundation.org \
--cc=benh@kernel.crashing.org \
--cc=chris@zankel.net \
--cc=cmetcalf@tilera.com \
--cc=davem@davemloft.net \
--cc=dhowells@redhat.com \
--cc=geert@linux-m68k.org \
--cc=gxt@mprc.pku.edu.cn \
--cc=james.hogan@imgtec.com \
--cc=jdike@addtoit.com \
--cc=jonas@southpole.se \
--cc=lethal@linux-sh.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=liqin.chen@sunplusct.com \
--cc=mingo@redhat.com \
--cc=monstr@monstr.eu \
--cc=msalter@redhat.com \
--cc=ralf@linux-mips.org \
--cc=rkuo@codeaurora.org \
--cc=rth@twiddle.net \
--cc=schwidefsky@de.ibm.com \
--cc=starvik@axis.com \
--cc=takata@linux-m32r.org \
--cc=tony.luck@intel.com \
--cc=x86@kernel.org \
--cc=ysato@users.sourceforge.jp \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).