On Thu, 29 Jan 2009 00:08:39 +0100 Frederic Weisbecker [off-list ref] wrote:

quoted

quoted

@@ -1131,7 +1155,13 @@ static void psmouse_disconnect(struct serio *serio)
 
 	/* make sure we don't have a resync in progress */
 	mutex_unlock(&psmouse_mutex);
-	flush_workqueue(kpsmoused_wq);
+
+	prepare_to_wait(&psmouse->recync_pending_queue, &wait,
+				TASK_UNINTERRUPTIBLE);
+	if (atomic_read(&psmouse->nb_recync_pending))
+		schedule();
+	finish_wait(&psmouse->recync_pending_queue, &wait);

So... we're requiring that nb_recync_pending is zero at this stage?

I wonder if the code manages to do that.  A little WARN_ON(), maybe?

quoted

 	mutex_lock(&psmouse_mutex);
 

After reading how work the async jobs (kernel/async.c), I think it would be better
to actually use it instead of creating a thread through a workqueue and wait for a
counter to be zero to be sure all is flushed.

The async functions provide local execution and synchronisation domains through special cookies,
which means long tasks of mouse resync will not starve other works.

What do you think about it?

Yes, it would be better to use the async infrastructure.

If only to see how the code ends up looking - it _should_ be simpler/cleaner
than the open-coded implementation.  If it isn't, we should ask the async code
"why not?".