Re: arch_ptrace_attach() without ptrace_traceme()?

Re: arch_ptrace_attach() without ptrace_traceme()?

[Oleg Nesterov]

(add lkml)

On 06/27, penguin-kernel@i-love.sakura.ne.jp wrote:
>
> Regarding commit f1671f6d "ptrace: fix exit_ptrace() vs ptrace_traceme() race",
> is calling arch_ptrace_attach() when ptrace_traceme() returned 0 without doing
> anything (due to PF_EXITING race) expected behavior?

Hmm. Good point, I thinks this should be fixed.

Thanks!

Oleg.

Re: arch_ptrace_attach() without ptrace_traceme()?

[Oleg Nesterov]

On 06/27, Oleg Nesterov wrote:
>
> On 06/27, penguin-kernel@i-love.sakura.ne.jp wrote:
> >
> > Regarding commit f1671f6d "ptrace: fix exit_ptrace() vs ptrace_traceme() race",
> > is calling arch_ptrace_attach() when ptrace_traceme() returned 0 without doing
> > anything (due to PF_EXITING race) expected behavior?
>
> Hmm. Good point, I thinks this should be fixed.

But it is not clear how we can fix this, perhaps we should ignore this
problem...

arch_ptrace_attach() is inherently racy when PTRACE_TRACEME is called.
Please note that f1671f6d did not introduce this race, although I have
to admit I didn't notice this problem when I did this patch.

The race with PF_EXITING you described doesn't differ from another
scenario. PF_EXITING is not set, ptrace_traceme() actually attaches
the caller, but its paren exits and untraces it before it does
arch_ptrace_attach().

If only I knew what arch_ptrace_attach() can do in general ;) But
probably it should be paired with ptrace_disable(), and it is not
called when the tracer detaches on exit anyway. So I think we can
ignore this race.

Oleg.