aboutsummaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/gecko.py
diff options
context:
space:
mode:
authorMikulas Patocka <mpatocka@redhat.com>2024-09-13 15:05:18 +0200
committerMikulas Patocka <mpatocka@redhat.com>2024-09-15 21:02:54 +0200
commitc8691cd0fc11197515ed148de0780d927bfca38b (patch)
tree5ac0b3519f9bf7d5b6e69a1f74d6c645ec479eef /tools/perf/scripts/python/gecko.py
parent9c2010bccc0ce012f52de18ebd0c3add241f75b8 (diff)
Revert "dm: requeue IO if mapping table not yet available"
This reverts commit fa247089de9936a46e290d4724cb5f0b845600f5. The following sequence of commands causes a livelock - there will be workqueue process looping and consuming 100% CPU: dmsetup create --notable test truncate -s 1MiB testdata losetup /dev/loop0 testdata dmsetup load test --table '0 2048 linear /dev/loop0 0' dd if=/dev/zero of=/dev/dm-0 bs=16k count=1 conv=fdatasync The livelock is caused by the commit fa247089de99. The commit claims that it fixes a race condition, however, it is unknown what the actual race condition is and what program is involved in the race condition. When the inactive table is loaded, the nodes /dev/dm-0 and /sys/block/dm-0 are created. /dev/dm-0 has zero size at this point. When the device is suspended and resumed, the nodes /dev/mapper/test and /dev/disk/* are created. If some program opens a block device before it is created by dmsetup or lvm, the program is buggy, so dm could just report an error as it used to do before. Reported-by: Zdenek Kabelac <zkabelac@redhat.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Fixes: fa247089de99 ("dm: requeue IO if mapping table not yet available")
Diffstat (limited to 'tools/perf/scripts/python/gecko.py')
0 files changed, 0 insertions, 0 deletions