lkml.org 
[lkml]   [2021]   [Apr]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [PATCH v32 4/4] scsi: ufs: Add HPB 2.0 support
Date
> @@ -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.
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
\
 
 \ /
  Last update: 2021-04-21 16:16    [W:0.112 / U:0.156 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site