All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Kirill Tkhai <tkhai@yandex.ru>
Cc: Kirill Tkhai <ktkhai@parallels.com>,
	linux-kernel@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Vladimir Davydov <vdavydov@parallels.com>
Subject: Re: [PATCH v3] sched/numa: fix unsafe get_task_struct() in task_numa_assign()
Date: Mon, 20 Oct 2014 22:50:06 +0200	[thread overview]
Message-ID: <20141020205006.GA2500@redhat.com> (raw)
In-Reply-To: <54456E26.2000103@yandex.ru>

On 10/21, Kirill Tkhai wrote:
>
> I think generic helper is a good idea. The prototype looks OK.
>
> But I'm a little doubt about retry loop. If this helper is generic and
> one day it may move to ./include directory,

Well, if we add a generic helper I think it should be exported even if
it has a single caller. But I agree this probably needs a justification
too.

> isn't there a probability
> people will use it wrong? This loop may bring delays or something bad.

Yes, I thought about livelock too. OK, we can remove it, just
s/goto retry/return NULL/. Or, perhaps better, return ERR_PTR(-EAGAIN)
so that the caller can know that retry is possible.

I do not really mind, and we can reconsider this later. And I will not
argue if you prefer to add the rq->curr specific hack (like your patch
does).

> And since we still depends on RCU, I'd suggest to add its lockdep assert.

Agreed.

Let me explain what I personally dislike in v3:

	- I think that we do not have enough reasons for
	  SLAB_DESTROY_BY_RCU. This is the serious change.

	  probe_kernel_read() looks better to me, and hopefully
	  IS_ENABLED(DEBUG_PAGEALLOC) can make it conditional.

	- PF_EXITING was fine in task_numa_compare(), but if we
	  move this logic into a helper (even if it is not exported)
	  then I think we need a more specific check. sighand == NULL
	  looks better to me because it clearly connects to
	  release_task() which makes this task_struct "rcu-unsafe".

	- Again, perhaps we should start we a simple and stupid fix.
	  We can do get_task_struct() under rq->lock or, if nothing
	  else, just

	  	raw_spin_lock_irq(&rq->lock);
	  	cur = rq->curr;
	  	if (is_idle_task(cur) || (cur->flags & PF_EXITING))
	  		cur = NULL;
	  	raw_spin_unlock_irq(&rq->lock);

Either way, I hope you will send v4 ;)

But probably you should wait for for Peter's opinion first.

Oleg.


  reply	other threads:[~2014-10-20 20:53 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 [this message]
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
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=20141020205006.GA2500@redhat.com \
    --to=oleg@redhat.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.