netdev - Re: [PATCH] rtl8xxxu: disable interrupt_in transfer for 8188cu and 8192cu

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: <CABTNMG2_Cb7RhguJZNKZxAna6oBaDPhomBWRreO-adFX2Erwkw@mail.gmail.com>
Date:   Mon, 5 Jul 2021 17:00:10 +0800
From:   Chris Chiu <chris.chiu@...onical.com>
To:     Kalle Valo <kvalo@...eaurora.org>
Cc:     Jes.Sorensen@...il.com, davem@...emloft.net, kuba@...nel.org,
        code@...o-schneider.ch, linux-wireless@...r.kernel.org,
        netdev@...r.kernel.org, Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] rtl8xxxu: disable interrupt_in transfer for 8188cu and 8192cu

On Fri, Jul 2, 2021 at 4:42 PM Kalle Valo <kvalo@...eaurora.org> wrote:
>
> chris.chiu@...onical.com writes:
>
> > From: Chris Chiu <chris.chiu@...onical.com>
> >
> > There will be crazy numbers of interrupts triggered by 8188cu and
> > 8192cu module, around 8000~10000 interrupts per second, on the usb
> > host controller. Compare with the vendor driver source code, it's
> > mapping to the configuration CONFIG_USB_INTERRUPT_IN_PIPE and it is
> > disabled by default.
> >
> > Since the interrupt transfer is neither used for TX/RX nor H2C
> > commands. Disable it to avoid the confusing interrupts for the
> > 8188cu and 8192cu module which I only have for verification.
>
> The last paragraph is not entirely clear for me, can you elaborate it
> more? What do you mean with "confusing interrupts"? And is this fixing
> an actual user visible bug or are you just reducing the number of
> interrupts?
>
It's confusing because there are 8000~9000 interrupts per second even
though the association is not done yet and no traffic is pumped. It's
also way too many even the reception of the beacon frames triggers the
interrupt. This huge number overwhelms the normal interrupt we
expected from the register setting (only < 100/sec if runs with
rtlwif/rtl8192cu driver instead). It's difficult to judge where/why
the interrupts come from and what possible overhead it could possibly
incur.

> --
> https://patchwork.kernel.org/project/linux-wireless/list/
>
> https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches