OpenBSD src changes summary for 2017-04-13
==========================================

lib/libc                                sbin/fsck_ffs
sbin/iked                               sbin/pfctl
sys/arch/alpha/include                  sys/arch/amd64/include
sys/arch/arm/include                    sys/arch/arm64/arm64
sys/arch/arm64/include                  sys/arch/hppa/include
sys/arch/i386/include                   sys/arch/m88k/include
sys/arch/mips64/include                 sys/arch/mips64/mips64
sys/arch/powerpc/include                sys/arch/sh/include
sys/arch/sparc64/include                sys/kern
sys/sys                                 usr.sbin/dhcpd
usr.sbin/ldapd                          usr.sbin/rebound

== lib =============================================================== 01/04 ==

  http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib

libc

  ~ stdlib/malloc.3                       ~ stdlib/malloc.c

  > allow clearing less than allocated and document freezero(3) better (otto@)

  ~ stdio/getdelim.c                      

  > Use recallocarray in getdelim/getline to clear memory on buffer resizes,
  > inspired by a similar change to fgetln.
  > ok deraadt millert (brynet@)

  ~ sys/execve.2                          

  > Xr sigprocmask(2) not the obsolete sigsetmask(3) (millert@)

== sbin ============================================================== 02/04 ==

  http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sbin

fsck_ffs

  ~ pass4.c                               

  > fix wrongly indented lines (jsg@)

iked

  ~ config.c                              ~ iked.h
  ~ ikev2.c                               ~ ikev2_pld.c

  > Add a NAT-T keepalive timer in case we are behind a NAT gateway.
  > See RFC 5996, section 2.23, NAT Traversal:
  > In the case of a mismatching NAT_DETECTION_DESTINATION_IP hash, it
  > means that the system receiving the NAT_DETECTION_DESTINATION_IP
  > payload is behind a NAT and that system SHOULD start sending
  > keepalive packets as defined in [UDPENCAPS].
  > With markus@, ok reyk@ (patrick@)

pfctl

  ~ pfctl_table.c                         

  > fix wrongly indented lines (jsg@)

== sys =============================================================== 03/04 ==

  http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys

arch/alpha/include

  ~ proc.h                                

  > Provide mips64 with kernel-facing TCB_{GET,SET} macros that store it
  > in struct mdproc.  With that, all archs have those and the __HAVE_MD_TCB
  > macro can be unifdef'ed as always defined.
  > ok kettenis@ visa@ jsing@ (guenther@)

arch/amd64/include

  ~ proc.h                                

  > Provide mips64 with kernel-facing TCB_{GET,SET} macros that store it
  > in struct mdproc.  With that, all archs have those and the __HAVE_MD_TCB
  > macro can be unifdef'ed as always defined.
  > ok kettenis@ visa@ jsing@ (guenther@)

arch/arm/include

  ~ proc.h                                

  > Provide mips64 with kernel-facing TCB_{GET,SET} macros that store it
  > in struct mdproc.  With that, all archs have those and the __HAVE_MD_TCB
  > macro can be unifdef'ed as always defined.
  > ok kettenis@ visa@ jsing@ (guenther@)

arch/arm64/arm64

  ~ pmap.c                                

  > Use the non-interrupt-safe pool allocator for the vp pool to avoid runninng
  > out of kva in the kmem_map.  Avoids a hang when spawning a lot of
  > processes. (kettenis@)

arch/arm64/include

  ~ proc.h                                

  > Provide mips64 with kernel-facing TCB_{GET,SET} macros that store it
  > in struct mdproc.  With that, all archs have those and the __HAVE_MD_TCB
  > macro can be unifdef'ed as always defined.
  > ok kettenis@ visa@ jsing@ (guenther@)

  ~ pte.h                                 

  > A little bit more trivial cleanup. (kettenis@)

arch/hppa/include

  ~ proc.h                                

  > Provide mips64 with kernel-facing TCB_{GET,SET} macros that store it
  > in struct mdproc.  With that, all archs have those and the __HAVE_MD_TCB
  > macro can be unifdef'ed as always defined.
  > ok kettenis@ visa@ jsing@ (guenther@)

