tests/test-bdrv-graph-mod: add test_parallel_perm_update
commite6af4f0e9414d36c0f0baddfb274003c0e7d6ecb
authorVladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Wed, 28 Apr 2021 15:17:30 +0000 (28 18:17 +0300)
committerKevin Wolf <kwolf@redhat.com>
Fri, 30 Apr 2021 10:27:47 +0000 (30 12:27 +0200)
tree738f84ebb8931885fe91eb6c57f41ba4567dd6f0
parentd71cc67d6880c00ff45e8e26350233694aa4de72
tests/test-bdrv-graph-mod: add test_parallel_perm_update

Add test to show that simple DFS recursion order is not correct for
permission update. Correct order is topological-sort order, which will
be introduced later.

Consider the block driver which has two filter children: one active
with exclusive write access and one inactive with no specific
permissions.

And, these two children has a common base child, like this:

┌─────┐     ┌──────┐
│ fl2 │ ◀── │ top  │
└─────┘     └──────┘
  │           │
  │           │ w
  │           ▼
  │         ┌──────┐
  │         │ fl1  │
  │         └──────┘
  │           │
  │           │ w
  │           ▼
  │         ┌──────┐
  └───────▶ │ base │
            └──────┘

So, exclusive write is propagated.

Assume, we want to make fl2 active instead of fl1.
So, we set some option for top driver and do permission update.

If permission update (remember, it's DFS) goes first through
top->fl1->base branch it will succeed: it firstly drop exclusive write
permissions and than apply them for another BdrvChildren.
But if permission update goes first through top->fl2->base branch it
will fail, as when we try to update fl2->base child, old not yet
updated fl1->base child will be in conflict.

Now test fails, so it runs only with -d flag. To run do

  ./test-bdrv-graph-mod -d -p /bdrv-graph-mod/parallel-perm-update

from <build-directory>/tests.

Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Message-Id: <20210428151804.439460-3-vsementsov@virtuozzo.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
tests/unit/test-bdrv-graph-mod.c