Messages in this thread | | | From | Roland McGrath <> | Subject | Re: [PATCH -mm v6] tracepoint: Add signal coredump tracepoint | Date | Mon, 26 Apr 2010 10:59:24 -0700 (PDT) |
| |
> 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
| |