• Dexuan Cui's avatar
    scsi: storvsc: Fix a race in sub-channel creation that can cause panic · c9675904
    Dexuan Cui authored
    We can concurrently try to open the same sub-channel from 2 paths:
    
    path #1: vmbus_onoffer() -> vmbus_process_offer() -> handle_sc_creation().
    path #2: storvsc_probe() -> storvsc_connect_to_vsp() ->
    	 -> storvsc_channel_init() -> handle_multichannel_storage() ->
    	 -> vmbus_are_subchannels_present() -> handle_sc_creation().
    
    They conflict with each other, but it was not an issue before the recent
    commit ae6935ed ("vmbus: split ring buffer allocation from open"),
    because at the beginning of vmbus_open() we checked newchannel->state so
    only one path could succeed, and the other would return with -EINVAL.
    
    After ae6935ed, the failing path frees the channel's ringbuffer by
    vmbus_free_ring(), and this causes a panic later.
    
    Commit ae6935ed itself is good, and it just reveals the longstanding
    race. We can resolve the issue by removing path #2, i.e. removing the
    second vmbus_are_subchannels_present() in handle_multichannel_storage().
    
    BTW, the comment "Check to see if sub-channels have already been created"
    in handle_multichannel_storage() is incorrect: when we unload the driver,
    we first close the sub-channel(s) and then close the primary channel, next
    the host sends rescind-offer message(s) so primary->sc_list will become
    empty. This means the first vmbus_are_subchannels_present() in
    handle_multichannel_storage() is never useful.
    
    Fixes: ae6935ed ("vmbus: split ring buffer allocation from open")
    Cc: stable@vger.kernel.org
    Cc: Long Li <longli@microsoft.com>
    Cc: Stephen Hemminger <sthemmin@microsoft.com>
    Cc: K. Y. Srinivasan <kys@microsoft.com>
    Cc: Haiyang Zhang <haiyangz@microsoft.com>
    Signed-off-by: default avatarDexuan Cui <decui@microsoft.com>
    Signed-off-by: default avatarK. Y. Srinivasan <kys@microsoft.com>
    Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
    c9675904
storvsc_drv.c 51.1 KB