OpenBSD cvs log

created 2021-02-09T10:30:44Z
begin 2021-02-08T00:00:00Z
end 2021-02-09T00:00:00Z
path src/sys
commits 10

date 2021-02-08T08:18:45Z
author mpi
files src/sys/dev/dt/dt_dev.c log diff annotate
src/sys/dev/pci/if_myx.c log diff annotate
src/sys/dev/pci/drm/drm_linux.c log diff annotate
src/sys/kern/kern_rwlock.c log diff annotate
src/sys/kern/kern_sched.c log diff annotate
src/sys/kern/kern_sig.c log diff annotate
src/sys/kern/kern_synch.c log diff annotate
src/sys/kern/kern_timeout.c log diff annotate
src/sys/kern/subr_log.c log diff annotate
src/sys/sys/proc.h log diff annotate
src/sys/sys/systm.h log diff annotate
message Simplify sleep_setup API to two operations in preparation for splitting
the SCHED_LOCK().

Putting a thread on a sleep queue is reduce to the following:

sleep_setup();
/* check condition or release lock */
sleep_finish();

Previous version ok cheloha@, jmatthew@, ok claudio@

date 2021-02-08T09:18:30Z
author claudio
files src/sys/kern/tty_pty.c log diff annotate
message Do not hold onto the fdplock longer then needed. Release the lock after
the initial falloc() calls and then regrab it for the fdinsert() or
fdremove() calls respectiviely. Also move closef() outside of the lock.
This replaces the previously reverted lock order change that was reverted.
OK mvs@ visa@

date 2021-02-08T10:51:01Z
author mpi
files src/sys/kern/exec_elf.c log diff annotate
src/sys/kern/init_main.c log diff annotate
src/sys/kern/kern_exit.c log diff annotate
src/sys/kern/kern_fork.c log diff annotate
src/sys/kern/kern_proc.c log diff annotate
src/sys/kern/kern_resource.c log diff annotate
src/sys/kern/kern_sig.c log diff annotate
message Revert the convertion of per-process thread into a SMR_TAILQ.

We did not reach a consensus about using SMR to unlock single_thread_set()
so there's no point in keeping this change.

date 2021-02-08T10:51:02Z
author mpi
files src/sys/kern/kern_synch.c log diff annotate
src/sys/kern/kern_sysctl.c log diff annotate
src/sys/kern/subr_witness.c log diff annotate
src/sys/kern/sys_process.c log diff annotate
src/sys/kern/tty.c log diff annotate
src/sys/sys/proc.h log diff annotate
src/sys/uvm/uvm_glue.c log diff annotate
message Revert the convertion of per-process thread into a SMR_TAILQ.

We did not reach a consensus about using SMR to unlock single_thread_set()
so there's no point in keeping this change.

date 2021-02-08T11:20:03Z
author stsp
files src/sys/conf/files log diff annotate
src/sys/dev/softraid.c log diff annotate
message Add a RAID1C (raid1 + crypto) softraid(8) discipline.

The RAID1C discipline encrypts data like the CRYPTO discipline, and accepts
multiple chunks during creation and assembly like the RAID1 discipline.

To deal with failing disks a RAID1C volume may be assembled with a smaller
number of chunks than the volume was created with. The volume will then come
up in degraded state. If the volume is now detached and assembled again with
the correct number of chunks, any re-added chunks will require a rebuild.

Consequently, assembling RAID1C volumes requires careful attention to the
chunks passed via 'bioctl -l'. If a chunk is accidentally omitted from the
command line during volume assembly, then this chunk will need to be rebuilt.

At least one known-good chunk is required in order to assemble the volume.

Like CRYPTO, RAID1C supports passphrase and key-disk authentication.
Key-disk based volumes are assembled automatically if the key disk is present
while the system is booting up.

Unlike CRYPTO and RAID1, there is no boot support for RAID1C yet.

