linux-kernel - RE: [RFC PATCH v3] scsi: ufs: Quiesce all scsi devices before shutdown

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] [day] [month] [year] [list]

Message-ID: <SN6PR04MB46401CB0D89FFD24496B33A6FC720@SN6PR04MB4640.namprd04.prod.outlook.com>
Date:   Mon, 27 Jul 2020 10:46:49 +0000
From:   Avri Altman <Avri.Altman@....com>
To:     Stanley Chu <stanley.chu@...iatek.com>,
        Bart Van Assche <bvanassche@....org>
CC:     "linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
        "martin.petersen@...cle.com" <martin.petersen@...cle.com>,
        "alim.akhtar@...sung.com" <alim.akhtar@...sung.com>,
        "jejb@...ux.ibm.com" <jejb@...ux.ibm.com>,
        "beanhuo@...ron.com" <beanhuo@...ron.com>,
        "asutoshd@...eaurora.org" <asutoshd@...eaurora.org>,
        "cang@...eaurora.org" <cang@...eaurora.org>,
        "matthias.bgg@...il.com" <matthias.bgg@...il.com>,
        "linux-mediatek@...ts.infradead.org" 
        <linux-mediatek@...ts.infradead.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "kuohong.wang@...iatek.com" <kuohong.wang@...iatek.com>,
        "peter.wang@...iatek.com" <peter.wang@...iatek.com>,
        "chun-hung.wu@...iatek.com" <chun-hung.wu@...iatek.com>,
        "andy.teng@...iatek.com" <andy.teng@...iatek.com>,
        "chaotian.jing@...iatek.com" <chaotian.jing@...iatek.com>,
        "cc.chou@...iatek.com" <cc.chou@...iatek.com>
Subject: RE: [RFC PATCH v3] scsi: ufs: Quiesce all scsi devices before
 shutdown

> 
> Hi Bart,
> 
> On Sat, 2020-07-11 at 20:21 -0700, Bart Van Assche wrote:
> > On 2020-07-06 06:22, Stanley Chu wrote:
> > > +static void ufshcd_cleanup_queue(struct scsi_device *sdev, void *data)
> > > +{
> > > +   if (sdev->request_queue)
> > > +           blk_cleanup_queue(sdev->request_queue);
> > > +}
> >
> > No SCSI LLD should ever call blk_cleanup_queue() directly for
> > sdev->request_queue. Only the SCSI core should call blk_cleanup_queue()
> > directly for that queue.
> 
> Got it.
> 
> So may I focus on fixing racing first by quiecsing all SCSI devices only
> and do not touch blk_cleanup_queue() in UFS driver, just like v2?
> 
> 
> > >  int ufshcd_shutdown(struct ufs_hba *hba)
> > >  {
> > >     int ret = 0;
> > > +   struct scsi_target *starget;
> > >
> > >     if (!hba->is_powered)
> > >             goto out;
> > > @@ -8612,7 +8632,25 @@ int ufshcd_shutdown(struct ufs_hba *hba)
> > >                     goto out;
> > >     }
> > >
> > > +   /*
> > > +    * Quiesce all SCSI devices to prevent any non-PM requests sending
> > > +    * from block layer during and after shutdown.
> > > +    *
> > > +    * Here we can not use blk_cleanup_queue() since PM requests
> > > +    * (with BLK_MQ_REQ_PREEMPT flag) are still required to be sent
> > > +    * through block layer. Therefore SCSI command queued after the
> > > +    * scsi_target_quiesce() call returned will block until
> > > +    * blk_cleanup_queue() is called.
> > > +    *
> > > +    * Besides, scsi_target_"un"quiesce (e.g., scsi_target_resume) can
> > > +    * be ignored since shutdown is one-way flow.
> > > +    */
> > > +   ufshcd_scsi_for_each_sdev(ufshcd_quiece_sdev);
> > > +
> > >     ret = ufshcd_suspend(hba, UFS_SHUTDOWN_PM);
> > > +
> > > +   /* Set queue as dying to not block queueing commands */
> > > +   ufshcd_scsi_for_each_sdev(ufshcd_cleanup_queue);
> > >  out:
> > >     if (ret)
> > >             dev_err(hba->dev, "%s failed, err %d\n", __func__, ret);
> > >
> >
> > What is the purpose of ufshcd_shutdown()? Why does this function exist?
> > How about removing the calls to ufshcd_shutdown() and invoking power
> down
> > code from inside sd_suspend_common() instead?
> 
> ufshcd_shutdown() configures below things different from or more than
> what sd_suspend_common() can do now,
> 
> - Set link as OFF state
> - Regulator and clock toggling according to required low-power state for
> shutdown
> - Auto BKOP toggling
> - Vendor-specific shutdown flow ...etc.
> 
> Therefore UFS shutdown callback would be still required.
And this is also why, that each chipset vendor implement its own dev_pm_ops.

Thanks,
Avri

> 
> Thanks,
> Stanley Chu