On Thu, 2017-11-23 at 15:42 +0100, Sebastian Siewior wrote:
> On 2017-11-21 22:20:51 [+0100], Mike Galbraith wrote:
> > On Tue, 2017-11-21 at 14:56 -0500, Mikulas Patocka wrote:
> > >
> > > If we don't have any reason why it is needed to unplug block requests
> > > when
> > > a spinlock is taken
On 2017-11-21 22:20:51 [+0100], Mike Galbraith wrote:
> On Tue, 2017-11-21 at 14:56 -0500, Mikulas Patocka wrote:
> >
> > If we don't have any reason why it is needed to unplug block requests when
> > a spinlock is taken - so let's not do this.
>
> That's perfectly fine. I guess I shouldn't hav
On Tue, 2017-11-21 at 14:56 -0500, Mikulas Patocka wrote:
>
> If we don't have any reason why it is needed to unplug block requests when
> a spinlock is taken - so let's not do this.
That's perfectly fine. I guess I shouldn't have even mentioned having
encountered unplug at mutex being insuffic
On Tue, 21 Nov 2017, Mike Galbraith wrote:
> On Tue, 2017-11-21 at 11:11 -0500, Mikulas Patocka wrote:
> >
> > So, drop the spinlock unplugging and leave only mutex unplugging,
> > reproduce the deadlock and send the stacktraces.
>
> Nah, I reproduced it five years ago. Is any of that releva
On Tue, 2017-11-21 at 11:11 -0500, Mikulas Patocka wrote:
>
> So, drop the spinlock unplugging and leave only mutex unplugging,
> reproduce the deadlock and send the stacktraces.
Nah, I reproduced it five years ago. Is any of that relevant today?
Damned if I know. Your report was the first I'
On Tue, 21 Nov 2017, Mike Galbraith wrote:
> On Tue, 2017-11-21 at 09:37 +0100, Thomas Gleixner wrote:
> > On Tue, 21 Nov 2017, Mike Galbraith wrote:
> > > On Mon, 2017-11-20 at 16:33 -0500, Mikulas Patocka wrote:
> > > >
> > > > Is there some specific scenario where you need to call
> > > > b
On Tue, 2017-11-21 at 09:37 +0100, Thomas Gleixner wrote:
> On Tue, 21 Nov 2017, Mike Galbraith wrote:
> > On Mon, 2017-11-20 at 16:33 -0500, Mikulas Patocka wrote:
> > >
> > > Is there some specific scenario where you need to call
> > > blk_schedule_flush_plug from rt_spin_lock_fastlock?
> >
>
On Tue, 21 Nov 2017, Mike Galbraith wrote:
> On Mon, 2017-11-20 at 16:33 -0500, Mikulas Patocka wrote:
> >
> > Is there some specific scenario where you need to call
> > blk_schedule_flush_plug from rt_spin_lock_fastlock?
>
> Excellent question. What's the difference between not getting IO
> st
On Mon, 2017-11-20 at 16:33 -0500, Mikulas Patocka wrote:
>
> Is there some specific scenario where you need to call
> blk_schedule_flush_plug from rt_spin_lock_fastlock?
Excellent question. What's the difference between not getting IO
started because you meet a mutex with an rt_mutex under the
On Mon, 20 Nov 2017, Mikulas Patocka wrote:
>
>
> On Mon, 20 Nov 2017, Sebastian Siewior wrote:
>
> > On 2017-11-18 19:37:10 [+0100], Mike Galbraith wrote:
> > > Below is my 2012 3.0-rt version of that for reference; at that time we
> > > were using slab, and slab_lock referenced below was a
On Sat, 18 Nov 2017, Mike Galbraith wrote:
> On Fri, 2017-11-17 at 15:57 +0100, Sebastian Siewior wrote:
> > On 2017-11-13 12:56:53 [-0500], Mikulas Patocka wrote:
> > > Hi
> > Hi,
> >
> > > I'm submitting this patch for the CONFIG_PREEMPT_RT patch. It fixes
> > > deadlocks in device mapper wh
On Mon, 20 Nov 2017, Sebastian Siewior wrote:
> On 2017-11-18 19:37:10 [+0100], Mike Galbraith wrote:
> > Below is my 2012 3.0-rt version of that for reference; at that time we
> > were using slab, and slab_lock referenced below was a local_lock. The
> > comment came from crash analysis of a de
On Mon, 2017-11-20 at 13:43 +0100, Mike Galbraith wrote:
> The problem was converted spinlocks (and added RT locks).
But I suppose lockdep should gripe about that these days...
On Mon, 2017-11-20 at 11:53 +0100, Sebastian Siewior wrote:
>
> To your question whether or not delaying IO can cause any deadlocks is
> something that I can't answer and this something that would affect !RT,
> too. I tried to add lockdep to bit-spinlocks but this does not work
> because one conte
On 2017-11-18 19:37:10 [+0100], Mike Galbraith wrote:
> Below is my 2012 3.0-rt version of that for reference; at that time we
> were using slab, and slab_lock referenced below was a local_lock. The
> comment came from crash analysis of a deadlock I met before adding the
> (yeah, hacky) __migrate_
On Fri, 2017-11-17 at 15:57 +0100, Sebastian Siewior wrote:
> On 2017-11-13 12:56:53 [-0500], Mikulas Patocka wrote:
> > Hi
> Hi,
>
> > I'm submitting this patch for the CONFIG_PREEMPT_RT patch. It fixes
> > deadlocks in device mapper when real time preemption is used.
>
> applied, thank you.
B
On 2017-11-13 12:56:53 [-0500], Mikulas Patocka wrote:
> Hi
Hi,
> I'm submitting this patch for the CONFIG_PREEMPT_RT patch. It fixes
> deadlocks in device mapper when real time preemption is used.
applied, thank you.
> Mikulas
Sebastian
On Tue, 14 Nov 2017, Sebastian Siewior wrote:
> [ minimize CC ]
>
> On 2017-11-13 12:56:53 [-0500], Mikulas Patocka wrote:
> > Hi
> >
> > I'm submitting this patch for the CONFIG_PREEMPT_RT patch. It fixes
> > deadlocks in device mapper when real time preemption is used.
>
> I run into a EXT
Hi
I'm submitting this patch for the CONFIG_PREEMPT_RT patch. It fixes
deadlocks in device mapper when real time preemption is used.
Mikulas
From: Mikulas Patocka
When some block device driver creates a bio and submits it to another
block device driver, the bio is added to current->bio_list
19 matches
Mail list logo
