On Thu, 2017-01-26 at 18:09 +0100, Sebastian Andrzej Siewior wrote:
> On 2017-01-25 19:29:49 [+0100], Mike Galbraith wrote:
> > On Wed, 2017-01-25 at 18:02 +0100, Sebastian Andrzej Siewior wrote:
> >
> > > > [ 341.960794]CPU0
> > > > [ 341.960795]
> > > > [ 341.960795]
On Thu, 2017-01-26 at 18:09 +0100, Sebastian Andrzej Siewior wrote:
> On 2017-01-25 19:29:49 [+0100], Mike Galbraith wrote:
> > On Wed, 2017-01-25 at 18:02 +0100, Sebastian Andrzej Siewior wrote:
> >
> > > > [ 341.960794]CPU0
> > > > [ 341.960795]
> > > > [ 341.960795]
On 2017-01-25 19:29:49 [+0100], Mike Galbraith wrote:
> On Wed, 2017-01-25 at 18:02 +0100, Sebastian Andrzej Siewior wrote:
>
> > > [ 341.960794]CPU0
> > > [ 341.960795]
> > > [ 341.960795] lock(btrfs-tree-00);
> > > [ 341.960795] lock(btrfs-tree-00);
> > > [
On 2017-01-25 19:29:49 [+0100], Mike Galbraith wrote:
> On Wed, 2017-01-25 at 18:02 +0100, Sebastian Andrzej Siewior wrote:
>
> > > [ 341.960794]CPU0
> > > [ 341.960795]
> > > [ 341.960795] lock(btrfs-tree-00);
> > > [ 341.960795] lock(btrfs-tree-00);
> > > [
On Wed, 2017-01-25 at 18:02 +0100, Sebastian Andrzej Siewior wrote:
> > [ 341.960794]CPU0
> > [ 341.960795]
> > [ 341.960795] lock(btrfs-tree-00);
> > [ 341.960795] lock(btrfs-tree-00);
> > [ 341.960796]
> > [ 341.960796] *** DEADLOCK ***
> > [ 341.960796]
> > [
On Wed, 2017-01-25 at 18:02 +0100, Sebastian Andrzej Siewior wrote:
> > [ 341.960794]CPU0
> > [ 341.960795]
> > [ 341.960795] lock(btrfs-tree-00);
> > [ 341.960795] lock(btrfs-tree-00);
> > [ 341.960796]
> > [ 341.960796] *** DEADLOCK ***
> > [ 341.960796]
> > [
On 2017-01-22 18:45:14 [+0100], Mike Galbraith wrote:
> RT does not have a way to describe its rwlock semantics to lockdep,
> leading to the btrfs false positive below. Btrfs maintains an array
> of keys which it assigns on the fly in order to avoid false positives
> in stock code, however, that
On 2017-01-22 18:45:14 [+0100], Mike Galbraith wrote:
> RT does not have a way to describe its rwlock semantics to lockdep,
> leading to the btrfs false positive below. Btrfs maintains an array
> of keys which it assigns on the fly in order to avoid false positives
> in stock code, however, that
On Sun, Jan 22, 2017 at 06:45:14PM +0100, Mike Galbraith wrote:
> On Sun, 2017-01-22 at 09:46 +0100, Mike Galbraith wrote:
> > Greetings btrfs/lockdep wizards,
> >
> > RT trees have trouble with the BTRFS lockdep positive avoidance lock
> > class dance (see disk-io.c). Seems the trouble is due
On Sun, Jan 22, 2017 at 06:45:14PM +0100, Mike Galbraith wrote:
> On Sun, 2017-01-22 at 09:46 +0100, Mike Galbraith wrote:
> > Greetings btrfs/lockdep wizards,
> >
> > RT trees have trouble with the BTRFS lockdep positive avoidance lock
> > class dance (see disk-io.c). Seems the trouble is due
On Sun, 2017-01-22 at 18:45 +0100, Mike Galbraith wrote:
> On Sun, 2017-01-22 at 09:46 +0100, Mike Galbraith wrote:
> > Greetings btrfs/lockdep wizards,
> >
> > RT trees have trouble with the BTRFS lockdep positive avoidance lock
> > class dance (see disk-io.c). Seems the trouble is due to RT
On Sun, 2017-01-22 at 18:45 +0100, Mike Galbraith wrote:
> On Sun, 2017-01-22 at 09:46 +0100, Mike Galbraith wrote:
> > Greetings btrfs/lockdep wizards,
> >
> > RT trees have trouble with the BTRFS lockdep positive avoidance lock
> > class dance (see disk-io.c). Seems the trouble is due to RT
> +>> > /*
> +>> > * Allow read-after-read or read-after-write recursion of the
> +>> > * same lock class for RT rwlocks.
> +>> > */
> +>> > if (read == 3 && (prev->read == 3 || prev->read == 0))
Pff, shoulda left it reader vs reader.. but
> +>> > /*
> +>> > * Allow read-after-read or read-after-write recursion of the
> +>> > * same lock class for RT rwlocks.
> +>> > */
> +>> > if (read == 3 && (prev->read == 3 || prev->read == 0))
Pff, shoulda left it reader vs reader.. but
On Sun, 2017-01-22 at 09:46 +0100, Mike Galbraith wrote:
> Greetings btrfs/lockdep wizards,
>
> RT trees have trouble with the BTRFS lockdep positive avoidance lock
> class dance (see disk-io.c). Seems the trouble is due to RT not having
> a means of telling lockdep that its rwlocks are
On Sun, 2017-01-22 at 09:46 +0100, Mike Galbraith wrote:
> Greetings btrfs/lockdep wizards,
>
> RT trees have trouble with the BTRFS lockdep positive avoidance lock
> class dance (see disk-io.c). Seems the trouble is due to RT not having
> a means of telling lockdep that its rwlocks are
Greetings btrfs/lockdep wizards,
RT trees have trouble with the BTRFS lockdep positive avoidance lock
class dance (see disk-io.c). Seems the trouble is due to RT not having
a means of telling lockdep that its rwlocks are recursive for read by
the lock owner only, combined with the BTRFS lock
Greetings btrfs/lockdep wizards,
RT trees have trouble with the BTRFS lockdep positive avoidance lock
class dance (see disk-io.c). Seems the trouble is due to RT not having
a means of telling lockdep that its rwlocks are recursive for read by
the lock owner only, combined with the BTRFS lock
18 matches
Mail list logo
