Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [EXT] Re: [PATCH v2 1/5] scsi; ufs: add device descriptor for
 Host Performance Booster
To:     "Bean Huo (beanhuo)" <beanhuo@micron.com>,
        "huobean@gmail.com" <huobean@gmail.com>,
        "alim.akhtar@samsung.com" <alim.akhtar@samsung.com>,
        "avri.altman@wdc.com" <avri.altman@wdc.com>,
        "asutoshd@codeaurora.org" <asutoshd@codeaurora.org>,
        "jejb@linux.ibm.com" <jejb@linux.ibm.com>,
        "martin.petersen@oracle.com" <martin.petersen@oracle.com>,
        "stanley.chu@mediatek.com" <stanley.chu@mediatek.com>,
        "tomas.winkler@intel.com" <tomas.winkler@intel.com>,
        "cang@codeaurora.org" <cang@codeaurora.org>
Cc:     "linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
References: <20200416203126.1210-1-beanhuo@micron.com>
 <20200416203126.1210-2-beanhuo@micron.com>
 <6e092ac1-7e7d-3f12-8c81-b88369f1f621@acm.org>
 <BN7PR08MB568449A01D10F89B5C7F0E8BDBD30@BN7PR08MB5684.namprd08.prod.outlook.com>
From:   Bart Van Assche <bvanassche@acm.org>
Message-ID: <2625027d-8d98-3f30-93d4-dc1c39a434f1@acm.org>
Date:   Thu, 23 Apr 2020 10:57:17 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <BN7PR08MB568449A01D10F89B5C7F0E8BDBD30@BN7PR08MB5684.namprd08.prod.outlook.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 4/23/20 4:01 AM, Bean Huo (beanhuo) wrote:
> Thanks your review, I will take your suggestions in next version development.

Hi Bean,

Please make sure that the issues raised by Christoph are addressed 
before reposting this series.

Additionally, I think the following two call chains are deadlock-prone 
and should be addressed:

ufshcd_queuecommand()
-> ufshcd_comp_scsi_upiu()
   -> ufshpb_prep_fn()
     -> schedule_work(&hpb->ufshpb_req_work)
       -> ufshpb_req_workq_fn()
         -> ufshpb_subregion_activate()
           -> ufshpb_subregion_l2p_load()
             -> ufshpb_l2p_load_req()
               -> blk_execute_rq_nowait()

ufshcd_queuecommand()
-> ufshcd_comp_scsi_upiu()
   -> ufshpb_prep_fn()
     -> schedule_work(&hpb->ufshpb_req_work)
       -> ufshpb_req_workq_fn()
         -> ufshpb_subregion_activate()
         -> ufshpb_region_deactivate()
           -> ufshpb_execute_cmd()
             -> scsi_execute()

I don't know any other block or SCSI driver that calls blk_execute_rq*() 
or scsi_execute() from inside its .queue_rq() callback to queue requests 
onto the same request queue (the device mapper requeues requests onto a 
lower level request queue).

Thanks,

Bart.