public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Markus Metzger <markus.t.metzger@googlemail.com>
Cc: "Metzger, Markus T" <markus.t.metzger@intel.com>,
	"Kleen, Andi" <andi.kleen@intel.com>, Ingo Molnar <mingo@elte.hu>,
	Roland McGrath <roland@redhat.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [rfc] x86, bts: fix crash
Date: Fri, 27 Mar 2009 22:29:33 +0100	[thread overview]
Message-ID: <20090327212933.GA5325@redhat.com> (raw)
In-Reply-To: <1238175204.6077.18.camel@raistlin>

On 03/27, Markus Metzger wrote:
>
> Regarding the race on task->thread.ds_ctx between ds_release_bts() and
> ds_switch_to(), how would I prevent a task from being rescheduled for
> a small amount of time?

I don't see how we can do this. We can split wait_task_inactive() into
2 functions, the first one returns with task_rq_lock() held and interrupts
disabled. But this is nasty, and in any case wait_task_inactive(p) can't
force "p" to be deactivated.

Can't we do something different?

For simplicity, let's suppose that we have only task_struct->bts and it
is just a blob of memory which can be used by CPU somehow.

First, we add "struct rcu_head" into task_struct->bts, and then

	void free_bts((struct rcu_head *rcu)
	{
		struct bts_tracer *bts = container_of();
		...
		kfree(bts);
	}

	void ds_release_bts(struct bts_tracer *tracer)
	{
		struct task_struct *child = tracer->ds.context->task;
		struct bts_tracer *bts = child->bts;

		child->bts = NULL;

		// make sure child will NOT use ->bts
		// after the next context switch,
		// clear TIF_DS_AREA_MSR or something
		...

		call_rcu_sched(bts->rcu, free_bts);
	}

Now we can call ds_release_bts() from the atomic context (as we do
now).

Once again, the pseudo code above has nothing to do with reality,
just for illustration.

(as for the memory accounting, this is another issue, let's forget
 for now).

Oleg.


  reply	other threads:[~2009-03-27 21:33 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <928CFBE8E7CB0040959E56B4EA41A77E9260843D@irsmsx504.ger.corp.intel.com>
2009-03-26  1:58 ` [rfc] x86, bts: fix crash Oleg Nesterov
2009-03-27 15:01   ` Metzger, Markus T
2009-03-27 16:50     ` Oleg Nesterov
2009-03-27 17:33       ` Markus Metzger
2009-03-27 21:29         ` Oleg Nesterov [this message]
2009-03-30  7:24           ` Metzger, Markus T
2009-03-30 11:29             ` Metzger, Markus T
2009-03-30 13:29               ` Oleg Nesterov
2009-03-30 13:55                 ` Metzger, Markus T

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=20090327212933.GA5325@redhat.com \
    --to=oleg@redhat.com \
    --cc=andi.kleen@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=markus.t.metzger@googlemail.com \
    --cc=markus.t.metzger@intel.com \
    --cc=mingo@elte.hu \
    --cc=roland@redhat.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