linux-kernel - Re: [1/2] carl9170: Fix wrong completion usage

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] [day] [month] [year] [list]

Date:   Fri, 9 Sep 2016 14:16:17 +0200
From:   Kalle Valo <kvalo@....qualcomm.com>
To:     Daniel Wagner <wagi@...om.org>
CC:     Kalle Valo <kvalo@...eaurora.org>,
        Christian Lamparter <chunkeey@...glemail.com>,
        "Luis R . Rodriguez" <mcgrof@...nel.org>,
        <ath10k@...ts.infradead.org>, <linux-wireless@...r.kernel.org>,
        <netdev@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        Daniel Wagner <daniel.wagner@...-carit.de>
Subject: Re: [1/2] carl9170: Fix wrong completion usage

Daniel Wagner <wagi@...om.org> wrote:
> From: Daniel Wagner <daniel.wagner@...-carit.de>
> 
> carl9170_usb_stop() is used from several places to flush and cleanup any
> pending work. The normal pattern is to send a request and wait for the
> irq handler to call complete(). The completion is not reinitialized
> during normal operation and as the old comment indicates it is important
> to keep calls to wait_for_completion_timeout() and complete() balanced.
> 
> Calling complete_all() brings this equilibirum out of balance and needs
> to be fixed by a reinit_completion(). But that opens a small race
> window. It is possible that the sequence of complete_all(),
> reinit_completion() is faster than the wait_for_completion_timeout() can
> do its work. The wake up is not lost but the done counter test is after
> reinit_completion() has been executed. The only reason we don't see
> carl9170_exec_cmd() hang forever is we use the timeout version of
> wait_for_copletion().
> 
> Let's fix this by reinitializing the completion (that is just setting
> done counter to 0) just before we send out an request. Now,
> carl9170_usb_stop() can be sure a complete() call is enough to make
> progess since there is only one waiter at max. This is a common pattern
> also seen in various drivers which use completion.
> 
> Signed-off-by: Daniel Wagner <daniel.wagner@...-carit.de>

Thanks, 1 patch applied to ath-next branch of ath.git:

78a9e170388b carl9170: Fix wrong completion usage

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9287819/