All of lore.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 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.