Bug 1170048

Summary:	losetup --partscan won't create partition devices
Product:	[openSUSE] openSUSE Tumbleweed	Reporter:	Michal Koutný <mkoutny>
Component:	Kernel	Assignee:	systemd maintainers <systemd-maintainers>
Status:	RESOLVED DUPLICATE	QA Contact:	E-mail List <qa-bugs>
Severity:	Normal
Priority:	P5 - None	CC:	sbrabec
Version:	Current
Target Milestone:	---
Hardware:	Other
OS:	Other
Whiteboard:
Found By:	---	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---
Bug Depends on:	1169932
Bug Blocks:

Description Michal Koutný 2020-04-21 09:49:31 UTC

## Environment

kernel-default-5.7.rc1-1.1.g84ddad4.x86_64
systemd-244-3.1.x86_64
util-linux-2.35.1-1.1.x86_64


## Expected behavior

image.0.raw is a whole dist image file
# losetup --find --show --partscan ~/image.0.raw

would created devices for the image plus the partitions
/dev/loop0
/dev/loop0p1
/dev/loop0p2


## Actual behavior

# losetup --find --show --partscan ~/image.0.raw

creates only the top device /dev/loop0

> Apr 20 16:54:30 blackbook kernel: loop_reread_partitions: partition scan of loop2 (/home/mkoutny/image.0.raw) failed (rc=-16)


## Observation
- this started happening after upgrade of kernel-default (from
  5.6.0-rc7-1.g0801cd7-default) or util-linux (from 2.34-4.4)
- SIGSTOPping udevd during losetup call allows the scan to succeed

Comment 1 Michal Koutný 2020-04-21 09:50:43 UTC

The trigger are the two kernel patches that fixed "locking":

> d3ef5536274f ("block: fix busy device checking in blk_drop_partitions")
> cb6b771b05c3 ("block: fix busy device checking in blk_drop_partitions again")

losetup isn't "atomic" operation:
> strace -e ioctl losetup --find --show --partscan ~/image.0.raw 
> (1) ioctl(3, LOOP_CTL_GET_FREE)             = 1
>     ioctl(4, LOOP_SET_FD, 3)                = 0
> (2) ioctl(4, LOOP_SET_STATUS64, {lo_offset=0, lo_number=0, lo_flags=LO_FLAGS_PARTSCAN, lo_file_name="/home/mkoutny/image.0.raw", ...}) = 0

Somewhere between (1) and (2) uevent is triggered and udevd opens the device
and (2) fails. Note that ioctl apparently succeeds (EBUSY is swallowed in
kernel).

TBH, I don't know what a good fix would be. Perhaps udevd being more careful when processing loop uevents? (I'm reassigning to systemd-maintainers, CCing util-linux maintainer).

Also keyword: mkosi