Project

General

Profile

Bug #12925

Recursive mutex enter panic in virtio_fini()

Added by Jason King about 1 month ago. Updated about 1 month ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
driver - device drivers
Start date:
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:
Gerrit CR:

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.


Related issues

Related to illumos gate - Bug #12924: blkdev needs to be better at handling attach failuresClosed

Actions

History

#1

Updated by Jason King about 1 month ago

  • Description updated (diff)
#2

Updated by Dan McDonald about 1 month ago

  • Related to Bug #12924: blkdev needs to be better at handling attach failures added

Also available in: Atom PDF