Ingo Molnar <[email protected]> wrote:
>
>
> yeah ... cannot remember why i have done it originally :-|
>
Might it be to do with sizeof(task_struct.comm)?
>
> On Wed, 10 Aug 2005, James Bottomley wrote:
>
> > Ingo,
> >
> > This has been in the workqueue code in day one, for no real reason that
> > I can see. We just tripped over it in SCSI because the fibre channel
> > transport class creates one workqueue per host with the name scsi_wq_%d
> > which trips this after we get to 100. Unfortunately we just came across
> > someone with > 100 host adapters ...
> >
> > I think the solution is just to get rid of the artificial limit.
> >
> > James
> >
> > diff --git a/kernel/workqueue.c b/kernel/workqueue.c
> > --- a/kernel/workqueue.c
> > +++ b/kernel/workqueue.c
> > @@ -308,8 +308,6 @@ struct workqueue_struct *__create_workqu
> > struct workqueue_struct *wq;
> > struct task_struct *p;
> >
> > - BUG_ON(strlen(name) > 10);
> > -
> > wq = kmalloc(sizeof(*wq), GFP_KERNEL);
> > if (!wq)
> > return NULL;
> >
> >
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |