Comment 22 for bug 1920874

`udevadm monitor` shows events as follows while removing memory card of these card reader in kernel 5.8

```

KERNEL[188.377042] change /devices/pci0000:00/0000:00:14.0/usb2/2-9/2-9:1.0/host5/target5:0:0/5:0:0:0/block/sdc (block)
UDEV [188.383261] remove /devices/pci0000:00/0000:00:14.0/usb2/2-9/2-9:1.0/host5/target5:0:0/5:0:0:0/block/sdc (block)
KERNEL[188.390887] change /devices/pci0000:00/0000:00:14.0/usb2/2-9/2-9:1.0/host5/target5:0:0/5:0:0:0/block/sdc (block)
UDEV [188.396012] remove /devices/pci0000:00/0000:00:14.0/usb2/2-9/2-9:1.0/host5/target5:0:0/5:0:0:0/block/sdc (block)
```

In Kernel later then 5.9.0-rc3, the udevadm shows only `change` event instead of `remove`.

Removing memory cards on these card readers do not trigger remove event for scsi_disk, scsi_device, scsi_generic, or usb unbind like other card readers do.

After kernel bisecting, I found the commit `block: don't clear bd_invalidated in check_disk_size_change` (https://github.com/torvalds/linux/commit/6540fbf6b634071950f01ee4e4194e2ea8ca72d1) makes the difference.

When removing memory card on kernel 5.10, the GD_NEED_PART_SCAN bit is cleared in bdev_disk_changed() but the blk_drop_partitions() returns -EBUSY right after. It makes the consequent __blkdev_get have no chance to invoke bdev_disk_changed() again, thus the partitions has no chance to be removed until the memory card re-inserted.

Reverting the commit or clear the GD_NEED_PART_SCAN bit after blk_drop_partitions done can fix the issue.