From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from userp1040.oracle.com ([156.151.31.81]:19040 "EHLO userp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751693AbdF1BJ6 (ORCPT ); Tue, 27 Jun 2017 21:09:58 -0400 To: "Ewan D. Milne" Cc: linux-scsi@vger.kernel.org, stable@vger.kernel.org Subject: Re: [PATCH RESEND] scsi: Add STARGET_CREATED_REMOVE state to scsi_target_state From: "Martin K. Petersen" References: <1498589758-31473-1-git-send-email-emilne@redhat.com> Date: Tue, 27 Jun 2017 21:09:52 -0400 In-Reply-To: <1498589758-31473-1-git-send-email-emilne@redhat.com> (Ewan D. Milne's message of "Tue, 27 Jun 2017 14:55:58 -0400") Message-ID: MIME-Version: 1.0 Content-Type: text/plain Sender: stable-owner@vger.kernel.org List-ID: Ewan, > The addition of the STARGET_REMOVE state had the side effect of > introducing a race condition that can cause a crash. > > scsi_target_reap_ref_release() checks the starget->state to > see if it still in STARGET_CREATED, and if so, skips calling > transport_remove_device() and device_del(), because the starget->state > is only set to STARGET_RUNNING after scsi_target_add() has called > device_add() and transport_add_device(). > > However, if an rport loss occurs while a target is being scanned, > it can happen that scsi_remove_target() will be called while the > starget is still in the STARGET_CREATED state. In this case, the > starget->state will be set to STARGET_REMOVE, and as a result, > scsi_target_reap_ref_release() will take the wrong path. The end > result is a panic: Johannes/Bart/James: Please review! -- Martin K. Petersen Oracle Linux Engineering