On Thu, 29 Jan 2009 00:08:39 +0100 Frederic Weisbecker <fweisbec@xxxxxxxxx> wrote: > > > @@ -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? > > > > > 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?". -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
