linux-kernel - Re: [PATCH 1/2] usb: dwc3: core: Call cpu_relax() in registers polling busy loops

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: <20240820220536.lgxvvbfboheknyll@synopsys.com>
Date: Tue, 20 Aug 2024 22:05:41 +0000
From: Thinh Nguyen <Thinh.Nguyen@...opsys.com>
To: Zhongqiu Han <quic_zhonhan@...cinc.com>
CC: Thinh Nguyen <Thinh.Nguyen@...opsys.com>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "mathias.nyman@...el.com" <mathias.nyman@...el.com>,
        "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/2] usb: dwc3: core: Call cpu_relax() in registers
 polling busy loops

On Tue, Aug 20, 2024, Zhongqiu Han wrote:
> Busy loops that poll on a register should call cpu_relax(). On some
> architectures, it can lower CPU power consumption or yield to a
> hyperthreaded twin processor. It also serves as a compiler barrier,
> see Documentation/process/volatile-considered-harmful.rst. In addition,
> if something goes wrong in the busy loop at least it can prevent things
> from getting worse.
> 
> Signed-off-by: Zhongqiu Han <quic_zhonhan@...cinc.com>
> ---
>  drivers/usb/dwc3/core.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
> index 734de2a8bd21..498f08dbbdb5 100644
> --- a/drivers/usb/dwc3/core.c
> +++ b/drivers/usb/dwc3/core.c
> @@ -2050,6 +2050,8 @@ static int dwc3_get_num_ports(struct dwc3 *dwc)
>  		if (!offset)
>  			break;
>  
> +		cpu_relax();
> +
>  		val = readl(base + offset);
>  		major_revision = XHCI_EXT_PORT_MAJOR(val);
>  
> -- 
> 2.25.1
> 

We're not polling on a register here. We're just traversing and reading
the next port capability. The loop in dwc3_get_num_ports() should not be
more than DWC3_USB2_MAX_PORTS + DWC3_USB3_MAX_PORTS.

What's really causing this busy loop you found?

If polling for a register is really a problem, then we would have that
problem everywhere else in dwc3. But why here?

Thanks,
Thinh