From: Eli Billauer <eli.billauer@gmail.com>
To: gregkh@linuxfoundation.org
Cc: arnd@arndb.de, linux-kernel@vger.kernel.org,
Eli Billauer <eli.billauer@gmail.com>
Subject: [PATCH 6/8] char: xillybus: Correct handling of wait queue
Date: Mon, 9 Nov 2026 12:27:58 +0100 [thread overview]
Message-ID: <20261109112800.48663-7-eli.billauer@gmail.com> (raw)
In-Reply-To: <20261109112800.48663-1-eli.billauer@gmail.com>
Don't use wait_event_interruptible() in an infinite while loop, and
replace with a non-interruptible timed-out wait instead. Use wake_up()
instead of wake_up_interruptible() to match that change.
Also, use the correct form of wait function in the disconnect method.
Assisted-by: Sashiko-0.2.5:gemini-3.1-pro-preview
Link: https://sashiko.dev/#/patchset/20260724094302.50761-1-eli.billauer@gmail.com
Signed-off-by: Eli Billauer <eli.billauer@gmail.com>
---
drivers/char/xillybus/xillyusb.c | 49 ++++++++++++--------------------
1 file changed, 18 insertions(+), 31 deletions(-)
diff --git a/drivers/char/xillybus/xillyusb.c b/drivers/char/xillybus/xillyusb.c
index 3afd9bd38a1a..09c7b0ecab59 100644
--- a/drivers/char/xillybus/xillyusb.c
+++ b/drivers/char/xillybus/xillyusb.c
@@ -40,6 +40,7 @@ MODULE_LICENSE("GPL v2");
#define XILLY_RX_TIMEOUT (10 * HZ / 1000)
#define XILLY_RESPONSE_TIMEOUT (500 * HZ / 1000)
+#define XILLY_ETERNITY_TIMEOUT (10 * HZ)
#define BUF_SIZE_ORDER 4
#define BUFNUM 8
@@ -596,11 +597,11 @@ static void wakeup_all(struct work_struct *work)
* processed.
*/
chan->read_data_ok = 0;
- wake_up_interruptible(&chan->in_fifo->waitq);
+ wake_up(&chan->in_fifo->waitq);
}
if (chan->out_ep)
- wake_up_interruptible(&chan->out_ep->fifo.waitq);
+ wake_up(&chan->out_ep->fifo.waitq);
mutex_unlock(&chan->lock);
@@ -609,7 +610,7 @@ static void wakeup_all(struct work_struct *work)
mutex_unlock(&xdev->process_in_mutex);
- wake_up_interruptible(&xdev->msg_ep->fifo.waitq);
+ wake_up(&xdev->msg_ep->fifo.waitq);
kref_put(&xdev->kref, cleanup_dev);
}
@@ -872,7 +873,7 @@ static void try_queue_bulk_out(struct xillyusb_endpoint *ep)
mutex_unlock(&ep->ep_mutex);
if (do_wake)
- wake_up_interruptible(&fifo->waitq);
+ wake_up(&fifo->waitq);
}
static void bulk_out_work(struct work_struct *work)
@@ -918,7 +919,7 @@ static int process_in_opcode(struct xillyusb_dev *xdev,
in_fifo = READ_ONCE(chan->in_fifo);
if (in_fifo)
- wake_up_interruptible(&in_fifo->waitq);
+ wake_up(&in_fifo->waitq);
break;
case OPCODE_REACHED_CHECKPOINT:
@@ -1018,7 +1019,7 @@ static int process_bulk_in(struct xillybuffer *xb)
return -EIO;
}
- wake_up_interruptible(&fifo->waitq);
+ wake_up(&fifo->waitq);
dwconsume = (bytes + 3) >> 2;
dws -= dwconsume;
@@ -1089,18 +1090,10 @@ static int xillyusb_send_opcode(struct xillyusb_dev *xdev,
mutex_lock(&xdev->msg_mutex);
- /*
- * The wait queue is woken with the interruptible variant, so the
- * wait function matches, however returning because of an interrupt
- * will mess things up considerably, in particular when the caller is
- * the release method. And the xdev->error part prevents being stuck
- * forever in the event of a bizarre hardware bug: Pull the USB plug.
- */
-
- while (wait_event_interruptible(fifo->waitq,
- fifo->fill <= (fifo->size - 8) ||
- xdev->error))
- ; /* Empty loop */
+ if (!wait_event_timeout(fifo->waitq,
+ fifo->fill <= (fifo->size - 8) ||
+ xdev->error, XILLY_ETERNITY_TIMEOUT))
+ report_io_error(xdev, -EIO);
if (xdev->error) {
rc = xdev->error;
@@ -1719,18 +1712,12 @@ static int xillyusb_release(struct inode *inode, struct file *filp)
* If rc_read is nonzero, xdev->error indicates a global
* device error. The error is reported later, so that
* resources are freed.
- *
- * Looping on wait_event_interruptible() kinda breaks the idea
- * of being interruptible, and this should have been
- * wait_event(). Only it's being waken with
- * wake_up_interruptible() for the sake of other uses. If
- * there's a global device error, chan->read_data_ok is
- * deasserted and the wait queue is awaken, so this is covered.
*/
- while (wait_event_interruptible(in_fifo->waitq,
- !chan->read_data_ok))
- ; /* Empty loop */
+ if (!wait_event_timeout(in_fifo->waitq,
+ !chan->read_data_ok,
+ XILLY_ETERNITY_TIMEOUT))
+ report_io_error(xdev, -EIO);
safely_assign_in_fifo(chan, NULL);
fifo_mem_release(in_fifo);
@@ -2240,9 +2227,9 @@ static void xillyusb_disconnect(struct usb_interface *interface)
* but somehow the message wasn't sent. Should never happen.
*/
- rc = wait_event_interruptible_timeout(fifo->waitq,
- msg_ep->drained || xdev->error,
- XILLY_RESPONSE_TIMEOUT);
+ rc = wait_event_timeout(fifo->waitq,
+ msg_ep->drained || xdev->error,
+ XILLY_RESPONSE_TIMEOUT);
if (!rc)
dev_err(&interface->dev,
--
2.17.1
next prev parent reply other threads:[~2026-11-09 11:28 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-09 11:27 [PATCH 0/8] char: xillybus: Fix issues reported by Sashiko Eli Billauer
2026-11-09 11:27 ` [PATCH 1/8] char: xillybus: Use unsigned int literal Eli Billauer
2026-11-09 11:27 ` [PATCH 2/8] char: xillybus: Safer access of unaligned pointers Eli Billauer
2026-11-09 11:27 ` [PATCH 3/8] char: xillybus: Return error in fops read method handler Eli Billauer
2026-11-09 11:27 ` [PATCH 4/8] char: xillybus: Rely on FMODE flags in poll method Eli Billauer
2026-11-09 11:27 ` [PATCH 5/8] char: xillybus: Refactor flush function Eli Billauer
2026-11-09 11:27 ` Eli Billauer [this message]
2026-11-09 11:27 ` [PATCH 7/8] char: xillybus: Avoid indefinite sleep of work item Eli Billauer
2026-11-09 11:28 ` [PATCH 8/8] char: xillybus: Cancel delayed work items before teardown Eli Billauer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261109112800.48663-7-eli.billauer@gmail.com \
--to=eli.billauer@gmail.com \
--cc=arnd@arndb.de \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®