linux-kernel - Re: [PATCH] Bluetooth: use wait_event API instead of open-coding it

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:   Mon, 23 Apr 2018 19:58:41 +0200
From:   Marcel Holtmann <marcel@...tmann.org>
To:     John Keeping <john@...anate.com>
Cc:     BlueZ development <linux-bluetooth@...r.kernel.org>,
        ML netdev <netdev@...r.kernel.org>,
        linux-kernel@...r.kernel.org,
        Johan Hedberg <johan.hedberg@...il.com>
Subject: Re: [PATCH] Bluetooth: use wait_event API instead of open-coding it

Hi John,

> I've seen timeout errors from HCI commands where it looks like
> schedule_timeout() has returned immediately; additional logging for the
> error case gives:
> 
> 	req_status=1 req_result=0 remaining=10000 jiffies
> 
> so the device is still in state HCI_REQ_PEND and the value returned by
> schedule_timeout() is the same as the original timeout (HCI_INIT_TIMEOUT
> on a system with HZ=1000).
> 
> Use wait_event_interruptible_timeout() instead of open-coding similar
> behaviour which is subject to the spurious failure described above.
> 
> Signed-off-by: John Keeping <john@...anate.com>
> ---
> I saw problems with the -rt patchset on 4.9 and I'm not convinced that
> it's Bluetooth at fault for the problem described above, but I think
> this is a nice cleanup even if it's not a bug fix.
> 
> net/bluetooth/hci_request.c | 30 +++++++-----------------------
> 1 file changed, 7 insertions(+), 23 deletions(-)

patch has been applied to bluetooth-next tree.

Regards

Marcel