Re: ptracing a task from core_pattern pipe

[Oleg Nesterov <oleg@redhat.com>]

Hi Daniel,

Sorry, I can't understand your email...

On 03/15, Daniel Walker wrote:
>
> I was writing an application to ptrace a process which is dumping core
> from inside the pipe application for core_pattern.

This was never possible. And never will, I think.

> So for example you make core pattern equal to something like
> "|/bin/corepipe_app" then the kernel runs that app prior to actually
> killing the process that failed.

No, the dumper "kills" itself (but see below) and the starts
/bin/corepipe_app.

> Before the pipe application runs it puts SIGKILL on the pending signal
> list for the failed application.

if "it" means the dumper thread then "almost true". It kills other threads
but not itself.

(Just in case, this was recently changed. After
 coredump-ensure-that-sigkill-always-kills-the-dumping-thread.patch in -mm
 tree the dumper doesn't run in SIGNAL_GROUP_EXIT, but probably this
 doesn't matter)

> However the application can't run.

Which application? Both the dumper and corepipe_app can run...

> This commit,
>
> 9899d11f654474d2d54ea52ceaa2a1f4db3abd68

> seems to put a damper on ptracing the application at this point.

How can this commit make any difference? It should not.

> So I wanted to see what you think of all this.. Can we add an exception
> to this which would allow operations on a task which is dumping core,

Which ptrace request you think should work at this stage? The coredumping
task is dying, it can't report, say, signal or syscall. It can report
nothing except PTRACE_EVENT_EXIT, but only after it closes the pipe.

> but still has SIGKILL pending. The other way would be to not add SIGKILL
> till after the pipe app runs.

See above.

> As of right now I can PTRACE_ATTACH, but the operations all fail with
> -ESRCH .

Sure, because the tracee doesn't (and shouldn't) stop, iow it doesn't
report any event.



Could you explain what actually you are trying to do? And what exactly
doesn't work as you expected?

Now that the coredump is killable (-mm patches), _perhaps_ we can, say,
add PTRACE_EVENT_CORED_DUMPED reported after binfmt->core_dump(). Not
sure this is what you need...

Oleg.