public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@tv-sign.ru>
To: Ingo Molnar <mingo@elte.hu>, Roland McGrath <roland@redhat.com>
Cc: Srivatsa Vaddagiri <vatsa@in.ibm.com>,
	linux-kernel@vger.kernel.org,
	Dipankar Sarma <dipankar@in.ibm.com>,
	Paul E McKenney <paulmck@us.ibm.com>,
	Gautham R Shenoy <ego@in.ibm.com>
Subject: rt ptracer can monopolize CPU (was: Cpu-Hotplug and Real-Time)
Date: Thu, 9 Aug 2007 21:03:53 +0400	[thread overview]
Message-ID: <20070809170353.GA82@tv-sign.ru> (raw)
In-Reply-To: <20070807151336.GA507@tv-sign.ru>

On 08/07, Oleg Nesterov wrote:
>
> On 08/07, Gautham R Shenoy wrote:
> >
> > A will now call kthread_bind(B, cpu1).
> > kthread_bind(), calls wait_task_inactive(B), to ensures that 
> > B has scheduled itself out.
> > 
> > B is still on the runqueue, so A calls yield() in wait_task_inactive().
> > But since A is the task with the highest prio, scheduler schedules it
> > back again.
> > 
> > Thus B never gets to run to schedule itself out.
> > A loops waiting for B to schedule out leading  to system hang.
> 
> But I think we have another case. An RT ptracer can share the same CPU
> with ptracee. The latter sets TASK_STOPPED, unlocks ->siglock, and takes
> a preemption. Ptracer does ptrace_check_attach(), sees TASK_STOPPED, and
> yields in wait_task_inactive.

Even simpler.

#include <stdio.h>
#include <signal.h>
#include <unistd.h>
#include <sys/ptrace.h>
#include <sys/wait.h>
#define	__USE_GNU
#include <sched.h>

void die(const char *msg)
{
	printf("ERR!! %s: %m\n", msg);
        kill(0, SIGKILL);
}

void set_cpu(int cpu)
{
	unsigned cpuval = 1 << cpu;
	if (sched_setaffinity(0, 4, (void*)&cpuval) < 0)
		die("setaffinity");
}

// __wake_up_parent() does SYNC wake up, we need a handler to provoke
// signal_wake_up().
// otherwise ptrace_stop() is not preempted after read_unlock(tasklist).
static void sigchld(int sig)
{
}

int main(void)
{
	set_cpu(0);

	int pid = fork();
	if (!pid)
		for (;;)
			;

	struct sched_param sp = { 99 };
	if (sched_setscheduler(0, SCHED_FIFO, &sp))
		die("setscheduler");

	signal(SIGCHLD, sigchld);

	if (ptrace(PTRACE_ATTACH, pid, NULL, NULL))
		die("attach");

	wait(NULL);

	if (ptrace(PTRACE_DETACH, pid, NULL, NULL))
		die("detach");

	kill(pid, SIGKILL);

	return 0;
}

Locks CPU 0. Not a security problem, needs CAP_SYS_NICE and the task
could be reniced and killed, but still not good.

ptracee does ptrace_stop()->do_notify_parent_cldstop(), ptracer preempts
the child before it calls schedule(), ptrace(PTRACE_DETACH) goes to
wait_task_inactive() and yields forever.

Can we just replace yield() with schedule_timeout_uninterruptible(1) ?
wait_task_inactive() has no time-critical callers, and as it currently
used "on_rq" case is really unlikely.

Oleg.


  parent reply	other threads:[~2007-08-09 17:02 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-07 13:12 Cpu-Hotplug and Real-Time Gautham R Shenoy
2007-08-07 15:13 ` Oleg Nesterov
2007-08-07 17:33   ` Venki Pallipadi
2007-08-07 18:36     ` Oleg Nesterov
2007-08-09 17:03   ` Oleg Nesterov [this message]
2007-08-16 12:06     ` rt ptracer can monopolize CPU (was: Cpu-Hotplug and Real-Time) Gautham R Shenoy

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=20070809170353.GA82@tv-sign.ru \
    --to=oleg@tv-sign.ru \
    --cc=dipankar@in.ibm.com \
    --cc=ego@in.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=paulmck@us.ibm.com \
    --cc=roland@redhat.com \
    --cc=vatsa@in.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox