linux-kernel - Re: [PATCH v2 5/5] dump_stack: unify debug information printed by show

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20130402180750.GA6185@htj.dyndns.org>
Date:	Tue, 2 Apr 2013 11:07:50 -0700
From:	Tejun Heo <tj@...nel.org>
To:	Vineet Gupta <Vineet.Gupta1@...opsys.com>
Cc:	linux-arch@...r.kernel.org, linux-kernel@...r.kernel.org,
	akpm@...ux-foundation.org, mingo@...hat.com, x86@...nel.org,
	rth@...ddle.net, linux@....linux.org.uk, msalter@...hat.com,
	starvik@...s.com, dhowells@...hat.com, tony.luck@...el.com,
	benh@...nel.crashing.org, takata@...ux-m32r.org,
	geert@...ux-m68k.org, james.hogan@...tec.com, monstr@...str.eu,
	ralf@...ux-mips.org, jonas@...thpole.se, rkuo@...eaurora.org,
	schwidefsky@...ibm.com, liqin.chen@...plusct.com,
	davem@...emloft.net, lethal@...ux-sh.org, chris@...kel.net,
	cmetcalf@...era.com, ysato@...rs.sourceforge.jp,
	gxt@...c.pku.edu.cn, jdike@...toit.com
Subject: Re: [PATCH v2 5/5] dump_stack: unify debug information printed by
 show_regs()

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/