NetBSD Problem Report #53739

From www@NetBSD.org  Sun Nov 25 00:21:35 2018
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 361747A158
	for <gnats-bugs@gnats.NetBSD.org>; Sun, 25 Nov 2018 00:21:35 +0000 (UTC)
Message-Id: <20181125002126.9AD8A7A1EF@mollari.NetBSD.org>
Date: Sun, 25 Nov 2018 00:21:26 +0000 (UTC)
From: bbraun@synack.net
Reply-To: bbraun@synack.net
To: gnats-bugs@NetBSD.org
Subject: usbhidctl blocks forever if usbhidaction is running on the same device
X-Send-Pr-Version: www-1.0

>Number:         53739
>Category:       kern
>Synopsis:       usbhidctl blocks forever if usbhidaction is running on the same device
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Nov 25 00:25:00 +0000 2018
>Originator:     Rob Braun
>Release:        NetBSD 8.99.26
>Organization:
>Environment:
pinebook
>Description:
When usbhidaction is running and you run usbhidctl, usbhidctl will be stuck in uninterruptible wait until either an event comes in to wake usbhidaction, or usbhidaction exits.  usbhidctl's uhidev_open blocks trying to acquire sc->sc_lock before checking sc_state & UHIDEV_OPEN.                     But usbhidaction's uhid_do_read holds that lock while waiting for an event.
>How-To-Repeat:
Start usbhidaction:
/usr/bin/usbhidaction -c /etc/usbhidaction.conf -f /dev/uhid0 -i -p /var/run/usbhidaction-uhid0.pid

usbhidaction is now blocked in read() on the device, which is parked in uhid_do_read doing a cv_wait_sig() holding sc->sc_lock.

Run usbhidctl against the same device (or anything that attempts to open the device usbhidaction is using, including accidentally running usbhidaction again):
/usr/bin/usbhidctl -f /dev/uhid0 -v -r -a
usbhidctl will attempt to open the device, which attempts to acquire the sc_lock that usbhidaction's read holds.

Check ps, usbhidctl will be in state "D+" and unkillable.

Waking up usbhidaction's read with either a signal, or generating an event on the device will cause usbhidctl to wake up and return EBUSY.
>Fix:

Home	PR Database Search