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.
> if (uvm_map_inentry_recheck(serial, addr, ie)) {
> KERNEL_LOCK();
> + KERNEL_UNLOCK();
This in particular looks pretty weird.
