PERFORCE change 104043 for review
John Baldwin
jhb at freebsd.org
Tue Aug 15 16:02:40 UTC 2006
On Tuesday 15 August 2006 11:44, Divacky Roman wrote:
> On Tue, Aug 15, 2006 at 11:30:16AM -0400, John Baldwin wrote:
> > On Tuesday 15 August 2006 11:23, Roman Divacky wrote:
> > > http://perforce.freebsd.org/chv.cgi?CH=104043
> > >
> > > Change 104043 by rdivacky at rdivacky_witten on 2006/08/15 15:22:57
> > >
> > > Grrrr. Do the locking/unlocking correctly this time.
> > >
> > > Affected files ...
> > >
> >
> .. //depot/projects/soc2006/rdivacky_linuxolator/compat/linux/linux_futex.c#27
> > edit
> > >
> > > Differences ...
> > >
> > >
> >
==== //depot/projects/soc2006/rdivacky_linuxolator/compat/linux/linux_futex.c#27
> > (text+ko) ====
> > >
> > > @@ -339,9 +339,13 @@
> > > return f;
> > > }
> > > }
> > > + if (locked == FUTEX_UNLOCKED)
> > > + FUTEX_UNLOCK;
> > >
> > > /* Not found, create it */
> > > f = malloc(sizeof(*f), M_LINUX, M_WAITOK);
> > > + if (locked == FUTEX_UNLOCKED)
> > > + FUTEX_LOCK;
> > > f->f_uaddr = uaddr;
> > > f->f_refcount = 1;
> > > TAILQ_INIT(&f->f_waiting_proc);
> >
> > This readds the race. :) See my other e-mail on what you have to do to
handle
> > it.
>
> what is wrong with unprotected malloc? the memory at which f points at is
nowhere referenced
> nowhere added etc. until protected by the lock.
>
> can you please explain me why is this wrong? I dont see any harm with two
processes executing
> this code paralelly.
The problem is if both threads add a futex for the same address then you'll
have two structures for the same futex.
--
John Baldwin
More information about the p4-projects
mailing list