On 03/11/19(Sun) 13:12, Ted Unangst wrote:
> Martin Pieuchot wrote:
> > The last, now reverted change, to uvm_map_inentry() exposes a race that
> > is reproducible while building lang/go on amd64 which makes uvm_fault()
> > fail, resulting a in a SIGSEV of at least one of the processes.
>
> > Interestingly the machine cannot reproduce the race if the KERNEL_LOCK()
> > is used as a barrier, like in the diff below.
> >
> > I couldn't reproduce the race with the go programs in src/regress.
> > Building go is huge and difficult to instrument.
> >
> > By looking at sigpanic() in the traces it seems that stack manipulation
> > is generally the trigger. I'm guessing the issue needs a multi-threaded
> > program to be exposed but at that stage I'd appreciate any pointer or
> > any simpler way to trigger the race.
>
> Can you explain the race some more? The lock changes below would all seem to
> come too late to resolve any races.
I don't know. All I know is that the diff that got reverted causes the
build processes of golang to segfault. If you have an easier way to
reproduce the problem, I'm interested ;)
>
> > if (uvm_map_inentry_recheck(serial, addr, ie)) {
> > KERNEL_LOCK();
> > + KERNEL_UNLOCK();
>
> This in particular looks pretty weird.
That's just a barrier. It's to show that taking & releasing the lock
here is sufficient to avoid the segfault. In that scenario the map lock
is grabbed w/o the KERNEL_LOCK(), that said, it doesn't prove anything ;)
