From: Oleg Nesterov <oleg@redhat.com>
To: Suren Baghdasaryan <surenb@google.com>
Cc: akpm@linux-foundation.org, mhocko@suse.com, brauner@kernel.org,
tandersen@netflix.com, bigeasy@linutronix.de,
vincent.whitchurch@axis.com, ardb@kernel.org,
linux-kernel@vger.kernel.org, Martin Liu <liumartin@google.com>,
Minchan Kim <minchan@google.com>
Subject: Re: [PATCH 1/1] signal: on exit skip waiting for an ack from the tracer if it is frozen
Date: Wed, 3 Jul 2024 18:48:36 +0200 [thread overview]
Message-ID: <20240703164836.GC28444@redhat.com> (raw)
In-Reply-To: <CAJuCfpGh9EBqij+Ru_D4ieEHTVx7_a0N8odaOLCPYt3g0iVCQA@mail.gmail.com>
Suren, I am sorry for the late reply,
On 06/30, Suren Baghdasaryan wrote:
>
> > I think it would better to simply change ptrace_stop() to check TIF_MEMDIE
> > along with __fatal_signal_pending() and return in this case.
>
> I think this would not fix the case we are experiencing. In our case
> the tracee is killed from the userspace (TIF_MEMDIE is not set yet),
OK, I misunderstood the problem.
> gets stuck in ptrace_stop() waiting for an ack from the tracer and
> then is picked up by OOM-killer with the abovementioned consequences.
and __task_will_free_mem() returns true if SIGNAL_GROUP_EXIT is set...
Nevermind.
> > Of course, this won't fix all problems.
>
> As I mentioned, I'm not an expert in ptrace, so I'll gladly try any
> better solution if one is proposed.
I do not see any solution, sorry.
ptrace doesn't allow to intercept/nack SIGKILL, but at the same time it
happily allows the killed tracee to sleep in PTRACE_EVENT_EXIT. And even
another SIGKILL/whatever can't wake the tracee up.
This is historical behaviour, I do not see how can we change it. Any
change will break something.
Oleg.
next prev parent reply other threads:[~2024-07-03 16:50 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-28 17:32 [PATCH 1/1] signal: on exit skip waiting for an ack from the tracer if it is frozen Suren Baghdasaryan
2024-06-29 13:12 ` Oleg Nesterov
2024-06-30 19:12 ` Suren Baghdasaryan
2024-07-03 16:48 ` Oleg Nesterov [this message]
2024-07-03 18:23 ` Suren Baghdasaryan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240703164836.GC28444@redhat.com \
--to=oleg@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=ardb@kernel.org \
--cc=bigeasy@linutronix.de \
--cc=brauner@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=liumartin@google.com \
--cc=mhocko@suse.com \
--cc=minchan@google.com \
--cc=surenb@google.com \
--cc=tandersen@netflix.com \
--cc=vincent.whitchurch@axis.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.