linux-kernel - Re: [PATCH v3] usb: ohci: add check for host controller functional states

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: <7a505fc4-ec47-ac83-633f-7a5251bd5f82@loongson.cn>
Date:   Sat, 9 Oct 2021 10:01:25 +0800
From:   zhuyinbo <zhuyinbo@...ngson.cn>
To:     Alan Stern <stern@...land.harvard.edu>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
        Greg Kroah-Hartman <greg@...ah.com>,
        Patchwork Bot <patchwork-bot@...nel.org>
Subject: Re: [PATCH v3] usb: ohci: add check for host controller functional
 states


在 2021/10/8 下午10:26, Alan Stern 写道:
> On Fri, Oct 08, 2021 at 03:26:10PM +0800, Yinbo Zhu wrote:
>> The usb states of ohci controller include UsbOperational, UsbReset,
>> UsbSuspend and UsbResume. Among them, only the UsbOperational state
>> supports launching the start of frame for host controller according
>> the ohci protocol spec, but in S3/S4 press test procedure, it may
> Nobody reading this will know what "S3/S4 press test procedure" means.
> You have to explain it, or use a different name that people will
> understand.
okay, I got it.
>> happen that the start of frame was launched in other usb states and
>> cause ohci works abnormally then kernel will allways report rcu
>> call trace. This patch was to add check for host controller
>> functional states and if it is not UsbOperational state that need
>> set INTR_SF in intrdisable register to ensure SOF Token generation
>> was been disabled.
> This doesn't make sense.  You already mentioned that only the
> UsbOperational state supports sending start-of-frame packets.  So if the
> controller is in a different state then it won't send these packets,
> whether INTR_SF is enabled or not.
>
> What problem are you really trying to solve?

Only UsbOperational state supports sending start-of-frame packets, but 
in fact, in S3/S4 press test procedure,

usb in non-UsbOperational state that send start-of-frame packets but hc 
driver doesn't deal with this frame. and hc will

allways lauched the SOF for finishing the frame, the cpu will hand this 
sof interrupt and doesn't deal with time interrupt

that will cause rcu call trace then system doesn't suspend to memory/disk.

>> Signed-off-by: Yinbo Zhu <zhuyinbo@...ngson.cn>
>> ---
>> Change in v3:
>> 		Rework the commit information.
>> 		Move the patch code change to lower down position in ohci_irq.
>>
>>
>>   drivers/usb/host/ohci-hcd.c | 13 ++++++++++---
>>   1 file changed, 10 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
>> index 1f5e693..87aa9bb 100644
>> --- a/drivers/usb/host/ohci-hcd.c
>> +++ b/drivers/usb/host/ohci-hcd.c
>> @@ -879,7 +879,8 @@ static irqreturn_t ohci_irq (struct usb_hcd *hcd)
>>   {
>>   	struct ohci_hcd		*ohci = hcd_to_ohci (hcd);
>>   	struct ohci_regs __iomem *regs = ohci->regs;
>> -	int			ints;
>> +	int			ints, ctl;
>> +
> Extra blank line not needed.
>
>>   
>>   	/* Read interrupt status (and flush pending writes).  We ignore the
>>   	 * optimization of checking the LSB of hcca->done_head; it doesn't
>> @@ -969,9 +970,15 @@ static irqreturn_t ohci_irq (struct usb_hcd *hcd)
>>   	 * when there's still unlinking to be done (next frame).
>>   	 */
>>   	ohci_work(ohci);
>> -	if ((ints & OHCI_INTR_SF) != 0 && !ohci->ed_rm_list
>> -			&& ohci->rh_state == OHCI_RH_RUNNING)
>> +
>> +	ctl = ohci_readl(ohci, &regs->control);
>> +
> Blank lines not needed.
>
>> +	if (((ints & OHCI_INTR_SF) != 0 && !ohci->ed_rm_list
>> +			&& ohci->rh_state == OHCI_RH_RUNNING) ||
>> +			((ctl & OHCI_CTRL_HCFS) != OHCI_USB_OPER)) {
>>   		ohci_writel (ohci, OHCI_INTR_SF, &regs->intrdisable);
>> +		(void)ohci_readl(ohci, &regs->intrdisable);
>> +	}
> This is definitely wrong.  You must not turn off SF interrupts when
> ed_rm_list is non-NULL.  If you do, the driver will not be able to
> finish unlinking URBs.
>
> Alan Stern

Hi Alan Stern,

     even though ed_rm_list is non-NULL, if hc in non-UsbOperation state 
set SoF status in usbsts register that is illegal,

at this time hcd doesn't need care URB whether finished,  because hc had 
into a wrong state. even thoug it doesn't has this patch,

URB was not be able to finish when hc in above worng state. except 
software can intervence this wrong state. but the SoF bit of usbsts

register was set by HC, and this action will happen always !!! software 
clear SoF state I think it isn't make sense. software only disable SoF

interrupt to fix HC wrong state.

       In additon, when kernel include my patch, that it does't happen 
about what you descriped that driver will not be able to finish 
unlinging URBs.

Because above issue happen in S3/S4(Suspend to disk/Suspend to mem) test 
procedure, if ed_rm_lis is no-NULL but my patch disable SoF interrupt.

then when S3/S4 recovery to cpu idle state that usb resume will be 
called, reume function has following logic, URB will continue to be 
processed.

       static int ohci_rh_resume (struct ohci_hcd *ohci)

      {

         ...

         242         if (ohci->ed_rm_list)
         243                 ohci_writel (ohci, OHCI_INTR_SF, 
&ohci->regs->intrenable);

        ...

       }

BRS,

Yinbo Zhu.