Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 6 Jun 2016 21:50:47 -0700
From:      Mark Johnston <markj@FreeBSD.org>
To:        Konstantin Belousov <kostikbel@gmail.com>
Cc:        freebsd-current@FreeBSD.org, cem@FreeBSD.org
Subject:   Re: thread suspension when dumping core
Message-ID:  <20160607045047.GB29017@wkstn-mjohnston.west.isilon.com>
In-Reply-To: <20160607042956.GM38613@kib.kiev.ua>
References:  <20160604022347.GA1096@wkstn-mjohnston.west.isilon.com> <20160604093236.GA38613@kib.kiev.ua> <20160606171311.GC10101@wkstn-mjohnston.west.isilon.com> <20160607024610.GI38613@kib.kiev.ua> <20160607041741.GA29017@wkstn-mjohnston.west.isilon.com> <20160607042956.GM38613@kib.kiev.ua>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jun 07, 2016 at 07:29:56AM +0300, Konstantin Belousov wrote:
> On Mon, Jun 06, 2016 at 09:17:41PM -0700, Mark Johnston wrote:
> > Sure, see below. For reference:
> > 
> > td_flags = 0xa84c = INMEM | SINTR | CANSWAP | ASTPENDING | SBDRY | NEEDSUSPCHK
> > td_pflags = 0
> > td_inhibitors = 0x2 = SLEEPING
> > td_locks = 0
> > 
> > stack:
> > mi_switch+0x21e sleepq_catch_signals+0x377 sleepq_wait_sig+0xb _sleep+0x29d ...
> > 
> > p_flag = 0x10080080 = INMEM | STOPPED_SINGLE | HADTHREADS
> > p_flag2 = 0
> > 
> > The thread is sleeping interruptibly. The NEEDSUSPCHK flag is set, yet the
> > SLEEPABORT flag is not, so the thread can not have been sleeping when
> > thread_single() was called - else sleepq_abort() would have been
> > invoked and set SLEEPABORT. We are at the second sleepq_switch() call in
> > sleepq_catch_signals(), and no signal was pending, so we called
> > thread_suspend_check(), which returned 0 because of SBDRY. So we went to
> > sleep.
> 
> This looks as if we should not ignore suspension requests in
> thread_suspend_check() completely in TDF_SBDRY case, but return either
> EINTR or ERESTART (most likely ERESTART). Note that the goal of
> TDF_SBDRY is to avoid suspending in the protected region, not to make an
> impression that the suspension does not occur at all.

Thanks, that sounds right to me. It results in unified behaviour for
TDF_SBDRY regardless of whether the suspension attempt took place before
or after the thread went to sleep, and seems like it does the right
thing in the single-threaded case as well.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160607045047.GB29017>