Actions
Bug #12925
openRecursive mutex enter panic in virtio_fini()
Start date:
Due date:
% Done:
90%
Estimated time:
Difficulty:
Medium
Tags:
Gerrit CR:
External Bug:
Description
If a virtio device fails to attach and calls virtio_fini(vio, B_TRUE)
, the following sequence occurs:
void virtio_fini(virtio_t *vio, boolean_t failed) { mutex_enter(&vio->vio_mutex); ... if (failed) { /* * Signal to the host that device setup failed. */ virtio_set_status(vio, VIRTIO_STATUS_FAILED); } else { virtio_device_reset_locked(vio); } ... static void virtio_set_status(virtio_t *vio, uint8_t status) { VERIFY3U(status, !=, 0); mutex_enter(&vio->vio_mutex); uint8_t old = virtio_get8(vio, VIRTIO_LEGACY_DEVICE_STATUS); virtio_put8(vio, VIRTIO_LEGACY_DEVICE_STATUS, status | old); mutex_exit(&vio->vio_mutex); }
I'm not sure if we can just drop the mutex prior to the call to virtio_set_status() (and let it reacquire it), or if we just need to have a locked path when updating the status and hold the mutex.
Additionally, the d_errstats
are never cleaned up -- bd_detach
never gets called on attach failure, so the code to release the memory is never called.
Testing done: no panic from recursive mutex call with change applied.
Related issues
Updated by Dan McDonald over 3 years ago
- Related to Bug #12924: blkdev needs to be better at handling attach failures added
Updated by Toomas Soome 4 days ago
- Description updated (diff)
- Status changed from New to In Progress
- Assignee set to Toomas Soome
- % Done changed from 0 to 90
Actions