RE: RE: [PATCH v11 08/12] scsi: ufshpb: Add "Cold" regions timer

[Daejun Park]

Hi Avri,

> > Hi Avri,
> > 
> > >diff --git a/drivers/scsi/ufs/ufshpb.c b/drivers/scsi/ufs/ufshpb.c
> > >index 39b86e8b2eee..cf719831adb3 100644
> > >--- a/drivers/scsi/ufs/ufshpb.c
> > >+++ b/drivers/scsi/ufs/ufshpb.c
> > 
> > ...
> > 
> > >+static void ufshpb_read_to_handler(struct work_struct *work)
> > >+{
> > >+        struct ufshpb_lu *hpb = container_of(work, struct ufshpb_lu,
> > >+                                             ufshpb_read_to_work.work);
> > >+        struct victim_select_info *lru_info = &hpb->lru_info;
> > >+        struct ufshpb_region *rgn, *next_rgn;
> > >+        unsigned long flags;
> > >+        LIST_HEAD(expired_list);
> > >+
> > >+        if (test_and_set_bit(TIMEOUT_WORK_RUNNING, &hpb-
> > >work_data_bits))
> > >+                return;
> > >+
> > >+        spin_lock_irqsave(&hpb->rgn_state_lock, flags);
> > >+
> > >+        list_for_each_entry_safe(rgn, next_rgn, &lru_info->lh_lru_rgn,
> > >+                                 list_lru_rgn) {
> > >+                bool timedout = ktime_after(ktime_get(), rgn->read_timeout);
> > >+
> > >+                if (timedout) {
> > >+                        rgn->read_timeout_expiries--;
> > >+                        if (is_rgn_dirty(rgn) ||
> > >+                            rgn->read_timeout_expiries == 0)
> > >+                                list_add(&rgn->list_expired_rgn, &expired_list);
> > 
> > Why we need additional expired_list for updating inactive information?
> Since the lru list is accessed under rgn_state_lock, 
> and inactivation is done under rsp_list_lock,
> It's just a convenient way to list all the expired  regions.
OK,

>  
> > And I think "rgn->list_lru_rgn" should be deleted when it is expired.
> Oh - I don't think so.
> This should be done in one place only, which is cleanup_lru_info,
> Which is called, in host mode, after a successful unmap request.

Then I think list_for_each_entry_safe can be changed to list_for_each_entry,
because there is no deletion of the list. But it doesn't look like it needs
a fix right now.

Thanks,
Daejun