Re: CVS commit: src
On 12.05.2020 02:59, Joerg Sonnenberger wrote: > On Mon, May 11, 2020 at 11:07:02PM +0200, Kamil Rytarowski wrote: >> On 19.04.2020 03:06, Joerg Sonnenberger wrote: >>> Module Name:src >>> Committed By: joerg >>> Date: Sun Apr 19 01:06:16 UTC 2020 >>> >>> Modified Files: >>> src/lib/libc/gen: pthread_atfork.c >>> src/libexec/ld.elf_so: rtld.c rtld.h symbols.map >>> >>> Log Message: >>> Rename __atomic_fork to __locked_fork and give it &errno as argument. >>> rtld and libc use different storage, so the initial version would >>> incorrectly report the failure reason for fork(). >>> >>> There is still a small race condition inside ld.elf_so as it doesn't use >>> thread-safe errno internally, but that's a more contained internal >>> issue. >>> >>> >> >> >> Should we add the same logic for clone(2)? > > clone only exists for Linux compat. I see no reason to support any fork > emulation for it. > > Joerg > This Linux compat is on the source code level and inside the kernel clone() shares the same code with fork(). clone(2) is a regular syscall available in the NetBSD native ABI syscall layers. There are also users (I have got one). All problems for fork() can be reproduced for clone(). But if we want to just mitigate some issues of fork() users and fix/ignore promptly clone() ones, it is fine. signature.asc Description: OpenPGP digital signature
Re: CVS commit: src/sys
On Sun, May 10, 2020 at 03:15:22PM -, Christos Zoulas wrote: > In article <20200508220155.446eef...@cvs.netbsd.org>, > Andrew Doran wrote: > >-=-=-=-=-=- > > > >Module Name: src > >Committed By:ad > >Date:Fri May 8 22:01:55 UTC 2020 > > > >Modified Files: > > src/sys/arch/x86/include: cpu_counter.h > > src/sys/arch/x86/x86: cpu.c tsc.c > > src/sys/dev/ic: hpet.c hpetvar.h > > > >Log Message: > >Fix the TSC timecounter (on the systems I have access to): > > > >- Make the early i8254-based calculation of frequency a bit more accurate. > > > >- Keep track of how far the HPET & TSC advance between HPET attach and > > secondary CPU boot, and use to compute an accurate value before attaching > > the timecounter. Initial idea from joerg@. > > > >- When determining skew and drift between CPUs, make each measurement 1000 > > times and pick the lowest observed value. Increase the error threshold to > > 1000 clock cycles. > > > >- Use the frequency computed on the boot CPU for secondary CPUs too. > > > >- Remove cpu_counter_serializing(). > > The TSC is still faster than it is supposed to be so ntpd does not sync > (it diverges). It is better than before but not good enough to keep time. I suspect this problem is related to the MSR-based freq determination rather than the calibration so hopefully in combo with msaitoh@'s follow-up change it should be fixed. Andrew
Re: CVS commit: src
On Tue, May 12, 2020 at 10:51:51AM +0200, Kamil Rytarowski wrote: > On 12.05.2020 02:59, Joerg Sonnenberger wrote: > > On Mon, May 11, 2020 at 11:07:02PM +0200, Kamil Rytarowski wrote: > >> On 19.04.2020 03:06, Joerg Sonnenberger wrote: > >>> Module Name: src > >>> Committed By: joerg > >>> Date: Sun Apr 19 01:06:16 UTC 2020 > >>> > >>> Modified Files: > >>> src/lib/libc/gen: pthread_atfork.c > >>> src/libexec/ld.elf_so: rtld.c rtld.h symbols.map > >>> > >>> Log Message: > >>> Rename __atomic_fork to __locked_fork and give it &errno as argument. > >>> rtld and libc use different storage, so the initial version would > >>> incorrectly report the failure reason for fork(). > >>> > >>> There is still a small race condition inside ld.elf_so as it doesn't use > >>> thread-safe errno internally, but that's a more contained internal > >>> issue. > >>> > >>> > >> > >> > >> Should we add the same logic for clone(2)? > > > > clone only exists for Linux compat. I see no reason to support any fork > > emulation for it. > > > > Joerg > > > > This Linux compat is on the source code level and inside the kernel > clone() shares the same code with fork(). > > clone(2) is a regular syscall available in the NetBSD native ABI syscall > layers. There are also users (I have got one). > > All problems for fork() can be reproduced for clone(). But if we want to > just mitigate some issues of fork() users and fix/ignore promptly > clone() ones, it is fine. clone(2) already has a huge set of race conditions it will hit in various parts of libc, libpthread etc when it is used to emulate fork. It is a non-standard interface too with no mechanisms for resolving any of those races. I see no reason for pretending that it is anywhere usable. Joerg
