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: <eacd917270291bd835a1d5594e30800a2058d4c6.camel@gmail.com>
Date:   Sun, 08 Nov 2020 21:19:00 +0900
From:   Tsuchiya Yuto <kitakar@...il.com>
To:     Kalle Valo <kvalo@...eaurora.org>
Cc:     Amitkumar Karwar <amitkarwar@...il.com>,
        Ganapathi Bhat <ganapathi.bhat@....com>,
        Xinming Hu <huxinming820@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        linux-wireless@...r.kernel.org, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Maximilian Luz <luzmaximilian@...il.com>,
        Andy Shevchenko <andriy.shevchenko@...el.com>, verdre@...d.nl
Subject: Re: [PATCH 1/2] mwifiex: fix mwifiex_shutdown_sw() causing sw reset
 failure

On Sun, 2020-11-08 at 13:31 +0200, Kalle Valo wrote:
> Tsuchiya Yuto <kitakar@...il.com> writes:
> 
> > When FLR is performed but without fw reset for some reasons (e.g. on
> > Surface devices, fw reset requires another quirk), it fails to reset
> > properly. You can trigger the issue on such devices via debugfs entry
> > for reset:
> > 
> >     $ echo 1 | sudo tee /sys/kernel/debug/mwifiex/mlan0/reset
> > 
> > and the resulting dmesg log:
> > 
> >     [   45.740508] mwifiex_pcie 0000:03:00.0: Resetting per request
> >     [   45.742937] mwifiex_pcie 0000:03:00.0: info: successfully disconnected from [BSSID]: reason code 3
> >     [   45.744666] mwifiex_pcie 0000:03:00.0: info: shutdown mwifiex...
> >     [   45.751530] mwifiex_pcie 0000:03:00.0: PREP_CMD: card is removed
> >     [   45.751539] mwifiex_pcie 0000:03:00.0: PREP_CMD: card is removed
> >     [   45.771691] mwifiex_pcie 0000:03:00.0: PREP_CMD: card is removed
> >     [   45.771695] mwifiex_pcie 0000:03:00.0: deleting the crypto keys
> >     [   45.771697] mwifiex_pcie 0000:03:00.0: PREP_CMD: card is removed
> >     [   45.771698] mwifiex_pcie 0000:03:00.0: deleting the crypto keys
> >     [   45.771699] mwifiex_pcie 0000:03:00.0: PREP_CMD: card is removed
> >     [   45.771701] mwifiex_pcie 0000:03:00.0: deleting the crypto keys
> >     [   45.771702] mwifiex_pcie 0000:03:00.0: PREP_CMD: card is removed
> >     [   45.771703] mwifiex_pcie 0000:03:00.0: deleting the crypto keys
> >     [   45.771704] mwifiex_pcie 0000:03:00.0: PREP_CMD: card is removed
> >     [   45.771705] mwifiex_pcie 0000:03:00.0: deleting the crypto keys
> >     [   45.771707] mwifiex_pcie 0000:03:00.0: PREP_CMD: card is removed
> >     [   45.771708] mwifiex_pcie 0000:03:00.0: deleting the crypto keys
> >     [   53.099343] mwifiex_pcie 0000:03:00.0: info: trying to associate to '[SSID]' bssid [BSSID]
> >     [   53.241870] mwifiex_pcie 0000:03:00.0: info: associated to bssid [BSSID] successfully
> >     [   75.377942] mwifiex_pcie 0000:03:00.0: cmd_wait_q terminated: -110
> >     [   85.385491] mwifiex_pcie 0000:03:00.0: info: successfully disconnected from [BSSID]: reason code 15
> >     [   87.539408] mwifiex_pcie 0000:03:00.0: cmd_wait_q terminated: -110
> >     [   87.539412] mwifiex_pcie 0000:03:00.0: deleting the crypto keys
> >     [   99.699917] mwifiex_pcie 0000:03:00.0: cmd_wait_q terminated: -110
> >     [   99.699925] mwifiex_pcie 0000:03:00.0: deleting the crypto keys
> >     [  111.859802] mwifiex_pcie 0000:03:00.0: cmd_wait_q terminated: -110
> >     [  111.859808] mwifiex_pcie 0000:03:00.0: deleting the crypto keys
> >     [...]
> > 
> > When comparing mwifiex_shutdown_sw() with mwifiex_pcie_remove(), it
> > lacks mwifiex_init_shutdown_fw().
> > 
> > This commit fixes mwifiex_shutdown_sw() by adding the missing
> > mwifiex_init_shutdown_fw().
> > 
> > Fixes: 4c5dae59d2e9 ("mwifiex: add PCIe function level reset support")
> > Signed-off-by: Tsuchiya Yuto <kitakar@...il.com>
> 
> Otherwise looks good to me, but what is FLR? I can add the description
> to the commit log if you tell me what it is.
> 

Thanks! It's a PCIe Function Level Reset (FLR). In addition to this,
it may be better to add a vendor name (Microsoft) of the devices where
we observed this issue?
(The other patch I sent also lacks the vendor name [1])

Based on the two improvements, I think the commit log should look like
this (also fixed some grammatical errors):

    When a PCIe function level reset (FLR) is performed but without fw reset
    for some reasons (e.g., on Microsoft Surface devices, fw reset requires
    other quirks), it fails to reset wifi properly. You can trigger the issue
    on such devices via debugfs entry for reset:
    [...]

I'd appreciate it if you could add the above changes (and/or your changes
if required). I can also resend this series if this is more preferable.

[1] [PATCH] mwifiex: pcie: skip cancel_work_sync() on reset failure path
    https://lore.kernel.org/linux-wireless/20201028142346.18355-1-kitakar@gmail.com/


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