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

[Roland McGrath <roland@redhat.com>]

> 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