• Vivek Goyal's avatar
    block: Initialize ->queue_lock to internal lock at queue allocation time · c94a96ac
    Vivek Goyal authored
    There does not seem to be a clear convention whether q->queue_lock is
    initialized or not when blk_cleanup_queue() is called. In the past it
    was not necessary but now blk_throtl_exit() takes up queue lock by
    default and needs queue lock to be available.
    
    In fact elevator_exit() code also has similar requirement just that it
    is less stringent in the sense that elevator_exit() is called only if
    elevator is initialized.
    
    Two problems have been noticed because of ambiguity about spin lock
    status.
    
          - If a driver calls blk_alloc_queue() and then soon calls
            blk_cleanup_queue() almost immediately, (because some other
    	driver structure allocation failed or some other error happened)
    	then blk_throtl_exit() will run into issues as queue lock is not
    	initialized. Loop driver ran into this issue recently and I
    	noticed error paths in md driver too. Similar error paths should
    	exist in other drivers too.
    
          - If some driver provided external spin lock and zapped the lock
            before blk_cleanup_queue(), then it can lead to issues.
    
    So this patch initializes the default queue lock at queue allocation time.
    
    block throttling code is one of the users of queue lock and it is
    initialized at the queue allocation time, so it makes sense to
    initialize ->queue_lock also to internal lock. A driver can overide that
    lock later. This will take care of the issue where a driver does not have
    to worry about initializing the queue lock to default before calling
    blk_cleanup_queue()
    Signed-off-by: default avatarVivek Goyal <vgoyal@redhat.com>
    Signed-off-by: default avatarJens Axboe <jaxboe@fusionio.com>
    c94a96ac
blk-settings.c 25.4 KB