lkml.org 
[lkml]   [2004]   [May]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] Fix deadlock in __create_workqueue
Srivatsa Vaddagiri <vatsa@in.ibm.com> wrote:
>
> On Fri, Apr 30, 2004 at 07:27:12PM -0700, Andrew Morton wrote:
> > Can we not simply do:
> >
> >
> > diff -puN kernel/workqueue.c~a kernel/workqueue.c
> > --- 25/kernel/workqueue.c~a 2004-04-30 19:26:32.003303600 -0700
> > +++ 25-akpm/kernel/workqueue.c 2004-04-30 19:26:44.492404968 -0700
> > @@ -334,6 +334,7 @@ struct workqueue_struct *__create_workqu
> > destroy = 1;
> > }
> > }
> > + unlock_cpu_hotplug();
> >
> > /*
> > * Was there any error during startup? If yes then clean up:
> > @@ -342,7 +343,6 @@ struct workqueue_struct *__create_workqu
> > destroy_workqueue(wq);
> > wq = NULL;
> > }
> > - unlock_cpu_hotplug();
> > return wq;
> > }
>
> I didn't do this because I introduced a break at the first instance
> when create_workqueue_thread failed. Breaking out of the loop
> like that appeared to be more efficient rather than going back and
> trying to create threads for rest of the online cpus, because most
> likely thread creation will fail for other cpus also and anyway
> the workqueue will be destroyed down the line.

Well that create_workqueue_thread() will basically never fail - it's not a
path we need to be optimising.

And from inspection, cleanup_workqueue_thread() will handle the
non-existent thread quite happily.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:02    [W:0.068 / U:0.680 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site