All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Kirill Tkhai <tkhai@yandex.ru>,
	Kirill Tkhai <ktkhai@parallels.com>,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
	Vladimir Davydov <vdavydov@parallels.com>,
	cl@linux.com
Subject: Re: [PATCH v3] sched/numa: fix unsafe get_task_struct() in task_numa_assign()
Date: Wed, 22 Oct 2014 18:14:50 +0200	[thread overview]
Message-ID: <20141022161450.GA27607@redhat.com> (raw)
In-Reply-To: <20141022090954.GF12706@worktop.programming.kicks-ass.net>

On 10/22, Peter Zijlstra wrote:
>
> So I worry about cache aliasing (not an issue on x86), so by touching
> 'random' pages that might be freed and reissued to back userspace, we
> could be accessing the one page through multiple virtual mappings which
> therefore result in aliases.

Or this page can be vmalloc'ed. Yes, but we do not care. Although this
was one of the reasons why the 2nd version of xxx() checks ->sighand at
the end, even if this is not needed correctness-wise.

Let's look at the code again,

	struct task_struct *xxx(struct task_struct **ptask)
	{
		struct task_struct *task;
		struct sighand_struct *sighand;

	retry:
		task = ACCESS_ONCE(*ptask);
		if (!task)
			return task;

		if (IS_ENABLED(CONFIG_DEBUG_PAGEALLOC)) {
			if (probe_kernel_read(&sighand, &task->sighand, sizeof(sighand)))
				goto retry;
		} else {
			sighand = task->sighand;
		}

(this if/else should go into a separare helper)

		/*
		 * Pairs with atomic_dec_and_test() in put_task_struct(task).
		 * If we have read the freed/reused memory, we must see that
		 * the pointer was updated.
		 */
		smp_rmb();
		if (unlikely(task != ACCESS_ONCE(*ptask)))
			goto retry;

At this point we know that task_struct was not freed. Otherwise, since
this function assumes that "*ptask" must be cleared or updated before
the final put_task_struct(), we must notice that *ptask differs.

This means that we have read the correct value of ->sighand and the check
below is correct too. Even if ->sighand is not stable and can be already
NULL right after probe_kernel_read(), this doesn't matter.

And this also means that aliasing is not a problem. If it was freed we
could read the random value, but in this case we are not even going to
look at result.

		/*
		 * release_task(task) was already called; potentially before
		 * the caller took rcu_read_lock() and in this case it can be
		 * freed before rcu_read_unlock().
		 */
		if (!sighand)
			return NULL;
		return task;
	}

> SDBR avoids this issue by guaranteeing the page is not reissued for
> another purpose.

Yes, this is true.

> I'm not sure I can convince myself SLUB is correct here. How do we avoid
> cache aliasing.

Hmm. so perhaps I misunderstood your concern...

Do you mean that on !x86 a plain LOAD can "corrupt" the memory as it seen
from another vaddr?

If yes, this is another argument for a helper which reads the potentially
freed freed slab memory. get_freepointer_safe() can use it too and it can
be reimplemented in arch/xxx/include if necessary.

Or I missed your point completely?

Oleg.


  reply	other threads:[~2014-10-22 16:18 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-20 10:15 [PATCH v3] sched/numa: fix unsafe get_task_struct() in task_numa_assign() Kirill Tkhai
2014-10-20 14:47 ` Oleg Nesterov
2014-10-20 16:56   ` Oleg Nesterov
2014-10-20 18:27     ` Oleg Nesterov
2014-10-20 20:18       ` Kirill Tkhai
2014-10-20 20:50         ` Oleg Nesterov
2014-10-20 21:05           ` Kirill Tkhai
2014-10-20 21:34             ` Oleg Nesterov
2014-10-20 22:57               ` Peter Zijlstra
2014-10-21  9:45           ` Peter Zijlstra
2014-10-21 19:03             ` Oleg Nesterov
2014-10-21 20:03               ` Kirill Tkhai
2014-10-21 20:10                 ` Kirill Tkhai
2014-10-22  9:09               ` Peter Zijlstra
2014-10-22 16:14                 ` Oleg Nesterov [this message]
2014-10-22 16:37                   ` Peter Zijlstra
2014-10-22 18:14                     ` introduce probe_slab_address? (Was: sched/numa: fix unsafe get_task_struct() in task_numa_assign()) Oleg Nesterov
2014-10-22 18:59                       ` introduce probe_slab_address? David Miller
2014-10-22 19:42                         ` Oleg Nesterov
2014-10-22 20:08                           ` David Miller
2014-10-22 20:20                             ` Oleg Nesterov
2014-10-24  9:44                         ` Peter Zijlstra

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=20141022161450.GA27607@redhat.com \
    --to=oleg@redhat.com \
    --cc=cl@linux.com \
    --cc=ktkhai@parallels.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=tkhai@yandex.ru \
    --cc=vdavydov@parallels.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.