Description

The issue beblow happens several times beforing the root
cause found:

  1. A `fdisk -l` process has being hung up for a long time;
  2. A image layer snapshot device is visiable to dmsetup, which
       should *not* happen because it should be deactivated after
       `Commit()`;

The backtrace of fdisk is always the same over time:

    [<ffffffff810bbc6a>] io_schedule+0x2a/0x80
    [<ffffffff81295a3f>] do_blockdev_direct_IO+0x1e9f/0x2f10
    [<ffffffff81296aea>] __blockdev_direct_IO+0x3a/0x40
    [<ffffffff81290e43>] blkdev_direct_IO+0x43/0x50
    [<ffffffff811b8a14>] generic_file_read_iter+0x374/0x960
    [<ffffffff81291ad5>] blkdev_read_iter+0x35/0x40
    [<ffffffff8125229b>] new_sync_read+0xfb/0x240
    [<ffffffff81252406>] __vfs_read+0x26/0x40
    [<ffffffff81252b96>] vfs_read+0x96/0x130
    [<ffffffff812540e5>] SyS_read+0x55/0xc0
    [<ffffffff81003c04>] do_syscall_64+0x74/0x180

Steps to reproduce the issue:
One reproducer is:
1. enlarge the race window by putting sleep seconds there;
2. run while true; do sudo fdisk -l; sleep 0.5; done on one terminal;
3. and pull image on another terminal;

Describe the results you received:

• fdisk -l IO hang on the image snapshot device

Describe the results you expected:

No process hang, and image snapshot device is not visible to dmsetup ls;

Output of containerd --version:

containerd --version
containerd github.com/containerd/containerd 1.2.5 05572c5e0a678f0d26c98e47582282c74a844c78

Any other relevant information: