CVS: cvs.openbsd.org: src

2022-07-01 Thread Daniel Jakots
CVSROOT:/cvs
Module name:src
Changes by: d...@cvs.openbsd.org2022/07/01 21:32:05

Modified files:
etc: changelist 

Log message:
Add /etc/rpki/skiplist

ok tb



CVS: cvs.openbsd.org: src

2022-07-01 Thread Theo de Raadt
CVSROOT:/cvs
Module name:src
Changes by: dera...@cvs.openbsd.org 2022/07/01 21:03:00

Modified files:
distrib/sets/lists/comp: md.amd64 

Log message:
sync



CVS: cvs.openbsd.org: xenocara

2022-07-01 Thread Christian Weisgerber
CVSROOT:/cvs
Module name:xenocara
Changes by: na...@cvs.openbsd.org   2022/07/01 14:42:06

Modified files:
app/xenodm/config: Xsession.in 
app/xinit  : xinitrc.cpp 

Log message:
X11 session startup: update list of ssh key files, tweak sh code

ok matthieu@



CVS: cvs.openbsd.org: src

2022-07-01 Thread Vitaliy Makkoveev
CVSROOT:/cvs
Module name:src
Changes by: m...@cvs.openbsd.org2022/07/01 03:57:24

Modified files:
usr.sbin/npppd/npppd: npppd.c 

Log message:
Remove PIPEXCSESSION ioctl(2) call only from npppd(8).

Long time ago pipex(4) sessions can't be deleted until pipex(4) queues
become empty. Such dead sessions stay linked to the stack and the
session `ip_forward' flag was used to prevent packets processing. But
now pipex(4) session could be closed just after close request. This
logic became unnecessary.

PIPEXCSESSION ioctl(2) will be removed from kernel with upcoming diff.

ok yasuoka@



CVS: cvs.openbsd.org: src

2022-07-01 Thread Vitaliy Makkoveev
CVSROOT:/cvs
Module name:src
Changes by: m...@cvs.openbsd.org2022/07/01 03:56:18

Modified files:
sys/kern   : uipc_socket.c uipc_socket2.c uipc_syscalls.c 
 uipc_usrreq.c 
sys/miscfs/fifofs: fifo_vnops.c 
sys/sys: socketvar.h unpcb.h 

Log message:
Make fine grained unix(4) domain sockets locking. Use the per-socket
`so_lock' rwlock(9) instead of global `unp_lock' which locks the whole
layer.

The PCB of unix(4) sockets are linked to each other and we need to lock
them both. This introduces the lock ordering problem, because when the
thread (1) keeps lock on `so1' and trying to lock `so2', the thread (2)
could hold lock on `so2' and trying to lock `so1'. To solve this we
always lock sockets in the strict order.

For the sockets which are already accessible from userland, we always
lock socket with the smallest memory address first. Sometimes we need to
unlock socket before lock it's peer and lock it again.

We use reference counters for prevent the connected peer destruction
during to relock. We also handle the case where the peer socket was
replaced by another socket.

For the newly connected sockets, which are not yet exported to the
userland by accept(2), we always lock the listening socket `head' first.
This allows us to avoid unwanted relock within accept(2) syscall.

ok claudio@