All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Sasha Levin <sasha.levin@oracle.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Ingo Molnar <mingo@kernel.org>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] kthreads: kill CLONE_KERNEL, change kernel_thread(kernel_init) to avoid CLONE_SIGHAND
Date: Fri, 16 May 2014 17:35:30 +0200	[thread overview]
Message-ID: <20140516153530.GA30751@redhat.com> (raw)
In-Reply-To: <53761FDB.10806@oracle.com>

On 05/16, Sasha Levin wrote:
>
> On 04/13/2014 03:56 PM, Oleg Nesterov wrote:
> > 1. Remove CLONE_KERNEL, it has no users and it is dangerous.
> >
> >    The (old) comment says "List of flags we want to share for kernel
> >    threads" but this is not true, we do not want to share ->sighand by
> >    default. This flag can only be used if the caller is sure that both
> >    parent/child will never play with signals (say, allow_signal/etc).
> >
> > 2. Change rest_init() to clone kernel_init() without CLONE_SIGHAND.
> >
> >    In this case CLONE_SIGHAND does not really hurt, and it looks like
> >    optimization because copy_sighand() can avoid kmem_cache_alloc().
> >
> >    But in fact this only adds the minor pessimization. kernel_init()
> >    is going to exec the init process, and de_thread() will need to
> >    unshare ->sighand and do kmem_cache_alloc(sighand_cachep) anyway,
> >    but it needs to do more work and take tasklist_lock and siglock.
> >
> > Signed-off-by: Oleg Nesterov <oleg@redhat.com>
>
> Hi Oleg,
>
> This patch triggers a hang during boot in my KVM guest.

Hmm... How??? ;)

> There are no
> messages or anything, it just hangs right before init is supposed to
> start up.

Do you mean kernel_init() hangs somewhere in run_init_process() paths?

> I've narrowed it down a bit, and it's the removal of CLONE_SIGHAND
> that's bothering it.

This must not be possible, I bet there is something else which should
be fixed.

> Removing CLONE_FS and CLONE_FILES doesn't
> cause the hang on boot.

kernel_thread(kernel_init) doesn't use CLONE_FILES ?

Oleg.


  reply	other threads:[~2014-05-16 15:36 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-13 19:56 [PATCH] kthreads: kill CLONE_KERNEL, change kernel_thread(kernel_init) to avoid CLONE_SIGHAND Oleg Nesterov
2014-04-14 11:05 ` Peter Zijlstra
2014-04-14 13:51 ` Steven Rostedt
2014-05-16 14:25 ` Sasha Levin
2014-05-16 15:35   ` Oleg Nesterov [this message]
2014-05-19 15:21     ` Sasha Levin

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=20140516153530.GA30751@redhat.com \
    --to=oleg@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=fweisbec@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=sasha.levin@oracle.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.