RAID1C largely reuses existing code of RAID1 and CRYPTO disciplines.
At present RAID1C's discipline-specific data structure is shared with that
of the CRYPTO discipline to allow re-use of existing CRYPTO code. A custom
RAID1C data structure would require CRYPTO code to access struct sr_crypto
via a pointer instead of via a member field of struct sr_discipline.

ok jsing@

date 2021-02-08T11:20:04Z
author stsp
files src/sys/dev/softraid_crypto.c log diff annotate
src/sys/dev/softraidvar.h log diff annotate
message Add a RAID1C (raid1 + crypto) softraid(8) discipline.

The RAID1C discipline encrypts data like the CRYPTO discipline, and accepts
multiple chunks during creation and assembly like the RAID1 discipline.

To deal with failing disks a RAID1C volume may be assembled with a smaller
number of chunks than the volume was created with. The volume will then come
up in degraded state. If the volume is now detached and assembled again with
the correct number of chunks, any re-added chunks will require a rebuild.

Consequently, assembling RAID1C volumes requires careful attention to the
chunks passed via 'bioctl -l'. If a chunk is accidentally omitted from the
command line during volume assembly, then this chunk will need to be rebuilt.

At least one known-good chunk is required in order to assemble the volume.

Like CRYPTO, RAID1C supports passphrase and key-disk authentication.
Key-disk based volumes are assembled automatically if the key disk is present
while the system is booting up.

Unlike CRYPTO and RAID1, there is no boot support for RAID1C yet.

RAID1C largely reuses existing code of RAID1 and CRYPTO disciplines.
At present RAID1C's discipline-specific data structure is shared with that
of the CRYPTO discipline to allow re-use of existing CRYPTO code. A custom
RAID1C data structure would require CRYPTO code to access struct sr_crypto
via a pointer instead of via a member field of struct sr_discipline.

ok jsing@

date 2021-02-08T11:21:53Z
author stsp
files src/sys/dev/softraid_raid1c.c log diff annotate
message Add a RAID1C (raid1 + crypto) softraid(8) discipline.

The RAID1C discipline encrypts data like the CRYPTO discipline, and accepts
multiple chunks during creation and assembly like the RAID1 discipline.

To deal with failing disks a RAID1C volume may be assembled with a smaller
number of chunks than the volume was created with. The volume will then come
up in degraded state. If the volume is now detached and assembled again with
the correct number of chunks, any re-added chunks will require a rebuild.

Consequently, assembling RAID1C volumes requires careful attention to the
chunks passed via 'bioctl -l'. If a chunk is accidentally omitted from the
command line during volume assembly, then this chunk will need to be rebuilt.

At least one known-good chunk is required in order to assemble the volume.

Like CRYPTO, RAID1C supports passphrase and key-disk authentication.
Key-disk based volumes are assembled automatically if the key disk is present
while the system is booting up.

Unlike CRYPTO and RAID1, there is no boot support for RAID1C yet.

RAID1C largely reuses existing code of RAID1 and CRYPTO disciplines.
At present RAID1C's discipline-specific data structure is shared with that
of the CRYPTO discipline to allow re-use of existing CRYPTO code. A custom
RAID1C data structure would require CRYPTO code to access struct sr_crypto
via a pointer instead of via a member field of struct sr_discipline.

ok jsing@

date 2021-02-08T12:30:10Z
author bluhm
files src/sys/net/if.c log diff annotate
src/sys/netinet/ip_carp.c log diff annotate
message Start refcounting interface groups with 1. if_creategroup() returns
a new object that is already refcounted, so carp attach does not
reach into internal structures. Add kasserts to detect counter
overflow or underflow.
OK mvs@

date 2021-02-08T19:37:15Z
author jan
files src/sys/netinet/tcp.h log diff annotate
src/sys/netinet/tcp_output.c log diff annotate
message Remove maxburst feature from tcp_output

OK bluhm@, claudio@, deraadt@

date 2021-02-08T20:07:04Z
author stsp
files src/sys/dev/softraid_raid1c.c log diff annotate
message change discipline name from "RAID1C" to "RAID 1C" to match the man pages