Description of problem:

When loop device is created WITHOUT '-P' option (so loop is not autonomously handling partition table)  there are not normally  /dev/loopXpY  nodes.

However when on such loop device is executed 'partprobe'  - the loop node appears (which seems to look like 'a good thing').

It looks like 'partprobe' calls:

ioctl(3, BLKPG, {BLKPG_ADD_PARTITION, ...)

This leads to udev processing:

KERNEL[] add      /devices/virtual/block/loopX/loopXp1 (block)
KERNEL[] change   /devices/virtual/block/loopX (block)
KERNEL[] change   /devices/virtual/block/loopX/loopXp1 (block)

Then on  'losetup -d"

open("/dev/loopX", O_RDONLY|O_CLOEXEC)  = 3
ioctl(3, LOOP_CLR_FD)                   = 0

maps to udev event:

KERNEL[] change   /devices/virtual/block/loopX (block)
UDEV  [] change   /devices/virtual/block/loopX (block)

But noone deleted partitions with major node 259 (blkext).

Then we may easily end-up with quite 'magical' moment in case such loop device is re-instantiated.

As after 'losetup' WITHOUT -P - there is  still /dev/loopXpY device.

It may lead to further confusion when 'kpartx -a' beings to be used.

It's quite unclear who responsible to resolve this bug.

Should kernel always send events to partitions ?
(i.e. in case of 'losetup -P' one can instantly see:
KERNEL[] change   /devices/virtual/block/loopX (block)
KERNEL[] remove   /devices/virtual/block/loopX/loopXp1 (block)

Maybe 'udev' should have extra rule for it? (but sounds crazy)

Possibly 'losetup -d' should take care of this ??

Anyway starting it here with 'partprobe' who initiated this :)


Version-Release number of selected component (if applicable):
kernel 4.8
parted-3.2-21

How reproducible:


Steps to Reproduce:
1. losetup  (WITHOUT -P)
2. create partition
3. run partprobe
4. drop loop device


Actual results:
partition nodes left in place

Expected results:
no partition nodes

Additional info: