linux-kernel - Re: [PATCH -mm v6] tracepoint: Add signal coredump tracepoint

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] [day] [month] [year] [list]

Message-Id: <20100426175924.B8B501AD11@magilla.sf.frob.com>
Date:	Mon, 26 Apr 2010 10:59:24 -0700 (PDT)
From:	Roland McGrath <roland@...hat.com>
To:	Masami Hiramatsu <mhiramat@...hat.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	lkml <linux-kernel@...r.kernel.org>,
	systemtap <systemtap@...rces.redhat.com>,
	DLE <dle-develop@...ts.sourceforge.net>,
	Oleg Nesterov <oleg@...hat.com>,
	Jason Baron <jbaron@...hat.com>, Ingo Molnar <mingo@...e.hu>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
Subject: Re: [PATCH -mm v6] tracepoint: Add signal coredump tracepoint

> I think retval decoding will help us to find which condition caused
> failing the coredump, by reading the source code.
> So, I'd like to leave it.

Having a proper -ERR* code for the cases that have one in your patch is
certainly good.  What I meant was using the 0/1 values to distinguish
success vs failure from the binfmt dumper.  If there were separate
tracepoints for success vs failure, then the failure one should certainly
get an error code, which would be 0 when the error (or refusal to dump) was
due to some decision made by the binfmt code rather than a write error.

> Hmm, indeed. it seems that those tracepoints are useful for finding
> unexpected delays from coredump...
> OK, I'll try to add those tracepoints. Would you have any recommended data
> which those tracepoints should record?

Whatever is handy, I suppose.  i.e. of the things you pass into the
tracepoint now, give each tracepoint the subset that makes sense for its
case.  For the tracepoint after synchronization and before dumping, I think
it should be more or less right after format_corename() and it can pass the
ispipe, corename, cprm.limit and binfmt->min_coredump values that affect
the tests immediately thereafter (as well as the full cprm and binfmt
pointers).

Thanks,
Roland
--
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/