arch/i386/include

  ~ proc.h                                

  > Provide mips64 with kernel-facing TCB_{GET,SET} macros that store it
  > in struct mdproc.  With that, all archs have those and the __HAVE_MD_TCB
  > macro can be unifdef'ed as always defined.
  > ok kettenis@ visa@ jsing@ (guenther@)

arch/m88k/include

  ~ proc.h                                

  > Provide mips64 with kernel-facing TCB_{GET,SET} macros that store it
  > in struct mdproc.  With that, all archs have those and the __HAVE_MD_TCB
  > macro can be unifdef'ed as always defined.
  > ok kettenis@ visa@ jsing@ (guenther@)

arch/mips64/include

  ~ proc.h                                ~ tcb.h

  > Provide mips64 with kernel-facing TCB_{GET,SET} macros that store it
  > in struct mdproc.  With that, all archs have those and the __HAVE_MD_TCB
  > macro can be unifdef'ed as always defined.
  > ok kettenis@ visa@ jsing@ (guenther@)

arch/mips64/mips64

  ~ vm_machdep.c                          

  > Provide mips64 with kernel-facing TCB_{GET,SET} macros that store it
  > in struct mdproc.  With that, all archs have those and the __HAVE_MD_TCB
  > macro can be unifdef'ed as always defined.
  > ok kettenis@ visa@ jsing@ (guenther@)

arch/powerpc/include

  ~ proc.h                                

  > Provide mips64 with kernel-facing TCB_{GET,SET} macros that store it
  > in struct mdproc.  With that, all archs have those and the __HAVE_MD_TCB
  > macro can be unifdef'ed as always defined.
  > ok kettenis@ visa@ jsing@ (guenther@)

arch/sh/include

  ~ proc.h                                

  > Provide mips64 with kernel-facing TCB_{GET,SET} macros that store it
  > in struct mdproc.  With that, all archs have those and the __HAVE_MD_TCB
  > macro can be unifdef'ed as always defined.
  > ok kettenis@ visa@ jsing@ (guenther@)

arch/sparc64/include

  ~ proc.h                                

  > Provide mips64 with kernel-facing TCB_{GET,SET} macros that store it
  > in struct mdproc.  With that, all archs have those and the __HAVE_MD_TCB
  > macro can be unifdef'ed as always defined.
  > ok kettenis@ visa@ jsing@ (guenther@)

kern

  ~ kern_exec.c                           ~ kern_fork.c
  ~ kern_prot.c                           ~ kern_sig.c

  > Provide mips64 with kernel-facing TCB_{GET,SET} macros that store it
  > in struct mdproc.  With that, all archs have those and the __HAVE_MD_TCB
  > macro can be unifdef'ed as always defined.
  > ok kettenis@ visa@ jsing@ (guenther@)

  ~ kern_prot.c                           ~ kern_pledge.c
  ~ syscalls.master                       

  > Delete the getlogin59 syscall, which was last used one year, two releases,
  > and four libc major versions ago
  > ok sthen@ jsing@ deraadt@ jca@ (guenther@)

  ~ init_sysent.c                         ~ syscalls.c

  > regen (guenther@)

sys

  ~ proc.h                                

  > Provide mips64 with kernel-facing TCB_{GET,SET} macros that store it
  > in struct mdproc.  With that, all archs have those and the __HAVE_MD_TCB
  > macro can be unifdef'ed as always defined.
  > ok kettenis@ visa@ jsing@ (guenther@)

  ~ syscall.h                             ~ syscallargs.h

  > regen (guenther@)

== usr.sbin ========================================================== 04/04 ==

  http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.sbin

dhcpd

  ~ dhcpd.h                               

  > Remove a bunch of obsolete, unused and irrelevant DHCP client types,
  > fields,
  > and enums. (krw@)

ldapd

  ~ syntax.c                              

  > multi-statement CHECK_RANGE() macro isn't safe for all placements, and
  > needs to use "do {} while 0" idiom; all callers need repair also.
  > Discovered by jsg (deraadt@)

rebound

  ~ rebound.c                             

  > moving some code into a switch meant that break no longer stopped the loop.
  > try harder with a goto. diagnosis and original fix by tb. (tedu@)

===============================================================================
_______________________________________________
odc mailing list
[email protected]
http://www.squish.net/mailman/listinfo/odc

Reply via email to