OpenBSD src changes summary for 2015-11-20 ==========================================
bin/ed bin/ksh bin/stty distrib/miniroot distrib/sets games/atc games/tetris gnu/usr.bin/cvs gnu/usr.bin/texinfo include/string.h include/strings.h lib/libc lib/libkeynote libexec libexec/login_tis sbin/growfs sbin/route share/man sys/arch/armv7/imx sys/arch/armv7/sunxi sys/arch/octeon/dev sys/arch/sgi/dev sys/arch/sgi/hpc sys/arch/socppc/dev sys/arch/sparc64/dev sys/arch/vax/if sys/dev sys/dev/ic sys/dev/isa sys/dev/pci sys/dev/pcmcia sys/dev/usb sys/kern sys/net sys/netinet sys/sys usr.bin/less usr.bin/lex usr.bin/mandoc usr.bin/openssl usr.bin/skeyinit usr.bin/ssh usr.bin/tail usr.bin/telnet usr.bin/tmux usr.bin/vi usr.sbin/bgpd usr.sbin/ntpd usr.sbin/rpc.bootparamd usr.sbin/slowcgi usr.sbin/trpt == bin =============================================================== 01/12 == http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/bin ed ~ ed.1 ~ main.c > make ed restore the user defined prompt (specified with -p) when it was > turned > off and then on again with 'P'. > ok daniel@ (tb@) ~ ed.1 > honestly i think you should just zap that paragraph - it doesn;t make > sense to document that posix more or less says something should happen, > and that it does. > jmc (tb@) ksh ~ sh.h > remove unused prototype > ok mmcc@ (tb@) stty ~ key.c > KNF (deraadt@) ~ stty.c > Cannot pledge bottom half of setting, because of the ioctl backing > "extproc", "ostart" and "ostop" are not allowed (yet?) (deraadt@) == distrib =========================================================== 02/12 == http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/distrib miniroot ~ install.sub > don't auto-skip X sets on systems without wscons, you can remove them > easily > with -x*, and "no wscons" doesn't cover all of the systems where one might > intentionally want to skip them anyway. ok bmercer deraadt espie rpe > (sthen@) sets ~ lists/comp/mi > sync (deraadt@) ~ lists/comp/mi > sync (deraadt@) == games ============================================================= 03/12 == http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/games atc ~ main.c > Convert hand-rolled option parsing to getopt(3). > ok deraadt@ (tb@) tetris ~ tetris.6 ~ tetris.c ~ tetris.h > pledge "stdio rpath wpath cpath tty" > "stdio rpath tty" for game play > "rpath wpath cpath" for maintaining highscores in $USER > ok deraadt@ sthen@ (tb@) == gnu =============================================================== 04/12 == http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/gnu usr.bin/cvs ~ acconfig.h ~ configure.in > Server-side pserver support is broken, and we don't plan to support it. > ok sthen@ semarie@ (jca@) ~ configure > Regen. (jca@) usr.bin/texinfo ~ info/terminal.c > Unbreak, tcflow and its underlying ioctls aren't allowed by pledge(2). > Just delete the tcflow(3) calls, the use case for tcflow(3) here is > a bit far-fetched. > looks good to deraadt@, ok espie@ (jca@) == include =========================================================== 05/12 == http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/include string.h ~ string.h > POSIX says that ffs(), strcasecmp(), strncasecmp(), r?index() and > the b* byte functions belong in strings.h, not string.h so break > them out of string.h into a new strings.h. As long as there is no > POSIX or X/OPEN define in use string.h will pull in strings.h. > OK naddy@ deraadt@ (millert@) strings.h ~ strings.h > POSIX says that ffs(), strcasecmp(), strncasecmp(), r?index() and > the b* byte functions belong in strings.h, not string.h so break > them out of string.h into a new strings.h. As long as there is no > POSIX or X/OPEN define in use string.h will pull in strings.h. > OK naddy@ deraadt@ (millert@) == lib =============================================================== 06/12 == http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib libc ~ termios/tcsetpgrp.3 > typo tcgetpgrp -> tcsetpgrp > ok mmcc@, yes... deraadt@ (tb@) ~ uuid/uuid.3 > Document that the status argument may be NULL; OK millert@ (tim@) libkeynote ~ keynote.1 ~ keynote.3 ~ keynote.4 ~ keynote.5 > No longer direct bug reports to [email protected] - it bounces mail. > "fair enough" jmc@ (mmcc@) == libexec =========================================================== 07/12 == http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/libexec libexec ~ Makefile > Remove login_tis, no one should be using the TIS authentication > server these days. (millert@) login_tis - Makefile - login_tis.8 - login_tis.c - login_tis.h > Remove login_tis, no one should be using the TIS authentication > server these days. (millert@) == sbin ============================================================== 08/12 == http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sbin growfs ~ growfs.c > Monospace comments are not meant to be justified. From FreeBSD. (mmcc@) ~ growfs.c > De-justify more comments. From FreeBSD. (mmcc@) route ~ route.c > Replace hardcoded "0" with SHUT_RD; from Ricardo Mestre (jca@) == share ============================================================= 09/12 == http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/share man ~ man9/Makefile + man9/ifq_enq.9 > shuffle struct ifqueue so in flight mbufs are protected by a mutex. > the code is refactored so the IFQ macros call newly implemented ifq > functions. the ifq code is split so each discipline (priq and hfsc > in our case) is an opaque set of operations that the common ifq > code can call. the common code does the locking, accounting (ifq_len > manipulation), and freeing of the mbuf if the disciplines enqueue > function rejects it. theyre kind of like bufqs in the block layer > with their fifo and nscan disciplines. > the new api also supports atomic switching of disciplines at runtime. > the hfsc setup in pf_ioctl.c has been tweaked to build a complete > hfsc_if structure which it attaches to the send queue in a single > operation, rather than attaching to the interface up front and > building up a list of queues. > the send queue is now mutexed, which raises the expectation that > packets can be enqueued or purged on one cpu while another cpu is > dequeueing them in a driver for transmission. a lot of drivers use > IFQ_POLL to peek at an mbuf and attempt to fit it on the ring before > committing to it with a later IFQ_DEQUEUE operation. if the mbuf > gets freed in between the POLL and DEQUEUE operations, fireworks > will ensue. > to avoid this, the ifq api introduces ifq_deq_begin, ifq_deq_rollback, > and ifq_deq_commit. ifq_deq_begin allows a driver to take the ifq > mutex and get a reference to the mbuf they wish to try and tx. if > there's space, they can ifq_deq_commit it to remove the mbuf and > release the mutex. if there's no space, ifq_deq_rollback simply > releases the mutex. this api was developed to make updating the > drivers using IFQ_POLL easy, instead of having to do significant > semantic changes to avoid POLL that we cannot test on all the > hardware. > the common code has been tested pretty hard, and all the driver > modifications are straightforward except for de(4). if that breaks > it can be dealt with later. > ok mpi@ jmatthew@ (dlg@) ~ man9/ifq_enq.9 > do not uppercase Nd; (jmc@) - man9/ifq_enq.9 ~ man9/Makefile + man9/ifq_enqueue.9 > i made a mistake. rename ifq_enq and ifq_deq to ifq_enqueue and ifq_dequeue > fixing it now before i regret it more. (dlg@) ~ man8/afterboot.8 > ntpd ison by default; from rob pierce (deraadt@) - man9/dopowerhooks.9 - man9/powerhook_establish.9 ~ man9/Makefile > After being separated for more than 5 years, allow these poor manuals > to meet their code again... in the bit bucket! (mpi@) ~ man8/afterboot.8 > Don't specify full paths for doas and path, and don't suggest that users > do so. > "good" deraadt@ (mmcc@) ~ man9/Makefile > cleanup powerhooks links too (deraadt@) == sys =============================================================== 10/12 == http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys arch/armv7/imx ~ imxenet.c > shuffle struct ifqueue so in flight mbufs are protected by a mutex. > the code is refactored so the IFQ macros call newly implemented ifq > functions. the ifq code is split so each discipline (priq and hfsc > in our case) is an opaque set of operations that the common ifq > code can call. the common code does the locking, accounting (ifq_len > manipulation), and freeing of the mbuf if the disciplines enqueue > function rejects it. theyre kind of like bufqs in the block layer > with their fifo and nscan disciplines. > the new api also supports atomic switching of disciplines at runtime. > the hfsc setup in pf_ioctl.c has been tweaked to build a complete > hfsc_if structure which it attaches to the send queue in a single > operation, rather than attaching to the interface up front and > building up a list of queues. > the send queue is now mutexed, which raises the expectation that > packets can be enqueued or purged on one cpu while another cpu is > dequeueing them in a driver for transmission. a lot of drivers use > IFQ_POLL to peek at an mbuf and attempt to fit it on the ring before > committing to it with a later IFQ_DEQUEUE operation. if the mbuf > gets freed in between the POLL and DEQUEUE operations, fireworks > will ensue. > to avoid this, the ifq api introduces ifq_deq_begin, ifq_deq_rollback, > and ifq_deq_commit. ifq_deq_begin allows a driver to take the ifq > mutex and get a reference to the mbuf they wish to try and tx. if > there's space, they can ifq_deq_commit it to remove the mbuf and > release the mutex. if there's no space, ifq_deq_rollback simply > releases the mutex. this api was developed to make updating the > drivers using IFQ_POLL easy, instead of having to do significant > semantic changes to avoid POLL that we cannot test on all the > hardware. > the common code has been tested pretty hard, and all the driver > modifications are straightforward except for de(4). if that breaks > it can be dealt with later. > ok mpi@ jmatthew@ (dlg@) arch/armv7/sunxi ~ sxie.c > shuffle struct ifqueue so in flight mbufs are protected by a mutex. > the code is refactored so the IFQ macros call newly implemented ifq > functions. the ifq code is split so each discipline (priq and hfsc > in our case) is an opaque set of operations that the common ifq > code can call. the common code does the locking, accounting (ifq_len > manipulation), and freeing of the mbuf if the disciplines enqueue > function rejects it. theyre kind of like bufqs in the block layer > with their fifo and nscan disciplines. > the new api also supports atomic switching of disciplines at runtime. > the hfsc setup in pf_ioctl.c has been tweaked to build a complete > hfsc_if structure which it attaches to the send queue in a single > operation, rather than attaching to the interface up front and > building up a list of queues. > the send queue is now mutexed, which raises the expectation that > packets can be enqueued or purged on one cpu while another cpu is > dequeueing them in a driver for transmission. a lot of drivers use > IFQ_POLL to peek at an mbuf and attempt to fit it on the ring before > committing to it with a later IFQ_DEQUEUE operation. if the mbuf > gets freed in between the POLL and DEQUEUE operations, fireworks > will ensue. > to avoid this, the ifq api introduces ifq_deq_begin, ifq_deq_rollback, > and ifq_deq_commit. ifq_deq_begin allows a driver to take the ifq > mutex and get a reference to the mbuf they wish to try and tx. if > there's space, they can ifq_deq_commit it to remove the mbuf and > release the mutex. if there's no space, ifq_deq_rollback simply > releases the mutex. this api was developed to make updating the > drivers using IFQ_POLL easy, instead of having to do significant > semantic changes to avoid POLL that we cannot test on all the > hardware. > the common code has been tested pretty hard, and all the driver > modifications are straightforward except for de(4). if that breaks > it can be dealt with later. > ok mpi@ jmatthew@ (dlg@) arch/octeon/dev ~ if_cnmac.c > Make cnmac compile again after IF_DROP() removal. Just bail out if the > link is down. > ok mpi@ (visa@) arch/sgi/dev ~ if_iec.c ~ if_mec.c > shuffle struct ifqueue so in flight mbufs are protected by a mutex. > the code is refactored so the IFQ macros call newly implemented ifq > functions. the ifq code is split so each discipline (priq and hfsc > in our case) is an opaque set of operations that the common ifq > code can call. the common code does the locking, accounting (ifq_len > manipulation), and freeing of the mbuf if the disciplines enqueue > function rejects it. theyre kind of like bufqs in the block layer > with their fifo and nscan disciplines. > the new api also supports atomic switching of disciplines at runtime. > the hfsc setup in pf_ioctl.c has been tweaked to build a complete > hfsc_if structure which it attaches to the send queue in a single > operation, rather than attaching to the interface up front and > building up a list of queues. > the send queue is now mutexed, which raises the expectation that > packets can be enqueued or purged on one cpu while another cpu is > dequeueing them in a driver for transmission. a lot of drivers use > IFQ_POLL to peek at an mbuf and attempt to fit it on the ring before > committing to it with a later IFQ_DEQUEUE operation. if the mbuf > gets freed in between the POLL and DEQUEUE operations, fireworks > will ensue. > to avoid this, the ifq api introduces ifq_deq_begin, ifq_deq_rollback, > and ifq_deq_commit. ifq_deq_begin allows a driver to take the ifq > mutex and get a reference to the mbuf they wish to try and tx. if > there's space, they can ifq_deq_commit it to remove the mbuf and > release the mutex. if there's no space, ifq_deq_rollback simply > releases the mutex. this api was developed to make updating the > drivers using IFQ_POLL easy, instead of having to do significant > semantic changes to avoid POLL that we cannot test on all the > hardware. > the common code has been tested pretty hard, and all the driver > modifications are straightforward except for de(4). if that breaks > it can be dealt with later. > ok mpi@ jmatthew@ (dlg@) arch/sgi/hpc ~ if_sq.c > shuffle struct ifqueue so in flight mbufs are protected by a mutex. > the code is refactored so the IFQ macros call newly implemented ifq > functions. the ifq code is split so each discipline (priq and hfsc > in our case) is an opaque set of operations that the common ifq > code can call. the common code does the locking, accounting (ifq_len > manipulation), and freeing of the mbuf if the disciplines enqueue > function rejects it. theyre kind of like bufqs in the block layer > with their fifo and nscan disciplines. > the new api also supports atomic switching of disciplines at runtime. > the hfsc setup in pf_ioctl.c has been tweaked to build a complete > hfsc_if structure which it attaches to the send queue in a single > operation, rather than attaching to the interface up front and > building up a list of queues. > the send queue is now mutexed, which raises the expectation that > packets can be enqueued or purged on one cpu while another cpu is > dequeueing them in a driver for transmission. a lot of drivers use > IFQ_POLL to peek at an mbuf and attempt to fit it on the ring before > committing to it with a later IFQ_DEQUEUE operation. if the mbuf > gets freed in between the POLL and DEQUEUE operations, fireworks > will ensue. > to avoid this, the ifq api introduces ifq_deq_begin, ifq_deq_rollback, > and ifq_deq_commit. ifq_deq_begin allows a driver to take the ifq > mutex and get a reference to the mbuf they wish to try and tx. if > there's space, they can ifq_deq_commit it to remove the mbuf and > release the mutex. if there's no space, ifq_deq_rollback simply > releases the mutex. this api was developed to make updating the > drivers using IFQ_POLL easy, instead of having to do significant > semantic changes to avoid POLL that we cannot test on all the > hardware. > the common code has been tested pretty hard, and all the driver > modifications are straightforward except for de(4). if that breaks > it can be dealt with later. > ok mpi@ jmatthew@ (dlg@) arch/socppc/dev ~ if_tsec.c > shuffle struct ifqueue so in flight mbufs are protected by a mutex. > the code is refactored so the IFQ macros call newly implemented ifq > functions. the ifq code is split so each discipline (priq and hfsc > in our case) is an opaque set of operations that the common ifq > code can call. the common code does the locking, accounting (ifq_len > manipulation), and freeing of the mbuf if the disciplines enqueue > function rejects it. theyre kind of like bufqs in the block layer > with their fifo and nscan disciplines. > the new api also supports atomic switching of disciplines at runtime. > the hfsc setup in pf_ioctl.c has been tweaked to build a complete > hfsc_if structure which it attaches to the send queue in a single > operation, rather than attaching to the interface up front and > building up a list of queues. > the send queue is now mutexed, which raises the expectation that > packets can be enqueued or purged on one cpu while another cpu is > dequeueing them in a driver for transmission. a lot of drivers use > IFQ_POLL to peek at an mbuf and attempt to fit it on the ring before > committing to it with a later IFQ_DEQUEUE operation. if the mbuf > gets freed in between the POLL and DEQUEUE operations, fireworks > will ensue. > to avoid this, the ifq api introduces ifq_deq_begin, ifq_deq_rollback, > and ifq_deq_commit. ifq_deq_begin allows a driver to take the ifq > mutex and get a reference to the mbuf they wish to try and tx. if > there's space, they can ifq_deq_commit it to remove the mbuf and > release the mutex. if there's no space, ifq_deq_rollback simply > releases the mutex. this api was developed to make updating the > drivers using IFQ_POLL easy, instead of having to do significant > semantic changes to avoid POLL that we cannot test on all the > hardware. > the common code has been tested pretty hard, and all the driver > modifications are straightforward except for de(4). if that breaks > it can be dealt with later. > ok mpi@ jmatthew@ (dlg@) arch/sparc64/dev ~ vnet.c > shuffle struct ifqueue so in flight mbufs are protected by a mutex. > the code is refactored so the IFQ macros call newly implemented ifq > functions. the ifq code is split so each discipline (priq and hfsc > in our case) is an opaque set of operations that the common ifq > code can call. the common code does the locking, accounting (ifq_len > manipulation), and freeing of the mbuf if the disciplines enqueue > function rejects it. theyre kind of like bufqs in the block layer > with their fifo and nscan disciplines. > the new api also supports atomic switching of disciplines at runtime. > the hfsc setup in pf_ioctl.c has been tweaked to build a complete > hfsc_if structure which it attaches to the send queue in a single > operation, rather than attaching to the interface up front and > building up a list of queues. > the send queue is now mutexed, which raises the expectation that > packets can be enqueued or purged on one cpu while another cpu is > dequeueing them in a driver for transmission. a lot of drivers use > IFQ_POLL to peek at an mbuf and attempt to fit it on the ring before > committing to it with a later IFQ_DEQUEUE operation. if the mbuf > gets freed in between the POLL and DEQUEUE operations, fireworks > will ensue. > to avoid this, the ifq api introduces ifq_deq_begin, ifq_deq_rollback, > and ifq_deq_commit. ifq_deq_begin allows a driver to take the ifq > mutex and get a reference to the mbuf they wish to try and tx. if > there's space, they can ifq_deq_commit it to remove the mbuf and > release the mutex. if there's no space, ifq_deq_rollback simply > releases the mutex. this api was developed to make updating the > drivers using IFQ_POLL easy, instead of having to do significant > semantic changes to avoid POLL that we cannot test on all the > hardware. > the common code has been tested pretty hard, and all the driver > modifications are straightforward except for de(4). if that breaks > it can be dealt with later. > ok mpi@ jmatthew@ (dlg@) arch/vax/if ~ if_qe.c > shuffle struct ifqueue so in flight mbufs are protected by a mutex. > the code is refactored so the IFQ macros call newly implemented ifq > functions. the ifq code is split so each discipline (priq and hfsc > in our case) is an opaque set of operations that the common ifq > code can call. the common code does the locking, accounting (ifq_len > manipulation), and freeing of the mbuf if the disciplines enqueue > function rejects it. theyre kind of like bufqs in the block layer > with their fifo and nscan disciplines. > the new api also supports atomic switching of disciplines at runtime. > the hfsc setup in pf_ioctl.c has been tweaked to build a complete > hfsc_if structure which it attaches to the send queue in a single > operation, rather than attaching to the interface up front and > building up a list of queues. > the send queue is now mutexed, which raises the expectation that > packets can be enqueued or purged on one cpu while another cpu is > dequeueing them in a driver for transmission. a lot of drivers use > IFQ_POLL to peek at an mbuf and attempt to fit it on the ring before > committing to it with a later IFQ_DEQUEUE operation. if the mbuf > gets freed in between the POLL and DEQUEUE operations, fireworks > will ensue. > to avoid this, the ifq api introduces ifq_deq_begin, ifq_deq_rollback, > and ifq_deq_commit. ifq_deq_begin allows a driver to take the ifq > mutex and get a reference to the mbuf they wish to try and tx. if > there's space, they can ifq_deq_commit it to remove the mbuf and > release the mutex. if there's no space, ifq_deq_rollback simply > releases the mutex. this api was developed to make updating the > drivers using IFQ_POLL easy, instead of having to do significant > semantic changes to avoid POLL that we cannot test on all the > hardware. > the common code has been tested pretty hard, and all the driver > modifications are straightforward except for de(4). if that breaks > it can be dealt with later. > ok mpi@ jmatthew@ (dlg@) dev ~ diskmap.c > Add pledge "disklabel", which allows sysctl kern.rawpartition, a > few disklabel ioctls, and the DIOCMAP ioctl against /dev/diskmap used > to translate duid numbers into partitions. > This will allow pledging of at least 12 disk/filesystem aware > programs; due to the negative impact that diff will wait a bit so > everyone has a chance to update their kernels. > ok semarie (deraadt@) dev/ic ~ aic6915.c ~ an.c ~ dc.c ~ elink3.c ~ fxp.c ~ gem.c ~ hme.c ~ lemac.c ~ pgt.c ~ re.c ~ rt2560.c ~ rt2661.c ~ rtw.c ~ smc83c170.c ~ smc91cxx.c ~ ti.c > shuffle struct ifqueue so in flight mbufs are protected by a mutex. > the code is refactored so the IFQ macros call newly implemented ifq > functions. the ifq code is split so each discipline (priq and hfsc > in our case) is an opaque set of operations that the common ifq > code can call. the common code does the locking, accounting (ifq_len > manipulation), and freeing of the mbuf if the disciplines enqueue > function rejects it. theyre kind of like bufqs in the block layer > with their fifo and nscan disciplines. > the new api also supports atomic switching of disciplines at runtime. > the hfsc setup in pf_ioctl.c has been tweaked to build a complete > hfsc_if structure which it attaches to the send queue in a single > operation, rather than attaching to the interface up front and > building up a list of queues. > the send queue is now mutexed, which raises the expectation that > packets can be enqueued or purged on one cpu while another cpu is > dequeueing them in a driver for transmission. a lot of drivers use > IFQ_POLL to peek at an mbuf and attempt to fit it on the ring before > committing to it with a later IFQ_DEQUEUE operation. if the mbuf > gets freed in between the POLL and DEQUEUE operations, fireworks > will ensue. > to avoid this, the ifq api introduces ifq_deq_begin, ifq_deq_rollback, > and ifq_deq_commit. ifq_deq_begin allows a driver to take the ifq > mutex and get a reference to the mbuf they wish to try and tx. if > there's space, they can ifq_deq_commit it to remove the mbuf and > release the mutex. if there's no space, ifq_deq_rollback simply > releases the mutex. this api was developed to make updating the > drivers using IFQ_POLL easy, instead of having to do significant > semantic changes to avoid POLL that we cannot test on all the > hardware. > the common code has been tested pretty hard, and all the driver > modifications are straightforward except for de(4). if that breaks > it can be dealt with later. > ok mpi@ jmatthew@ (dlg@) ~ rt2560.c ~ rt2661.c > Check for space on the ring before dequeuing packets. > Allows us to get rid of mq_requeue(9) and IFQ_POLL(9) because wireless > drivers use a special queue for management frames. > Tested by stsp@, ok dlg@, stsp@ (mpi@) dev/isa ~ if_ef_isapnp.c ~ if_ex.c > shuffle struct ifqueue so in flight mbufs are protected by a mutex. > the code is refactored so the IFQ macros call newly implemented ifq > functions. the ifq code is split so each discipline (priq and hfsc > in our case) is an opaque set of operations that the common ifq > code can call. the common code does the locking, accounting (ifq_len > manipulation), and freeing of the mbuf if the disciplines enqueue > function rejects it. theyre kind of like bufqs in the block layer > with their fifo and nscan disciplines. > the new api also supports atomic switching of disciplines at runtime. > the hfsc setup in pf_ioctl.c has been tweaked to build a complete > hfsc_if structure which it attaches to the send queue in a single > operation, rather than attaching to the interface up front and > building up a list of queues. > the send queue is now mutexed, which raises the expectation that > packets can be enqueued or purged on one cpu while another cpu is > dequeueing them in a driver for transmission. a lot of drivers use > IFQ_POLL to peek at an mbuf and attempt to fit it on the ring before > committing to it with a later IFQ_DEQUEUE operation. if the mbuf > gets freed in between the POLL and DEQUEUE operations, fireworks > will ensue. > to avoid this, the ifq api introduces ifq_deq_begin, ifq_deq_rollback, > and ifq_deq_commit. ifq_deq_begin allows a driver to take the ifq > mutex and get a reference to the mbuf they wish to try and tx. if > there's space, they can ifq_deq_commit it to remove the mbuf and > release the mutex. if there's no space, ifq_deq_rollback simply > releases the mutex. this api was developed to make updating the > drivers using IFQ_POLL easy, instead of having to do significant > semantic changes to avoid POLL that we cannot test on all the > hardware. > the common code has been tested pretty hard, and all the driver > modifications are straightforward except for de(4). if that breaks > it can be dealt with later. > ok mpi@ jmatthew@ (dlg@) dev/pci ~ if_bce.c ~ if_bnx.c ~ if_cas.c ~ if_de.c ~ if_em.c ~ if_ipw.c ~ if_iwi.c ~ if_ix.c ~ if_ixgb.c ~ if_lge.c ~ if_lii.c ~ if_msk.c ~ if_nep.c ~ if_nfe.c ~ if_nge.c ~ if_nxe.c ~ if_pcn.c ~ if_se.c ~ if_sis.c ~ if_sk.c ~ if_stge.c ~ if_tht.c ~ if_txp.c ~ if_vic.c ~ if_vio.c ~ if_xge.c > shuffle struct ifqueue so in flight mbufs are protected by a mutex. > the code is refactored so the IFQ macros call newly implemented ifq > functions. the ifq code is split so each discipline (priq and hfsc > in our case) is an opaque set of operations that the common ifq > code can call. the common code does the locking, accounting (ifq_len > manipulation), and freeing of the mbuf if the disciplines enqueue > function rejects it. theyre kind of like bufqs in the block layer > with their fifo and nscan disciplines. > the new api also supports atomic switching of disciplines at runtime. > the hfsc setup in pf_ioctl.c has been tweaked to build a complete > hfsc_if structure which it attaches to the send queue in a single > operation, rather than attaching to the interface up front and > building up a list of queues. > the send queue is now mutexed, which raises the expectation that > packets can be enqueued or purged on one cpu while another cpu is > dequeueing them in a driver for transmission. a lot of drivers use > IFQ_POLL to peek at an mbuf and attempt to fit it on the ring before > committing to it with a later IFQ_DEQUEUE operation. if the mbuf > gets freed in between the POLL and DEQUEUE operations, fireworks > will ensue. > to avoid this, the ifq api introduces ifq_deq_begin, ifq_deq_rollback, > and ifq_deq_commit. ifq_deq_begin allows a driver to take the ifq > mutex and get a reference to the mbuf they wish to try and tx. if > there's space, they can ifq_deq_commit it to remove the mbuf and > release the mutex. if there's no space, ifq_deq_rollback simply > releases the mutex. this api was developed to make updating the > drivers using IFQ_POLL easy, instead of having to do significant > semantic changes to avoid POLL that we cannot test on all the > hardware. > the common code has been tested pretty hard, and all the driver > modifications are straightforward except for de(4). if that breaks > it can be dealt with later. > ok mpi@ jmatthew@ (dlg@) ~ if_em.c > Revert all the changes to run the tx completion path wihtout holding the > KERNE_LOCK. > A piece is still not right as many peole reported a "watchdog timeout" > problem. > This basically brings us back to r1.305. > ok dlg@, jmatthew@ (mpi@) ~ if_em.h > Missed in previous, pointed by benoit@ (mpi@) dev/pcmcia ~ if_malo.c ~ if_xe.c > shuffle struct ifqueue so in flight mbufs are protected by a mutex. > the code is refactored so the IFQ macros call newly implemented ifq > functions. the ifq code is split so each discipline (priq and hfsc > in our case) is an opaque set of operations that the common ifq > code can call. the common code does the locking, accounting (ifq_len > manipulation), and freeing of the mbuf if the disciplines enqueue > function rejects it. theyre kind of like bufqs in the block layer > with their fifo and nscan disciplines. > the new api also supports atomic switching of disciplines at runtime. > the hfsc setup in pf_ioctl.c has been tweaked to build a complete > hfsc_if structure which it attaches to the send queue in a single > operation, rather than attaching to the interface up front and > building up a list of queues. > the send queue is now mutexed, which raises the expectation that > packets can be enqueued or purged on one cpu while another cpu is > dequeueing them in a driver for transmission. a lot of drivers use > IFQ_POLL to peek at an mbuf and attempt to fit it on the ring before > committing to it with a later IFQ_DEQUEUE operation. if the mbuf > gets freed in between the POLL and DEQUEUE operations, fireworks > will ensue. > to avoid this, the ifq api introduces ifq_deq_begin, ifq_deq_rollback, > and ifq_deq_commit. ifq_deq_begin allows a driver to take the ifq > mutex and get a reference to the mbuf they wish to try and tx. if > there's space, they can ifq_deq_commit it to remove the mbuf and > release the mutex. if there's no space, ifq_deq_rollback simply > releases the mutex. this api was developed to make updating the > drivers using IFQ_POLL easy, instead of having to do significant > semantic changes to avoid POLL that we cannot test on all the > hardware. > the common code has been tested pretty hard, and all the driver > modifications are straightforward except for de(4). if that breaks > it can be dealt with later. > ok mpi@ jmatthew@ (dlg@) dev/usb ~ if_aue.c ~ if_axe.c ~ if_axen.c ~ if_cdce.c ~ if_cdcef.c ~ if_cue.c ~ if_kue.c ~ if_mos.c ~ if_smsc.c ~ if_udav.c ~ if_ugl.c ~ if_upl.c ~ if_url.c ~ if_urndis.c > shuffle struct ifqueue so in flight mbufs are protected by a mutex. > the code is refactored so the IFQ macros call newly implemented ifq > functions. the ifq code is split so each discipline (priq and hfsc > in our case) is an opaque set of operations that the common ifq > code can call. the common code does the locking, accounting (ifq_len > manipulation), and freeing of the mbuf if the disciplines enqueue > function rejects it. theyre kind of like bufqs in the block layer > with their fifo and nscan disciplines. > the new api also supports atomic switching of disciplines at runtime. > the hfsc setup in pf_ioctl.c has been tweaked to build a complete > hfsc_if structure which it attaches to the send queue in a single > operation, rather than attaching to the interface up front and > building up a list of queues. > the send queue is now mutexed, which raises the expectation that > packets can be enqueued or purged on one cpu while another cpu is > dequeueing them in a driver for transmission. a lot of drivers use > IFQ_POLL to peek at an mbuf and attempt to fit it on the ring before > committing to it with a later IFQ_DEQUEUE operation. if the mbuf > gets freed in between the POLL and DEQUEUE operations, fireworks > will ensue. > to avoid this, the ifq api introduces ifq_deq_begin, ifq_deq_rollback, > and ifq_deq_commit. ifq_deq_begin allows a driver to take the ifq > mutex and get a reference to the mbuf they wish to try and tx. if > there's space, they can ifq_deq_commit it to remove the mbuf and > release the mutex. if there's no space, ifq_deq_rollback simply > releases the mutex. this api was developed to make updating the > drivers using IFQ_POLL easy, instead of having to do significant > semantic changes to avoid POLL that we cannot test on all the > hardware. > the common code has been tested pretty hard, and all the driver > modifications are straightforward except for de(4). if that breaks > it can be dealt with later. > ok mpi@ jmatthew@ (dlg@) kern ~ vfs_syscalls.c > Fix whitespace. No binary change. (jsg@) ~ vfs_syscalls.c > VISTTY check in revoke() is not working well for the non-indirected > /dev/console case, so go back to doing the direct D_TTY check. > signed over a few times with guenther (deraadt@) ~ kern_pledge.c ~ uipc_syscalls.c > Exempt accept(2) from the pledge_socket() check part of the "domain" > check. You cannot open a socket in a domain unless permitted -- but > you need to be able to accept one if the code flow asks for that to > happen. The most recent check is too tight. We may need to iterate the > policy here until we hit the right vibe... (deraadt@) ~ kern_pledge.c > Add pledge "disklabel", which allows sysctl kern.rawpartition, a > few disklabel ioctls, and the DIOCMAP ioctl against /dev/diskmap used > to translate duid numbers into partitions. > This will allow pledging of at least 12 disk/filesystem aware > programs; due to the negative impact that diff will wait a bit so > everyone has a chance to update their kernels. > ok semarie (deraadt@) ~ kern_pledge.c > Permit msync(2) in the "stdio" set; only a few programs use it related > to mmap, but thinking about it nothing feels risky > Long discussions with florian (deraadt@) ~ uipc_syscalls.c > Neuter the pledge domain checking for listen, getpeername, and getsockname > also. The idea is much like rpath is with files, you get an fd and then > you can play with it somewhat. In the socket space once you have a fd, you > can play with it somewhat. So you cannot bind, but you can accept. You > can listen, getpeername, getsockname, and of course set/getsockopt is > somewhat available.. yes, this makes pledge the anti-capsicum, kind of > like salt from Secovlje.. reasoning due to a conversation with tedu > (deraadt@) net ~ hfsc.c ~ hfsc.h ~ if.c ~ if_tun.c ~ if_var.h ~ pf_ioctl.c ~ pfvar.h ~ pf_if.c > shuffle struct ifqueue so in flight mbufs are protected by a mutex. > the code is refactored so the IFQ macros call newly implemented ifq > functions. the ifq code is split so each discipline (priq and hfsc > in our case) is an opaque set of operations that the common ifq > code can call. the common code does the locking, accounting (ifq_len > manipulation), and freeing of the mbuf if the disciplines enqueue > function rejects it. theyre kind of like bufqs in the block layer > with their fifo and nscan disciplines. > the new api also supports atomic switching of disciplines at runtime. > the hfsc setup in pf_ioctl.c has been tweaked to build a complete > hfsc_if structure which it attaches to the send queue in a single > operation, rather than attaching to the interface up front and > building up a list of queues. > the send queue is now mutexed, which raises the expectation that > packets can be enqueued or purged on one cpu while another cpu is > dequeueing them in a driver for transmission. a lot of drivers use > IFQ_POLL to peek at an mbuf and attempt to fit it on the ring before > committing to it with a later IFQ_DEQUEUE operation. if the mbuf > gets freed in between the POLL and DEQUEUE operations, fireworks > will ensue. > to avoid this, the ifq api introduces ifq_deq_begin, ifq_deq_rollback, > and ifq_deq_commit. ifq_deq_begin allows a driver to take the ifq > mutex and get a reference to the mbuf they wish to try and tx. if > there's space, they can ifq_deq_commit it to remove the mbuf and > release the mutex. if there's no space, ifq_deq_rollback simply > releases the mutex. this api was developed to make updating the > drivers using IFQ_POLL easy, instead of having to do significant > semantic changes to avoid POLL that we cannot test on all the > hardware. > the common code has been tested pretty hard, and all the driver > modifications are straightforward except for de(4). if that breaks > it can be dealt with later. > ok mpi@ jmatthew@ (dlg@) ~ if_tun.c > if we deq m0, we should probably send it to bpf, not m. > found by and ok jsg@ (dlg@) ~ if_gif.c > dont check for OACTIVE > only a driver sets or clears this flag. gif never sets it, so it > wont be set when it checks it. (dlg@) ~ if_pppx.c > dont check for IFF_OACTIVE > only a driver sets or clears this flag. pppx never sets it, so it > will never be set when it checks it. (dlg@) ~ if_trunk.c > dont play with IFF_OACTIVE needlessly. > only a driver sets or clears it, and trunk never sets it. therefore it > never needs to clear it. (dlg@) ~ if_tun.c > dont needlessly clear IFF_OACTIVE. > only a driver sets or clears OACTIVE. clearing it without setting it is > a waste of time. (dlg@) ~ if_ppp.c > correctly indent a line to make the intent clear > ok dlg@ (jsg@) ~ if.c > fix prio KASSERT, it should be <= not <. ok dlg@ (sthen@) ~ pf.c > Make use if_get() and get rid of rt_ifp. > While here keep carp(4) bits under NCARP. > Tested by and ok sthen@, ok visa@ (mpi@) ~ if.c ~ if_var.h > i made a mistake. rename ifq_enq and ifq_deq to ifq_enqueue and ifq_dequeue > fixing it now before i regret it more. (dlg@) ~ if_spppsubr.c > avoid a use after enqueue, which is like a use after free. > once you enqueue an mbuf, you no longer own it. therefore you cant > read the length out of it. this reads the length first, then tries > to enq it. > also, call if_start instead of a bare call to the underlying start > routine. > ok mpi@ sthen@ (dlg@) ~ if_spppsubr.c ~ if_pppoe.c > sppp(4) is now only used for pppoe(4) which doesn't use framing, so remove > support for sppp with framing, simplifying things. Remove unused ifdefs > while > there. > "sppp will go away before it gets used for something else" dlg@ (sthen@) ~ if_tun.c > Prefer if_get() over if_ref() when checking if the interface has been > destroyed during our sleep. > No objection from the slackers. (mpi@) ~ if.c ~ if.h > Keep if_ref() private, if_get() is what you want to use before if_put(). > The thread detaching an interface will sleep until all references to this > interface have been released. So we decided to only keep references for > a short period of time. > Keeping if_ref() private will hopefully help preserve this goal as long > as it makes sense. > Calling if_get()/if_put() in the same function also allows us to make > use of static analysis tools (thanks jsg@!) to catch our errors. > ok dlg@ (mpi@) ~ route.c > Initialise the ifidx to 0 (no interface) in rtredirect() to avoid using > ifidx uninitialised for the gateway not directly reachable case. > ok mpi@ (jsg@) netinet ~ tcp_input.c > Make use if_get() and get rid of rt_ifp. > Tested by and ok sthen@, ok visa@ (mpi@) ~ if_ether.c > Fewer uses of rt_ifp. > Tested by and ok sthen@, (mpi@) ~ if_ether.c > This no longer depends on bridge.h, fewer "#ifdef NBRIDGE", say yeah! > (mpi@) sys ~ mbuf.h > shuffle struct ifqueue so in flight mbufs are protected by a mutex. > the code is refactored so the IFQ macros call newly implemented ifq > functions. the ifq code is split so each discipline (priq and hfsc > in our case) is an opaque set of operations that the common ifq > code can call. the common code does the locking, accounting (ifq_len > manipulation), and freeing of the mbuf if the disciplines enqueue > function rejects it. theyre kind of like bufqs in the block layer > with their fifo and nscan disciplines. > the new api also supports atomic switching of disciplines at runtime. > the hfsc setup in pf_ioctl.c has been tweaked to build a complete > hfsc_if structure which it attaches to the send queue in a single > operation, rather than attaching to the interface up front and > building up a list of queues. > the send queue is now mutexed, which raises the expectation that > packets can be enqueued or purged on one cpu while another cpu is > dequeueing them in a driver for transmission. a lot of drivers use > IFQ_POLL to peek at an mbuf and attempt to fit it on the ring before > committing to it with a later IFQ_DEQUEUE operation. if the mbuf > gets freed in between the POLL and DEQUEUE operations, fireworks > will ensue. > to avoid this, the ifq api introduces ifq_deq_begin, ifq_deq_rollback, > and ifq_deq_commit. ifq_deq_begin allows a driver to take the ifq > mutex and get a reference to the mbuf they wish to try and tx. if > there's space, they can ifq_deq_commit it to remove the mbuf and > release the mutex. if there's no space, ifq_deq_rollback simply > releases the mutex. this api was developed to make updating the > drivers using IFQ_POLL easy, instead of having to do significant > semantic changes to avoid POLL that we cannot test on all the > hardware. > the common code has been tested pretty hard, and all the driver > modifications are straightforward except for de(4). if that breaks > it can be dealt with later. > ok mpi@ jmatthew@ (dlg@) ~ pledge.h > Add pledge "disklabel", which allows sysctl kern.rawpartition, a > few disklabel ioctls, and the DIOCMAP ioctl against /dev/diskmap used > to translate duid numbers into partitions. > This will allow pledging of at least 12 disk/filesystem aware > programs; due to the negative impact that diff will wait a bit so > everyone has a chance to update their kernels. > ok semarie (deraadt@) == usr.bin =========================================================== 11/12 == http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin less ~ main.c > spaces (deraadt@) ~ screen.c > wrapping an ioctl for TIOCGWINSZ inside #ifdef TIOCGWINSIZE (entirely > different) makes no sense; instead, accept all modern systems have > TIOCGWINSZ. (deraadt@) lex ~ scanopt.c > Cast two ctype args to u_char. (mmcc@) ~ main.c > Always use the system m4. (millert@) ~ main.c > Back out rev 1.22 which somehow had unreported merge conflicts. (millert@) ~ main.c > Always use the system m4; OK tedu@ (millert@) ~ buf.c ~ ecs.c > ansi (tedu@) ~ Makefile > switch back to yaccing parse.y, it seems to work. (tedu@) mandoc ~ main.c ~ tag.c ~ tag.h > Fix multiple issues regarding process group and signal mask handling > found by tb@ and millert@; parts of the code, in particular in tag.c, > by millert@; OK millert@. (schwarze@) openssl ~ certhash.c > do not need sys/param.h (deraadt@) skeyinit ~ skeyinit.c > pledge "stdio rpath wpath cpath fattr flock tty" > ok millert (deraadt@) ssh ~ sshconnect.c > add cast to make -Werror clean (djm@) ~ ssh-keygen.c > allow comment change for all supported formats > ok djm@ (halex@) tail ~ forward.c > quick hack to fix "tail +n", reported broken by Mikolaj Kucharski. > this doesn't attempt to repair all cases, but restoring basic functionality > is a first step. (tedu@) telnet ~ commands.c > Replace hardcoded "2" with SHUT_RDWR; from Ricardo Mestre (jca@) tmux ~ cmd-set-option.c ~ cmd-show-options.c ~ options-table.c ~ status.c ~ tmux.c ~ tmux.h > Instead of separate tables for different types of options, give each > option a scope type (server, session, window) in one table. (nicm@) ~ alerts.c > The alerts callback should be fired for bells even if bell-action is > none because it also affects the status line bell indicator (and > bell-action does not). Fixes a problem reported by tim@. (nicm@) ~ cmd-if-shell.c ~ cmd-new-window.c ~ utf8.c > Memory leaks and an uninitialized part of utf8_data, from Patrick Palka. > (nicm@) vi ~ common/main.c > vi -S doesn't need proc or exec. > ok tb@ (bentley@) == usr.sbin ========================================================== 12/12 == http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.sbin bgpd ~ bgpd.c ~ session.c > bgpd has been naughty. It tries to play with AF_UNIX sockets without > pledging "unix". > Move control_listen up to the main process which already has > pledge("unix"). accept(2) was already allowed. > (Technically no longer necessary since listen(2) is now allowed, too, > but this moves it to the right place.) > OK claudio@, deraadt@ (florian@) ntpd ~ Makefile ~ control.c > use RMS for jitter. we're linking with enough libraries that libm is tiny. > ok deraadt (tedu@) rpc.bootparamd ~ bootparamd.c > KNF (deraadt@) slowcgi ~ slowcgi.c > typo in error message: to -> too > ok florian@ (tb@) trpt ~ trpt.c > Appears to only need pledge "stdio" against open kvm (deraadt@) =============================================================================== _______________________________________________ odc mailing list [email protected] http://www.squish.net/mailman/listinfo/odc
