mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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


  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®