Re: Unlock umask(2)

On Wed, May 11, 2022 at 02:33:34PM -0600, Theo de Raadt wrote: > Vitaliy Makkoveev wrote: > > > On Wed, May 11, 2022 at 01:22:51PM -0600, Theo de Raadt wrote: > > > Vitaliy Makkoveev wrote: > > > > > > > Index: sys/sys/filedesc.h > > > > =

Re: Unlock umask(2)

Vitaliy Makkoveev wrote: > On Wed, May 11, 2022 at 01:22:51PM -0600, Theo de Raadt wrote: > > Vitaliy Makkoveev wrote: > > > > > Index: sys/sys/filedesc.h > > > === > > > RCS file: /cvs/src/sys/sys/filedesc.h,v > > > retrieving rev

Re: Unlock umask(2)

On Wed, May 11, 2022 at 01:22:51PM -0600, Theo de Raadt wrote: > Vitaliy Makkoveev wrote: > > > Index: sys/sys/filedesc.h > > === > > RCS file: /cvs/src/sys/sys/filedesc.h,v > > retrieving revision 1.45 > > diff -u -p -r1.45 filedesc

Re: Unlock umask(2)

Vitaliy Makkoveev wrote: > Index: sys/sys/filedesc.h > === > RCS file: /cvs/src/sys/sys/filedesc.h,v > retrieving revision 1.45 > diff -u -p -r1.45 filedesc.h > --- sys/sys/filedesc.h4 Jul 2020 08:06:08 - 1.45 > +++

Re: Unlock umask(2)

On Wed, May 11, 2022 at 09:49:34AM -0600, Theo de Raadt wrote: > Alexander Bluhm wrote: > > > On Wed, May 11, 2022 at 11:20:15AM +0300, Vitaliy Makkoveev wrote: > > > sys_umask() only modifies `fd_cmask', which modification is already > > > protected by `fd_lock' rwlock(9). > > > > I found this

Re: more rpki-client refactor

On Wed, May 11, 2022 at 06:54:32PM +0200, Claudio Jeker wrote: > I took the liberty and refactored the sbgp_assysnum() code a bit more. > > Main goal is to replace the reallocarray() in append_as() with an upfront > calloc() call since now the size is known. Also I decided to collaps > sbgp_asnum(

Re: Mark pw_error __dead in util.h

On Tue, May 03, 2022 at 10:37:36PM -0500, Matthew Martin wrote: > The function is already marked __dead in passwd.c, so appears to just be > an oversight. Committed, thanks. - todd

Re: amd64: do CPU identification before TSC sync test

> On May 11, 2022, at 2:51 AM, Yuichiro NAITO wrote: > > On 5/11/22 14:34, Yuichiro NAITO wrote: >> After applying your patch, cpu1 is not identified on my current kernel. >> Dmesg shows as follows. I'll see it further more. > > I found that LAPIC is necessary for `delay` function that is used i

more rpki-client refactor

I took the liberty and refactored the sbgp_assysnum() code a bit more. Main goal is to replace the reallocarray() in append_as() with an upfront calloc() call since now the size is known. Also I decided to collaps sbgp_asnum() into sbgp_assysnum(). One could also inline the now very simple append

Re: amd64: do CPU identification before TSC sync test

try next snap clematis wrote: > Hi, > I can't see any recent commits but has any of those changes been added to > recent snapshots? I was running one from 2nd of May and wasn't hitting > those cpu failed to identify errors but I do with the one from the 10th > of May. > > > cpu1 at mainbus0:

Re: Unlock umask(2)

I see no userland impact from such a change (except libkvm against kernel corefiles, which doesn't matter)

Re: Unlock umask(2)

Alexander Bluhm wrote: > On Wed, May 11, 2022 at 11:20:15AM +0300, Vitaliy Makkoveev wrote: > > sys_umask() only modifies `fd_cmask', which modification is already > > protected by `fd_lock' rwlock(9). > > I found this in sys/filedesc.h > > u_short fd_cmask; /* [f/w] mask

Re: rpki-client: cache X509v3 extensions early

On Wed, May 11, 2022 at 08:50:57AM -0600, Bob Beck wrote: > yes makes sense > > ok beck@ agreed, ok claudio@ > > On May 11, 2022, at 07:53, Theo Buehler wrote: > > > > Some funky libcrypto business ahead. > > > > X509 API functions such as X509_check_ca() or X509_get_extension_flags() > > c

Re: Unlock umask(2)

On Wed, May 11, 2022 at 11:20:15AM +0300, Vitaliy Makkoveev wrote: > sys_umask() only modifies `fd_cmask', which modification is already > protected by `fd_lock' rwlock(9). I found this in sys/filedesc.h u_short fd_cmask; /* [f/w] mask for file creation */ u_short fd

Re: rpki-client: cache X509v3 extensions early

yes makes sense ok beck@ > On May 11, 2022, at 07:53, Theo Buehler wrote: > > Some funky libcrypto business ahead. > > X509 API functions such as X509_check_ca() or X509_get_extension_flags() > cache X509v3 extensions internally if they're not already cached. They > make decisions based on (o

rpki-client: cache X509v3 extensions early

Some funky libcrypto business ahead. X509 API functions such as X509_check_ca() or X509_get_extension_flags() cache X509v3 extensions internally if they're not already cached. They make decisions based on (or report some of) the cached values. Although it's unlikely, this caching may fail halfway

Re: [PATCH] reorder_kernel: also redirect stderr to new logfile

On Wed, May 11, 2022 at 07:05:29PM +0900, Lauri Tirkkonen wrote: > Hi, > > I had reorder_kernel failing but generating empty log files. The root cause of > the log file being empty is that if $KERNEL_DIR.tgz exists, a new log file is > created but stderr keeps going to the old (now deleted) one. S

Unlock umask(2)

sys_umask() only modifies `fd_cmask', which modification is already protected by `fd_lock' rwlock(9). Index: sys/kern/syscalls.master === RCS file: /cvs/src/sys/kern/syscalls.master,v retrieving revision 1.223 diff -u -p -r1.223 sysca

Re: amd64: do CPU identification before TSC sync test

On 5/11/22 14:34, Yuichiro NAITO wrote: After applying your patch, cpu1 is not identified on my current kernel. Dmesg shows as follows. I'll see it further more. I found that LAPIC is necessary for `delay` function that is used in `idendifycpu` and waiting loop for CPUF_IDENTIFY flag is set.

Re: rpki-client: deserialize ASIdentifiers in libcrypto

On Tue, May 10, 2022 at 08:43:45PM +0200, Theo Buehler wrote: > The ASIdentifiers code is a bit strangely factored presumably due to > constraints of the low-level shoveling. I kept the coarse structure > of the code and left some house keeping for later. The changes in > sbgp_asrange() and sbgp_as