Messages in this thread | | | Subject | RE: RE: [PATCH v32 4/4] scsi: ufs: Add HPB 2.0 support | From | Daejun Park <> | Date | Wed, 28 Apr 2021 09:37:09 +0900 |
| |
Hi Avri,
>> @@ -1653,6 +2148,7 @@ void ufshpb_destroy_lu(struct ufs_hba *hba, struct >> scsi_device *sdev) >> >> ufshpb_cancel_jobs(hpb); >> >> + ufshpb_pre_req_mempool_destroy(hpb); >> ufshpb_destroy_region_tbl(hpb); >> >> kmem_cache_destroy(hpb->map_req_cache); >> @@ -1692,6 +2188,7 @@ static void ufshpb_hpb_lu_prepared(struct ufs_hba >> *hba) >> ufshpb_set_state(hpb, HPB_PRESENT); >> if ((hpb->lu_pinned_end - hpb->lu_pinned_start) > 0) >> queue_work(ufshpb_wq, &hpb->map_work); >> + ufshpb_issue_umap_all_req(hpb); >> } else { >> dev_err(hba->dev, "destroy HPB lu %d\n", hpb->lun); >> ufshpb_destroy_lu(hba, sdev); >Here in lu_prepare, ufshpb_remove can be called without destroy_lu, >and while there are jobs running.
If init_success is false, ufshpb_destroy_lu and ufshpb_remove are called. If init_success is true, ufshpb_destroy_lu and ufshpb_remove are not called in this function.
So I think it is not problem.
Thanks, Daejun
>How about calling destroy_lu as part of ufshpb_remove? >Calling it again when __scsi_remove_device, hostdata is already null so it won't matter. > >Again, only after we know where all this is going to. > >Thanks, >Avri > > >
| |