linux-kernel - Re: [RFC PATCH v3 1/1] scsi: ufs: Enable power management for wlun

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20210216173646.GA35819@stor-presley.qualcomm.com>
Date:   Tue, 16 Feb 2021 09:36:46 -0800
From:   Asutosh Das <asutoshd@...eaurora.org>
To:     Avri Altman <Avri.Altman@....com>
Cc:     "cang@...eaurora.org" <cang@...eaurora.org>,
        "martin.petersen@...cle.com" <martin.petersen@...cle.com>,
        "linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
        "linux-arm-msm@...r.kernel.org" <linux-arm-msm@...r.kernel.org>,
        "stern@...land.harvard.edu" <stern@...land.harvard.edu>,
        Alim Akhtar <alim.akhtar@...sung.com>,
        "James E.J. Bottomley" <jejb@...ux.ibm.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Ingo Molnar <mingo@...hat.com>,
        Stanley Chu <stanley.chu@...iatek.com>,
        Bean Huo <beanhuo@...ron.com>,
        Jaegeuk Kim <jaegeuk@...nel.org>,
        Kiwoong Kim <kwmad.kim@...sung.com>,
        Adrian Hunter <adrian.hunter@...el.com>,
        Satya Tangirala <satyat@...gle.com>,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH v3 1/1] scsi: ufs: Enable power management for wlun

On Sat, Feb 13 2021 at 13:37 -0800, Avri Altman wrote:
>> +       } else {
>Is it possible to get here?
>Scsi_scan_host is called only after successful add_wluns

It looks so.
scsi 0:0:0:49488: Link setup for lun - ufshcd_setup_links
[...]
Call trace:
dump_backtrace+0x0/0x1d4
show_stack+0x18/0x24
dump_stack+0xc4/0x144
ufshcd_setup_links+0xd8/0x100
ufshcd_slave_alloc+0x134/0x1a0
scsi_alloc_sdev+0x1c0/0x230
scsi_probe_and_add_lun+0xc0/0xd48
__scsi_add_device+0xc0/0x138
ufshcd_scsi_add_wlus+0x30/0x1c0
ufshcd_async_scan+0x58/0x240
async_run_entry_fn+0x48/0x128
process_one_work+0x1f0/0x470
worker_thread+0x26c/0x4c8
kthread+0x13c/0x320
ret_from_fork+0x10/0x18

>
>> +               /* device wlun is probed */
>> +               hba->luns_avail--;
>> +       }
>> +}
>> +
>
>
>>
>>  /**
>> @@ -7254,6 +7312,14 @@ static int ufshcd_scsi_add_wlus(struct ufs_hba
>> *hba)
>>                 goto out;
>>         }
>>         ufshcd_blk_pm_runtime_init(hba->sdev_ufs_device);
>> +       /*
>> +        * A pm_runtime_put_sync is invoked when this device enables
>> blk_pm_runtime
>> +        * & would suspend the device-wlun upon timer expiry.
>> +        * But suspending device wlun _may_ put the ufs device in the pre-defined
>> +        * low power mode (SSU <rpm_lvl>). Probing of other luns may fail then.
>> +        * Don't allow this suspend until all the luns have been probed.
>Maybe add one more sentence: see pm_runtime_mark_last_busy in ufshcd_setup_links
Done.

>
>
>
>> -       ufshcd_clear_ua_wluns(hba);
>Are there any callers left to ufshcd_clear_ua_wluns?
>Can it be removed?
Let me check.

>
>> +       if (hba->wlun_dev_clr_ua)
>> +               ufshcd_clear_ua_wlun(hba, UFS_UPIU_UFS_DEVICE_WLUN);
>>
>>         cmd[4] = pwr_mode << 4;