All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Nikolay Borisov <kernel@kyup.com>
Cc: "Linux-Kernel@Vger. Kernel. Org" <linux-kernel@vger.kernel.org>,
	riel@redhat.com, Peter Zijlstra <peterz@infradead.org>,
	Steven Rostedt <rostedt@goodmis.org>
Subject: Re: HARD LOCKUP: Strange hard lock up on spin_lock(&sighand->siglock);
Date: Mon, 3 Aug 2015 19:04:28 +0200	[thread overview]
Message-ID: <20150803170428.GA18618@redhat.com> (raw)
In-Reply-To: <55B629E9.6020207@kyup.com>

Sorry for delay, vacation.

I'll try to re-read your email later, just one note for now...

On 07/27, Nikolay Borisov wrote:
>
> Based on that I think could be happening is that the sighand itself is
> being freed while we are in the grace period inside __lock_task_sighand
> but the slab page itself is not freed as per the semantics of
> SLAB_DESTROY_BY_RCU. I looked up the source of this function in the
> latest kernels and saw that Oleg had put a comment clarifying the
> semantics but I'm still not convinced that it is safe. What if
> we are trying to lock the spinlock before this particular slab is
> initialised with sighand_ctor?

But this is not possible? ->sighand can never point to the uninitialized
struct sighand_struct.

Just in case... please note that if ->sighand was freed and then
re-allocated while __lock_task_sighand() spins under rcu_read_lock(),
sighand_ctor() won't be called again (due to SLAB_DESTROY_BY_RCU).
Perhaps this was the source of your confusion?

Oleg.


      parent reply	other threads:[~2015-08-03 17:06 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-27 12:54 HARD LOCKUP: Strange hard lock up on spin_lock(&sighand->siglock); Nikolay Borisov
2015-08-03 16:49 ` Steven Rostedt
2015-08-03 17:04 ` Oleg Nesterov [this message]

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=20150803170428.GA18618@redhat.com \
    --to=oleg@redhat.com \
    --cc=kernel@kyup.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=riel@redhat.com \
    --cc=rostedt@goodmis.org \
    /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.