linux-kernel - Re: [PATCH v2] ath10k: skip the wait for completion to recovery in shutdown path

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: <CA+ASDXOvnfETrKs2ZbayZsRkUEpUbaeMGRkZNRCXa=M28HHE-w@mail.gmail.com>
Date:   Tue, 1 Dec 2020 11:35:44 -0800
From:   Brian Norris <briannorris@...omium.org>
To:     Youghandhar Chintala <youghand@...eaurora.org>
Cc:     ath10k <ath10k@...ts.infradead.org>,
        linux-wireless <linux-wireless@...r.kernel.org>,
        Linux Kernel <linux-kernel@...r.kernel.org>,
        Rakesh Pillai <pillair@...eaurora.org>,
        Doug Anderson <dianders@...omium.org>, kuabhs@...omium.org
Subject: Re: [PATCH v2] ath10k: skip the wait for completion to recovery in
 shutdown path

On Thu, Nov 26, 2020 at 9:16 AM Youghandhar Chintala
<youghand@...eaurora.org> wrote:
> --- a/drivers/net/wireless/ath/ath10k/snoc.c
> +++ b/drivers/net/wireless/ath/ath10k/snoc.c
> @@ -1790,9 +1790,6 @@ static int ath10k_snoc_remove(struct platform_device *pdev)
>
>         reinit_completion(&ar->driver_recovery);
>
> -       if (test_bit(ATH10K_SNOC_FLAG_RECOVERY, &ar_snoc->flags))
> -               wait_for_completion_timeout(&ar->driver_recovery, 3 * HZ);

Hmm, this is the only instance of waiting for this completion, which
means that after this patch, 'ar->driver_recovery' is doing exactly
nothing. Should you instead just remove it completely?

Also, if your patch is correct, it seems like the completion was never
needed in the first place. You should probably address such a claim in
the commit message; is there truly no need to wait here? Or was there
some purpose here, but that purpose was accomplished some other way?
Or was there a purpose, and that purpose was misguided? It feels to me
like it is indeed correct to remove this (shutdown should be performed
promptly; we don't need to delay it just to try to "finish
recovering"), but it's your job to convince the reader.

Brian

> -
>         set_bit(ATH10K_SNOC_FLAG_UNREGISTERING, &ar_snoc->flags);
>
>         ath10k_core_unregister(ar);