| Summary: | Leaking partition table nodes on loop device | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Zdenek Kabelac <zkabelac> |
| Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> |
| Status: | NEW --- | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rawhide | CC: | bcl, gansalmon, ichavero, itamar, jonathan, kernel-maint, kzak, madhu.chinakonda, mchehab |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | Type: | Bug | |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
From my point of view problem is kernel. The kernel reaction to LOOP_CLR_FD ioctl is inconsistent: 1) if /dev/loopNpN partitions have been created by LO_FLAGS_PARTSCAN (losetup -P) then LOOP_CLR_FD ioctl generates "remove" events for partitions too 2) if /dev/loopNpN partitions have been created by re-read ioctl (partprobe) then LOOP_CLR_FD ioctl generates "remove" events for master non-partiton device only and partitions nodes remain in /dev |
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: