device busy attribute to prevent attaching devices whose children are in use - #144
piotrbartman wants to merge 4 commits into
Conversation
…tries previous udev script just deleted the parent entry when a partition was busy we keep this behavior for local use the "busy marker" is propagated to USB parent
if one of subdevices are locally used (e.g. in sys-usb) the parent is considered busy.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #144 +/- ##
==========================================
+ Coverage 71.24% 71.27% +0.02%
==========================================
Files 6 6
Lines 991 992 +1
==========================================
+ Hits 706 707 +1
Misses 285 285 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
OpenQA test summaryComplete test suite and dependencies: https://openqa.qubes-os.org/tests/overview?distri=qubesos&version=4.3&build=2026091923-devel&flavor=pull-requests Test run included the following:
New failures, excluding unstableCompared to: https://openqa.qubes-os.org/tests/overview?distri=qubesos&version=4.3&build=2026050504-devel&flavor=update
Failed tests9 failures
Fixed failuresCompared to: https://openqa.qubes-os.org/tests/176874#dependencies 37 fixed
Unstable testsDetails
Performance TestsPerformance degradation:No issues Remaining performance tests:111 tests
|
A device that is used (mounted etc.) locally by backend VM must not be handed to another one. This exposes them as a `used` ones. The marker means that the device, or it's child in use *locally*. Based on this marker and current attachment we discover if device is `busy`. Only backend VM writes to QubesDB and only about internal state. For this reason `busy` was renamed to `used` in QubesDB path. Mounting generates no block uevent, so qubes-block-mount-watcher polls the mount table and re-triggers the affected devices. `/qubes-device-usage-tracking` tells if a qube reports usage. `udev-qubes-vbd` handles detach `qubes.RefreshBlockDevices` handles attach
for different drivers previous solution does not work and we end up with garbage in qubesDB.
| @@ -0,0 +1,75 @@ | |||
| #!/usr/bin/python3 | |||
There was a problem hiding this comment.
I'm not really happy about yet another long-running python process in every VM due to memory usage... This one looks to take about 18MB.
IIUC there is no passive place to plug a hook into. Can this be in C, or maybe Rust? I'd expect a process like this should really need just a couple of kilobytes of memory, definitely below 1MB...
There was a problem hiding this comment.
OK, I think C is the better fit here since there aren't many reasons to introduce rust: poll() needs an unsafe extern regardless, and the only mountinfo field we parse is major:minor, which comes before the mount point, so no malicious string ever reaches the parser.
About "another resident process": the used markers only matter on lists or attaches, so qubesd could just call qubes.RefreshBlockDevices before a listing and we could drop the watcher. Drawbacks: a qrexec call per listing (the widget lists often), listing turning into a blocking call (not great) instead of a QubesDB read, and potentially stale state in the GUI (cache issues). So I decided to build a watcher.
There was a problem hiding this comment.
Yeah, it's nice for the VM to send this info on its own, so I agree this is a useful thing to have (given lack of passive alternatives).
This branch was successfully deployed
4 participants
add
busyattribute handling so a device that's in use (attached or used locally) stays visible in QubesDB with a busy=True marker instead of disappearing entirely, and propagates that marker up to the parent disk and the USB ancestor.xs_mark_busy,xs_mark_usb_busyset busy on the device and on the USB parent.usb_parent_still_in_usescans all sibling devices for either attachment or local use, to decide if the USB busy marker can be cleared.qubes.RefreshBlockDevicesre-triggers udev change events for it and its partitions after detach to force a state refresh from the one place that actually knows the truth (backend's sysfs + mount table), instead of guessing from cache.Open items: