OpenBSD src changes summary for 2017-11-24 ==========================================
regress/sbin regress/sys sbin/dhclient share/man sys/arch/armv7/sunxi sys/kern sys/sys usr.bin/openssl usr.sbin/syslogd == regress =========================================================== 01/06 == http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/regress sbin ~ pfctl/Makefile ~ pfctl/if2ip ~ pfctl/pfr.exec > Use the environment variable PFCTL to specify a different executable > for testing. Default is /sbin/pfctl. This makes test driven > development easier. (bluhm@) sys ~ net/loop/Makefile > Do not run sysctl and pfctl by != during make clean and make obj. > requested by miod@ (bluhm@) == sbin ============================================================== 02/06 == http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sbin dhclient ~ dhclient.c ~ dhcpd.h > Remove 'renewal' field from struct client_lease. Add lease_renewal() to > calculate the value when required for a particular lease. (krw@) == share ============================================================= 03/06 == http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/share man ~ man9/timeout.9 > add timeout_barrier, which is like intr_barrier and taskq_barrier. > if you're trying to free something that a timeout is using, you > have to wait for that timeout to finish running before doing the > free. timeout_del can stop a timeout from running in the future, > but it doesn't know if a timeout has finished being scheduled and > is now running. > previously you could know that timeouts are not running by simply > masking softclock interrupts on the cpu running the kernel. however, > code is now running outside the kernel lock, and timeouts can run > in a thread instead of softclock. > timeout_barrier solves the first problem by taking the kernel lock > and then masking softclock interrupts. that is enough to ensure > that any further timeout processing is waiting for those resources > to run again. > the second problem is solved by having timeout_barrier insert work > into the thread. when that work runs, that means all previous work > running in that thread has completed. > fixes and ok visa@, who thinks this will be useful for his work > too. (dlg@) == sys =============================================================== 04/06 == http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys arch/armv7/sunxi ~ sxie.c > rework transmit to get rid of ifq_deq_begin, and to improve speed. > i had a diff that did a small change to replace > ifq_deq_begin/commit/rollback with ifq_dequeue, and Eduard Nicodei > tweaked it a bit with Artturi Alm to use the fifo registers properly > and bump the ifq len. > the latter changes improve performance significantly. > "if you think that diff is correct, commit it" kettenis@ (dlg@) kern ~ kern_timeout.c > add timeout_barrier, which is like intr_barrier and taskq_barrier. > if you're trying to free something that a timeout is using, you > have to wait for that timeout to finish running before doing the > free. timeout_del can stop a timeout from running in the future, > but it doesn't know if a timeout has finished being scheduled and > is now running. > previously you could know that timeouts are not running by simply > masking softclock interrupts on the cpu running the kernel. however, > code is now running outside the kernel lock, and timeouts can run > in a thread instead of softclock. > timeout_barrier solves the first problem by taking the kernel lock > and then masking softclock interrupts. that is enough to ensure > that any further timeout processing is waiting for those resources > to run again. > the second problem is solved by having timeout_barrier insert work > into the thread. when that work runs, that means all previous work > running in that thread has completed. > fixes and ok visa@, who thinks this will be useful for his work > too. (dlg@) sys ~ timeout.h > add timeout_barrier, which is like intr_barrier and taskq_barrier. > if you're trying to free something that a timeout is using, you > have to wait for that timeout to finish running before doing the > free. timeout_del can stop a timeout from running in the future, > but it doesn't know if a timeout has finished being scheduled and > is now running. > previously you could know that timeouts are not running by simply > masking softclock interrupts on the cpu running the kernel. however, > code is now running outside the kernel lock, and timeouts can run > in a thread instead of softclock. > timeout_barrier solves the first problem by taking the kernel lock > and then masking softclock interrupts. that is enough to ensure > that any further timeout processing is waiting for those resources > to run again. > the second problem is solved by having timeout_barrier insert work > into the thread. when that work runs, that means all previous work > running in that thread has completed. > fixes and ok visa@, who thinks this will be useful for his work > too. (dlg@) == usr.bin =========================================================== 05/06 == http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin openssl ~ apps_posix.c > Use clock_gettime and getrusage to compute real and user time. > Better handling of clock jumps, from Scott Cheloa. (jca@) == usr.sbin ========================================================== 06/06 == http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.sbin syslogd ~ syslogd.c > Revert my change to ignore EIO errors when writing to log files. > Syslogd continued logging messages to a file that had an EIO error. > This could slow down the whole system. File system errors may cause > huge delays at every access. This prevented debugging the issue. > Now syslogd will log a warning and shut down logging to this file > until restart or SIGHUP. > OK deraadt@ espie@ millert@ (bluhm@) =============================================================================== _______________________________________________ odc mailing list [email protected] http://www.squish.net/mailman/listinfo/odc
