On Mon, Jun 13, 2016 at 12:24:52AM +0200, Jilles Tjoelker wrote:
> On Thu, Jun 09, 2016 at 07:34:55AM +0300, Konstantin Belousov wrote:
> > On Wed, Jun 08, 2016 at 11:17:44PM +0200, Jilles Tjoelker wrote:
> > > On Wed, Jun 08, 2016 at 04:56:35PM +0300, Konstantin Belousov wrote:
> > > > On Wed, Jun
On Thu, Jun 09, 2016 at 07:34:55AM +0300, Konstantin Belousov wrote:
> On Wed, Jun 08, 2016 at 11:17:44PM +0200, Jilles Tjoelker wrote:
> > On Wed, Jun 08, 2016 at 04:56:35PM +0300, Konstantin Belousov wrote:
> > > On Wed, Jun 08, 2016 at 06:35:08AM -0700, Mark Johnston wrote:
> > > > On Wed, Jun 0
On Wed, Jun 08, 2016 at 11:17:44PM +0200, Jilles Tjoelker wrote:
> On Wed, Jun 08, 2016 at 04:56:35PM +0300, Konstantin Belousov wrote:
> > On Wed, Jun 08, 2016 at 06:35:08AM -0700, Mark Johnston wrote:
> > > On Wed, Jun 08, 2016 at 07:30:55AM +0300, Konstantin Belousov wrote:
> > > > On Tue, Jun 0
On Wed, Jun 08, 2016 at 04:56:35PM +0300, Konstantin Belousov wrote:
> On Wed, Jun 08, 2016 at 06:35:08AM -0700, Mark Johnston wrote:
> > On Wed, Jun 08, 2016 at 07:30:55AM +0300, Konstantin Belousov wrote:
> > > On Tue, Jun 07, 2016 at 11:19:19PM +0200, Jilles Tjoelker wrote:
> > > > I also wonder
On Wed, Jun 08, 2016 at 04:56:35PM +0300, Konstantin Belousov wrote:
> On Wed, Jun 08, 2016 at 06:35:08AM -0700, Mark Johnston wrote:
> > On Wed, Jun 08, 2016 at 07:30:55AM +0300, Konstantin Belousov wrote:
> > > On Tue, Jun 07, 2016 at 11:19:19PM +0200, Jilles Tjoelker wrote:
> > > > I also wonder
On Wed, Jun 08, 2016 at 06:35:08AM -0700, Mark Johnston wrote:
> On Wed, Jun 08, 2016 at 07:30:55AM +0300, Konstantin Belousov wrote:
> > On Tue, Jun 07, 2016 at 11:19:19PM +0200, Jilles Tjoelker wrote:
> > > I also wonder whether we may be overengineering things here. Perhaps
> > > the advlock sle
On Wed, Jun 08, 2016 at 07:30:55AM +0300, Konstantin Belousov wrote:
> On Tue, Jun 07, 2016 at 11:19:19PM +0200, Jilles Tjoelker wrote:
> > In this case it is clear which sleep(9) calls should be affected so it
> > may be better to avoid more hidden state.
> In this case yes, but apparently some ou
On Tue, Jun 07, 2016 at 11:19:19PM +0200, Jilles Tjoelker wrote:
> On Tue, Jun 07, 2016 at 07:01:55PM +0300, Konstantin Belousov wrote:
> > On Tue, Jun 07, 2016 at 04:24:53PM +0200, Jilles Tjoelker wrote:
> > > On Tue, Jun 07, 2016 at 07:29:56AM +0300, Konstantin Belousov wrote:
> > > > This looks
On Tue, Jun 07, 2016 at 07:01:55PM +0300, Konstantin Belousov wrote:
> On Tue, Jun 07, 2016 at 04:24:53PM +0200, Jilles Tjoelker wrote:
> > On Tue, Jun 07, 2016 at 07:29:56AM +0300, Konstantin Belousov wrote:
> > > This looks as if we should not ignore suspension requests in
> > > thread_suspend_ch
On Tue, Jun 07, 2016 at 07:01:55PM +0300, Konstantin Belousov wrote:
> On Tue, Jun 07, 2016 at 04:24:53PM +0200, Jilles Tjoelker wrote:
> > On Tue, Jun 07, 2016 at 07:29:56AM +0300, Konstantin Belousov wrote:
> > > This looks as if we should not ignore suspension requests in
> > > thread_suspend_ch
On Tue, Jun 07, 2016 at 04:24:53PM +0200, Jilles Tjoelker wrote:
> On Tue, Jun 07, 2016 at 07:29:56AM +0300, Konstantin Belousov wrote:
> > 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 (
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 = 0x
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
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+0x3
On Tue, Jun 07, 2016 at 05:46:10AM +0300, Konstantin Belousov wrote:
> On Mon, Jun 06, 2016 at 10:13:11AM -0700, Mark Johnston wrote:
> > On Sat, Jun 04, 2016 at 12:32:36PM +0300, Konstantin Belousov wrote:
> What statement was not true: that your code sets TDF_SBDRY, or that
> the lf_advlock() fun
On Mon, Jun 6, 2016 at 7:46 PM, Konstantin Belousov wrote:
> On Mon, Jun 06, 2016 at 10:13:11AM -0700, Mark Johnston wrote:
>> On Sat, Jun 04, 2016 at 12:32:36PM +0300, Konstantin Belousov wrote:
>> > Does your fs both set TDF_SBDRY and call lf_advlock()/lf_advlockasync() ?
>>
>> It doesn't. This
On Mon, Jun 06, 2016 at 10:13:11AM -0700, Mark Johnston wrote:
> On Sat, Jun 04, 2016 at 12:32:36PM +0300, Konstantin Belousov wrote:
> > Does your fs both set TDF_SBDRY and call lf_advlock()/lf_advlockasync() ?
>
> It doesn't. This code belongs to a general framework for distributed FS
> locks; i
On Sat, Jun 04, 2016 at 12:32:36PM +0300, Konstantin Belousov wrote:
> On Fri, Jun 03, 2016 at 07:23:47PM -0700, Mark Johnston wrote:
> > Hi,
> >
> > I've recently observed a hang in a multi-threaded process that had hit
> > an assertion failure and was attempting to dump core. One thread was
> >
On Fri, Jun 03, 2016 at 07:23:47PM -0700, Mark Johnston wrote:
> Hi,
>
> I've recently observed a hang in a multi-threaded process that had hit
> an assertion failure and was attempting to dump core. One thread was
> sleeping interruptibly on an advisory lock with TDF_SBDRY set (our
> filesystem s
Hi,
I've recently observed a hang in a multi-threaded process that had hit
an assertion failure and was attempting to dump core. One thread was
sleeping interruptibly on an advisory lock with TDF_SBDRY set (our
filesystem sets VFCF_SBDRY). SIGABRT caused the receipient thread to
suspend other thre
20 matches
Mail list logo