netdev - Re: long delays in rtl8723 drivers in irq disabled sections

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: <e83f5b699c5652cbe2350ac3576215d24b748e03.camel@lynxeye.de>
Date:   Wed, 13 Nov 2019 23:11:10 +0100
From:   Lucas Stach <dev@...xeye.de>
To:     Pkshih <pkshih@...ltek.com>, wlanfae <wlanfae@...ltek.com>
Cc:     "linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: long delays in rtl8723 drivers in irq disabled sections

Hi PK,

Am Mittwoch, den 13.11.2019, 03:43 +0000 schrieb Pkshih:
> > -----Original Message-----
> > From: linux-wireless-owner@...r.kernel.org [mailto:linux-wireless-owner@...r.kernel.org] On Behalf
> > Of Lucas Stach
> > Sent: Wednesday, November 13, 2019 5:02 AM
> > To: wlanfae; Pkshih
> > Cc: linux-wireless@...r.kernel.org; netdev@...r.kernel.org
> > Subject: long delays in rtl8723 drivers in irq disabled sections
> > 
> > Hi all,
> > 
> > while investigating some latency issues on my laptop I stumbled across
> > quite large delays in the rtl8723 PHY code, which are done in IRQ
> > disabled atomic sections, which is blocking IRQ servicing for all
> > devices in the system.
> > 
> > Specifically there are 3 consecutive 1ms delays in
> > rtl8723_phy_rf_serial_read(), which is used in an IRQ disabled call
> > path. Sadly those delays don't have any comment in the code explaining
> > why they are needed. I hope that anyone can tell if those delays are
> > strictly neccessary and if so if they really need to be this long.
> > 
> 
> These delays are because read RF register is an indirect access that hardware
> needs time to accomplish read action, but there's no ready bit, so delay
> is required to guarantee the read value is correct. 

Thanks for the confirmation, I suspected something like this.

> It is possible to use smaller delay, but it's exactly required.

1ms seems like an eternity on modern hardware, even for an indirect
read.

> 
> An alternative way is to prevent calling this function in IRQ disabled flow.
> Could you share the calling trace?

Sure, trimmed callstack below. As you can see the IRQ disabled section
is started via a spin_lock_irqsave(). The trace is from a 8723de
module, which is still out of tree, but the same code is present in
mainline and used by the other 8723 variants.
I don't know if this function needs to guard against something running
in the IRQ handler, so depending on the answer to that the solution
might be as simple as not disabling IRQs when taking the spinlock.

kworker/-276     4d...    0us : _raw_spin_lock_irqsave
kworker/-276     4d...    0us : rtl8723_phy_rf_serial_read <-rtl8723de_phy_set_rf_reg
kworker/-276     4d...    1us : rtl8723_phy_query_bb_reg <-rtl8723_phy_rf_serial_read
kworker/-276     4d...    3us : rtl8723_phy_set_bb_reg <-rtl8723_phy_rf_serial_read
kworker/-276     4d...    4us : __const_udelay <-rtl8723_phy_rf_serial_read
kworker/-276     4d...    4us!: delay_mwaitx <-rtl8723_phy_rf_serial_read
kworker/-276     4d... 1004us : rtl8723_phy_set_bb_reg <-rtl8723_phy_rf_serial_read
[...]

Regards,
Lucas