CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2024/11/03 19:44:29 Modified files: sbin/iked : iked.conf.5 iked.h ikev2.c parse.y print.c Log message: add a "natt" option that forces negotiation of nat-t (and udpencap). this is like the -t command line option on iked itself, but you get to keep the ike listener on port 500 and you can enable this on specific policies instead of all of them. this is useful if you're dealing with an org that can't firewall ESP traffic well and so you need to force the traffic to be udp encapsulated even if there's no NAT involved. ok markus@ tobhe@
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2024/10/30 23:00:00 Modified files: sys/uvm: uvm_map.c uvm_map.h Log message: try to simplify the locking code around busy maps. this is src/sys/uvm/uvm_map.c r1.331 again with a small fix to pass the right mutex to msleep when waiting for the busy proc pointer. vm_maps have a "feature" where they can mark that they're being operated on by a specific proc, and then release the rwlock protecting their state. to relock, you have to be the same proc that marked it busy. this diff tries to simplify it a bit. it basically has threads check the busy field up front and rechecks the busy field inside the rwlock. if you can sleep, it will sleep up front for the busy field to become clear, rather than sleep on either the busy field or the rwlock. some code paths clear the busy field without holding the rwlock, so it doesn't make sense to me to be waiting for the busy field but sleeping somewhere else. ok claudio@
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2024/10/29 17:57:54 Modified files: sys/net: hfsc.c Log message: move hfsc to using nanoseconds for keeping times. before it was using 25600 things per second, so this isn't a huge change, but it can use nsecuptime() to get the time. kjc and cheloa like it ok claudio@
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2024/10/29 17:25:45 Modified files: sys/net: fq_codel.c Log message: use nsecuptime instead of using nanouptime and doing a bunch of maths. ok claudio@
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2024/10/21 00:07:33 Modified files: sys/uvm: uvm_map.c uvm_map.h Log message: revert "try to simplify the locking code around busy maps" anton@ and syzkaller have trouble with it.
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2024/10/20 05:28:17 Modified files: sys/uvm: uvm_map.c uvm_map.h Log message: try to simplify the locking code around busy maps. vm_maps have a "feature" where they can mark that they're being operated on by a specific proc, and then release the rwlock protecting their state. to relock, you have to be the same proc that marked it busy. this diff tries to simplify it a bit. it basically has threads check the busy field up front and rechecks the busy field inside the rwlock. if you can sleep, it will sleep up front for the busy field to become clear, rather than sleep on either the busy field or the rwlock. some code paths clear the busy field without holding the rwlock, so it doesn't make sense to me to be waiting for the busy field but sleeping somewhere else. ok claudio@ mpi@
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2024/10/17 16:44:17 Modified files: sys/kern : vfs_subr.c Log message: use rw_status instead of interpreting RWL_OWNER to see if a lock is busy. ok claudio@
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2024/10/17 02:22:53 Modified files: sys/dev/pci: pcidevs.h pcidevs_data.h Log message: regen
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2024/10/17 02:22:34 Modified files: sys/dev/pci: pcidevs Log message: Kingston SNV2S nvme device
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2024/10/17 02:21:51 Modified files: sys/dev/pci: pcidevs.h pcidevs_data.h Log message: regen
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2024/10/17 02:21:23 Modified files: sys/dev/pci: pcidevs Log message: ampere altra pci ports
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2024/10/16 05:12:31 Modified files: sys/net: if_tun.c Log message: cut tun_init() out, it does pointless work. tun_init turns interface/stack config into a set of flags that tun(4) keeps in tun_softc sc_flags, but never uses. ok miod@ kn@
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2024/10/16 05:03:55 Modified files: sys/net: if_tun.c Log message: remove SIOCSIFDSTADDR from the network ioctls. netintro says it's deprecated, and most of our other drivers are doing fine without it. ok miod@ kn@ patrick@
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2024/10/10 00:50:58 Modified files: sys/net: if_tun.c Log message: neuter the tun/tap ioctls that try and modify interface flags. historically there was just tun(4) that supported both layer 3 p2p and ethernet modes, but had to be reconfigured at runtime by userland to properly change the interface type and interface flags. this is obviously not a great idea, mostly because a lot of stack behaviour around address management makes assumptions based on these parameters, and changing them at runtime confuses things. splitting tun so ethernet was handled by a specific tap(4) driver was a first step at locking this down. this takes a further step by restricting userlands ability to reconfigure the interface flags, specifically IFF_BROADCAST, IFF_MULTICAST, and IFF_POINTOPOINT. this change lets userland pass those values via the ioctls, but only if they match the current set of flags on the interface. these flags are set appropriate for the type of interface when it's created, but should not be changed afterwards. nothing in base uses these ioctls, so the only fall out will be from ports doing weird things. ok claudio@ kn@
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2024/09/19 19:15:53 Modified files: share/man/man4 : sec.4 Log message: fix up the ip address config in the example config. you're supposed to configure the IP addresses inside the tunnel, sec doesn't support configuration of the tunnel endpoint addresses because that's handled by SAs via ike config. hit by Luca Di Gregorio on misc@
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2024/09/04 17:57:20 Modified files: sys/dev/pci: pcidevs.h pcidevs_data.h Log message: regen
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2024/09/04 17:56:43 Modified files: sys/dev/pci: pcidevs Log message: add PLX PEX 8718 and SK hynix PC601 devices. The PEX 8718 is used on a QNAP QM2-2P-something card, and we have a couple of pc601 nvme ssds plugged into it.
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2024/08/30 22:21:45 Modified files: share/man/man4 : Makefile Added files: share/man/man4 : rport.4 Log message: rport(4) for p2p l3 connectivity between route domains.
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2024/08/30 22:17:14 Modified files: sys/conf : GENERIC files Added files: sys/net: if_rport.c Log message: add rport(4) for p2p l3 connectivity between route domains. you can basically plug rdomains together and route between them over rport interfaces. people keep asking me if this is so you can leak routes between rdomains, and the answer is yes. this is like pair(4) but cheaper because it avoids all the mucking around with putting an ethernet header on the mbuf just to take it off again later, and is more efficient with address space because it's a p2p ip interface. it has a small tweak from mvs@ ok denis@ claudio@
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2024/08/30 18:51:29 Modified files: share/man/man4 : sec.4 Log message: provide an example config for ikev1 with isakmpd and ipsecctl
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2024/08/30 03:39:07 Modified files: share/man/man4 : etherip.4 Log message: tweak the example to use veb instead of bridge.
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2024/08/30 02:38:00 Modified files: share/man/man4 : etherip.4 Log message: try and keep in line with language used in other manual pages. while i'm here, try and unbundle some of the configuration and concepts. etherip interfaces can work fine as point to point ethernet tunnels, they do not need to be configured as part of bridge(4) to work. ipsec can be configured to protect etherip traffic independently of whether it's part of a bridge too.
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2024/08/30 01:25:55 Modified files: share/man/man4 : etherip.4 Log message: prefer "IPv4 and IPv6" over "IP[46]".
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2024/08/20 19:17:50 Modified files: sys/dev/pci: if_rge.c Log message: use 2k clusters on the rx ring instead of 9k clusters. rge can chain mbufs from multiple rx descriptors together to build a jumbo packet. 1514 byte packets are still the most common, so avoiding the waste of most of a 9k cluster if we can still makes sense.
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2024/08/20 19:12:52 Modified files: sys/dev/pci: if_rge.c if_rgereg.h Log message: support building a single packet out of multiple rx descriptors. rge is a bit like intel nics where you can put small mbufs on the rx ring and it will chain them together to make a jumbo packet. except unlike intel you can use any sized mbufs for the rx descriptors. this adds the handling of these packets to the rx path. we're still putting 9k frames on the ring though.
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2024/08/20 18:56:58 Modified files: sys/dev/pci: if_rge.c Log message: be more careful about bus_dmamap_syncs for rx ring descriptors. this is very similar to the changes made for tx where we fill in everything except the OWN flag on the rx descriptor, call bus_dmamap_sync as a barrier for the hw, and then flip the ownership of the OWN bit. this avoids the potential for the hw to see the own bit before other things in the descriptor, such as the address and length of the buffer. while here, trim code that's not currently used. we don't currently support rxing one packet by assembling buffers from multiple descriptors, so stop fiddling with the queue mbuf head and tail pointers. delete rge_discard_rxbuf() cos it looks like a leftover from code which tries to reuse mbufs on the rx ring. we free mbufs when there's an error and let the rxr stuff refill. ok patrick@ no objections from kevlo@
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2024/08/19 18:09:12 Modified files: sys/dev/pci: if_rge.c if_rgereg.h Log message: rework rge tx start and completion to better bus_dmamap_sync tx descriptors ok patrick@ thanks to kettenis@ for reminding me how computers work again.
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2024/08/15 06:20:20 Modified files: share/man/man4 : bpf.4 sys/net: bpf.c bpf.h bpfdesc.h Log message: add BIOCSETFNR, which is like BIOCSETF but doesnt reset the buffer or stats. from Matthew Luckie via tech@ deraadt@ likes it.
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2024/08/12 00:47:11 Modified files: sys/dev/pci: if_rge.c sys/dev/ic : re.c Log message: try harder to leave a gap on the tx ring. i think before this change we could overwrite entries on the ring, which can confuse the chip and the tx completion code. i think. it's funny how much a comparison hurts my brain. ok patrick@ tested by and ok kevlo@
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2024/08/10 19:02:10 Modified files: sys/dev/pci: if_igc.c Log message: unbreak igc on strict alignment archs. igc (like other intel nics) only supports a limited range of rx buffer sizes, one of which is 2k like our standard mbuf clusters. however they put the ethernet packet at the start of the provided rx buffer, which means the ip header is misaligned on strict alignment archs if we use the standard 2k mbuf clusters. to avoid wasting too much memory using the next biggest cluster (4k) we have mcl2k2 clusters that pretty much exists for intel nics to use. igc (and probably some other drivers ive touched) was too clever about using mcl2k2 though, which caused panics when trying to use jumbo packets. jan@ fixed this by moving back to 2k clusters, but that broke sparc64 (and probably powerpc64). this dumbs the mcl2k2 handling down a bit so jumbos still work, but adds ETHER_ALIGN back so strict alignment archs also work again. ok bluhm@
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2024/08/10 18:50:38 Modified files: share/man/man9 : timeout.9 Log message: timeout_add_msec and timeout_add_usec take uint64_t now.
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2024/08/10 18:49:34 Modified files: sys/sys: timeout.h sys/kern : kern_timeout.c Log message: make the timeout_add_foo wrappers more consistent. take uint64_t as the arg type for timeout_add_msec and timeout_add_usec like we do for timeout_add_nsec now. always calculate ticks using uint64_t, and factor out the range checks on the resulting ticks value so it's done consistently. ok claudio@
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2024/08/05 17:52:03 Modified files: share/man/man9 : timeout.9 Log message: timeout_add_nsec takes a uint64_t now.
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2024/08/05 17:51:11 Modified files: sys/kern : kern_timeout.c sys/sys: timeout.h Log message: change the nsec argument to timeout_add_nsec from int to uint64_t you can only fit a couple of nanonseconds into an int, which limited the usefulness of the api. worse, if a large nsec value was passed in it could be cast to a negative int value which tripped over a KASSERT at the top of timeout_add that ends up being called. avoid this footgun by working in the bigger type and doing the same range checks/fixes for other timeout_add wrappers. ok claudio@ mvs@
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2024/07/31 06:00:18 Modified files: usr.bin/ssh: sshd-session.c Log message: add a random amount of time (up to 4 seconds) to the grace login time. ok deraadt@ djm@
CVS: cvs.openbsd.org: www
CVSROOT:/cvs Module name:www Changes by: d...@cvs.openbsd.org2024/07/23 02:43:30 Modified files: faq: faq16.html Log message: update bridging vms with the real network to use veb and vport. this makes it more likely that dhcp will work. ok florian@
CVS: cvs.openbsd.org: www
CVSROOT:/cvs Module name:www Changes by: d...@cvs.openbsd.org2024/07/13 17:38:52 Modified files: faq: faq16.html Log message: Option 3 sets up a vport instead of a vether now, so run dhcpd on vport0
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2024/05/05 22:25:52 Modified files: sys/dev/pci: igc_regs.h if_igc.c if_igc.h Log message: expose hardware counters as kstats. igc(4) counters are read to clear like em(4) counters, so this code looks very much like em(4) but with less quirks so far. ok bluhm@ bket@
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2024/03/25 18:54:24 Modified files: usr.bin/kstat : kstat.c Log message: print amps and watts
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2024/03/25 18:53:51 Modified files: sys/sys: kstat.h Log message: amps and watts types volts felt lonely
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2024/03/18 21:49:11 Modified files: sys/net: if_sec.c Log message: count if_enqueue/ifq_enqueue errors as oqdrops. this helps narrow down where some "output failures" on sec interfaces occur. based on discussion with jason tubnor
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2024/03/18 00:14:50 Modified files: sys/net: if_aggr.c Log message: expose per port information via kstats. the most interesting information exposed here is the number of times a port changes state according to the lacp state machine. if a port is flapping, it's hard to see if you only look at the current state. getting a count of changes over time makes problems a lot more visible and therefore fixable. this also exposes counters around how the lacp protocol packets. all of these can be useful when trying to line up behaviors with another system (eg, a switch). ok jmatthew@
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2024/03/18 00:05:23 Modified files: sys/net: if_aggr.c Log message: use high bits from the mbuf flowid to pick a port to transmit on. a port here is a physical interface used by an aggr. this leaves the low bits for a physical interface to use to pick a tx ring. without this, aggr used low bits for port selection, which takes bits away from the ring selection, which can lead to uneven distribution of packets over tx rings. ive been running this in production for well over a year now.
CVS: cvs.openbsd.org: www
CVSROOT:/cvs Module name:www Changes by: d...@cvs.openbsd.org2024/03/11 04:57:38 Modified files: . : want.html Log message: i've got an r6c now, thank you
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2024/03/03 21:44:12 Modified files: sys/net: if_aggr.c Log message: white space fixes. no functional change
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2024/02/20 21:26:45 Modified files: sys/arch/riscv64/riscv64: machdep.c Log message: revert r1.35 i dont know what i'm doing wrong with the handling of the no-map property, but i'll find some coffee and time and figure it out soon hopefully.
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2024/02/20 18:45:14 Modified files: sys/arch/riscv64/riscv64: machdep.c sys/arch/arm64/arm64: machdep.c Log message: handle /reserved-memory nodes from device trees on arm64. u-boot is supposed to take these entries and put them in the efi memory map, but i keep hitting machines where an otherwise functional u-boot does not do this, resulting in weird errors. i have an espressobin with a vendor u-boot that has a reserved-memory region for psci. without this diff the machine faults when the kernel tries to reboot using a psci handler. a macchiatobin with an otherwise working u-boot throws SErrors or panics on weird memory corruption problems without this. i thought it was bad RAM, but the problems persisted with completely different ram, and very underclocked and well cooled ram. riscv64 already has code to handle reserved-memory regions. the riscv64 change is to add handling for the "no-map" property. ok kettenis@
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2024/01/23 17:17:01 Modified files: sys/net: if_sec.c Log message: tag packets going out a sec interface to prevent route/encap loops. sec(4) was already looking for this mbuf tag so it could drop packets that had already been sent out on the same interface, but i forgot the code that adds the tag. this was reported by jason tubnor who experienced spins/lockups when using sec and a physical interface was disconnected. rather than being a locking problem like we initially assumed, it turned out that unplugging a physical interface caused a route for ipsec encapsulated traffic to go out over sec(4), causing the packet to loop in the stack. the fix was also tested and verified by jason. sorry for taking so long to look at it.
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2024/01/18 20:46:15 Modified files: sys/dev/ic : re.c revar.h sys/dev/pci: if_re_pci.c sys/dev/cardbus: if_re_cardbus.c Log message: consolidate pci and cardbus detach code, and have it detach kstats. this solves one probably with an re(4) going away.
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2023/11/23 16:45:10 Modified files: sys/net: if_veb.c Log message: avoid passing weird mbuf chains to pf when pushing out a veb. pf expects the ip header to be in the first mbuf of the chain we pass to pf_test, but in some situations the ethernet header is the only data in the first mbuf. after we remove the ethernet header, the first mbuf had no data in it which confused pf. fix this by passing all packets to ip_check on output as well as input. ip input handlers do all the necessary m_pullups. found by Mark Patruck.
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2023/11/22 20:38:34 Modified files: sbin/ifconfig : brconfig.c ifconfig.c ifconfig.h Log message: add an endpoint command for "bridges" that use addresses as endpoints. this can be used to add static entries on interfaces like vxlan(4).
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2023/11/22 20:36:42 Modified files: share/man/man4 : vxlan.4 Log message: non-standard vxlan port is set on the tunnel src address
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2023/11/22 20:22:14 Modified files: sbin/ifconfig : ifconfig.c Log message: add support for specifying ports on the src address in tunnel endpoints.
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2023/11/22 18:00:44 Modified files: sys/arch/arm64/arm64: cpu.c Log message: provide operating performance point info about each cpu via kstats. if there's a device tree and it provides information about cpu speed, expose those stats. this is particularly useful on big.little or systems with multiple clusters/clock domains or cores that can scale indepenently because it can report the actual speed each cpu is operating at independently. ok patrick@ who used an earlier version of this diff to work on cpu scaling on an rk3588 system.
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2023/11/22 17:47:13 Modified files: sys/dev/ofw: ofw_thermal.c Log message: expose the state of thermal zones as kstats. this makes it a bit more obvious how much head room you have for things like cpu performance scaling. the information provided at the moment is more useful for developers working on cpu scaling, but it should improve as i get my head around more of these things. patrick@ and kettenis@ like the idea.
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2023/11/17 17:23:38 Modified files: sys/net: if_vxlan.c Log message: ports specified on tunnel destination addresses are invalid.
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2023/11/15 20:17:34 Modified files: usr.bin/kstat : kstat.c Log message: avoid reading data when enumerating kstats. this means we can reliably read the provider/instance/name/unit tuple, which should avoid "duplicate kstat entry" when multiple kstat read handlers have issues. found on a box with multiple rge interfaces, which have hardware backed kstats that can only be read when the interface is up.
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2023/11/15 19:45:54 Modified files: usr.bin/kstat : kstat.c Log message: handle printing cpu freq and volt kstat_kv types
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2023/11/15 19:45:20 Modified files: sys/sys: kstat.h Log message: cpu frequency and volt types for kstat_kvs
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2023/11/15 16:57:45 Modified files: sys/dev: bio.c Log message: use a random number as the cookie in bio ioctls. ok kn@ krw@
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2023/11/12 08:42:54 Modified files: sys/net: route.h Log message: rt_gateway and rt_gwroute use X protections now. pointed out by bluhm@
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2023/11/12 08:42:05 Modified files: sys/net: route.c Log message: rt_setgate performs a series of tweaks to an rtable and the routes in the rtable which should be serialised to ensure they're consistent. unfortunately, rt_setgate is called from the network stack while it's only holding shared NET_LOCK. this uses the [X] protections as described in route.h to serialise the changes, and reworks the code to try and keep enough stuff linked up properly during the changes that it will still work if another cpu is still using the rtentry structs while they still have shared net lock. tested by and ok bluhm@
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2023/11/12 08:18:04 Modified files: sbin/pflogd: pflogd.c Log message: fix the signal numbers passed to siginterrupt. from dhill@
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2023/11/12 02:21:36 Modified files: share/man/man4 : wscons.4 Log message: the ws in wscons is short for workstation
CVS: cvs.openbsd.org: www
CVSROOT:/cvs Module name:www Changes by: d...@cvs.openbsd.org2023/11/11 12:07:11 Modified files: . : want.html Log message: a nanopi r6c woudl be useful for rk3588 development
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2023/11/11 05:52:20 Modified files: sys/net: route.h Log message: start documenting the protections or locks needed for struct rtentry fields. this is the result of a bunch of discussion at h2k23. ok claudio@ mvs@ bluhm@
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2023/11/09 11:36:19 Modified files: sbin/pflogd: pflogd.c Log message: avoid restartable syscalls with siginterrupt() against all our handlers. pflogd uses blocking bpf reads, but installs a bunch of signal handlers to handle cleanly closing and (re)opening the log file. signal() by default sets the handlers up so they're restartable. this has the effect that when pflogd receives a signal while waiting in bpfread, the signal handler runs and sets a flag saying the file should be rotated or closed or whatever, but then the kernel restarts the read. when pflogd used a bpf read timeout, pflogd would run it's "event" loop every time the read timeout expired. this meant even though the bpf read was restarted, by having the read timeout expire every 500ms the flag the signal handlers set would be processed in a relatively short period of time. after moving bpf to a wait timeout, pflogd basically has to wait for a packet to be captured before the bpf read will return. if you're trying to kill pflogd on an idle firewall then you're basically stuck. making the signal handlers not restartable allows bpfread to fail with EINTR so pflogd can go around it's even loop and exit as expected. reported by Mikhail on bugs@ ok claudio@ pflogd needs a rewrite though.
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2023/11/09 07:07:18 Modified files: sys/dev: bio.c Log message: get rid of the ioctl whitelist that bio will tunnel for other devs. this will allow bio(4) to be used with other (non raid) related devices. ok krw@ kn@
CVS: cvs.openbsd.org: www
CVSROOT:/cvs Module name:www Changes by: d...@cvs.openbsd.org2023/10/23 00:25:49 Modified files: . : want.html Log message: i have a RB450Gx4 now.
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2023/08/29 17:28:38 Modified files: sys/dev/usb: if_umb.c Log message: fix handling of unknown error rate in mbim signal state info from gerhard@: > According to MBIM spec, table 10-58 (MBIM_SIGNAL_STATE_INFO) a value > of 99 means the error rate is "Unknown or undetectable". the code was using -99 before, but properly reports unknown/null now.
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2023/08/29 17:26:40 Modified files: sys/dev/usb: if_umb.c if_umb.h Log message: export mbim signal stats tested by mbuhl@ gerhard@
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2023/08/26 05:33:46 Modified files: sys/dev/usb: if_umb.c Log message: umb can use p2p_input as an if_input handler. umb(4) is a hardware p2p driver, it just has ip coming in, so we can do the same thing we do for the address family and input processing as other p2p interfaces. the short packet check that umb_input does is already done by the ip stacks, so we're not losing anything. tested by gerhard@ mbuhl@ ok gerhard@
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2023/08/15 03:46:30 Modified files: sys/net: if_sec.c Log message: scrub the mbuf flowid for packets going out a sec interface. maybe ipsec should do this for all packets it encapsulates. tested by hrvoje
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2023/08/14 20:31:07 Modified files: sys/net: if_sec.c Log message: sec_start needs to show bpf the packets going out. from and ok goda@ requested by many
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2023/08/10 20:35:38 Modified files: sys/conf : GENERIC Log message: enable sec(4) so people can try it out
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2023/08/10 20:34:56 Modified files: sys/net: if_sec.c Log message: better support queuing (hfsc) on sec(4)
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2023/08/08 04:31:03 Modified files: sbin/isakmpd : isakmpd.conf.5 Log message: have a go at documenting the Interface config statement. im not really happy with this, but it's a start.
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2023/08/08 04:19:15 Modified files: sys/net: if_sec.c Log message: if sec is being destroyed, prevent it from being brought up again.
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2023/08/08 04:14:29 Modified files: sys/net: if_sec.c Log message: try to avoid a deadlock between sec_down and sec_send. sec_send runs in the systq (because it calls ipsec stuff which uses crypto, which is not mpsafe) and takes the net lock (because ipsec output calls ip_output and other stuff). sec_down is called with NET_LOCK held and tries to run a barrier for send task. if the send task is running but is waiting for the net lock while sec_down is holding the net lock while waiting for the task to finish, we're deadlocked. this copies the sc_up thing from pfsync, which hopefuly avoids this. pointed out by mvs@
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2023/08/06 22:10:08 Modified files: sbin/ipsecctl : ike.c ipsecctl.h parse.y pfkdump.c Log message: add support route based ipsec vpn negotiation with sec(4) via isakmpd. this adds "interface secX" to the grammar that you can use instead of specifying tunnel/transport modes and traffic selectors. if you have config like "ike interface sec0 local ... peer ...", ipsecctl will generate the right config for isakmpd to negotiate esp tunnels for all traffic between 0.0.0.0/0 and 0.0.0.0/0. however, this also specifies that they should be set up as interface SAs in the kernel for use with sec(4). this supports route-based instead of policy based ipsec encapsulation, and allows us to more easily operate with other vendors and products that also offer route-based vpns with opinions about the negotiated policy that doesnt fit with the SPD. support from many including markus@ tobhe@ claudio@ sthen@ patrick@ now is a good time deraadt@
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2023/08/06 22:01:30 Modified files: sbin/isakmpd : ipsec.c pf_key_v2.c sa.h Log message: support configuring interface SAs for route-based ipsec vpns. add "Interface NUMBER" to the config parser to specify that once SAs have been negotiated with a peer, install the SAs with the sadb_x_iface extension set up, but skip installing the flows/SPD entries. this allows for the negotiation of multiple esp tunnels covering all traffic between 0.0.0.0/0 to 0.0.0.0/0, and then being able to do something useful with them using the routing table and sec(4) interfaces instead of having SPD entries fight over those packets in the kernel. this in turn allows interoperation with other ipsec/vpn solutions that require the negotiation of such tunnels. support from many including markus@ tobhe@ claudio@ sthen@ patrick@ now is a good time deraadt@
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2023/08/06 21:43:57 Modified files: sys/netinet: ip_ipsp.c ipsec_input.c Log message: add the glue between ipsec security associations and sec(4) interfaces. if TDBF_IFACE is set on a tdb, the ipsec stack will pass it to the sec(4) driver to keep track of instead of wiring it up for security associations to use. when sec(4) transmits a packet, it will look up it's list of tdbs to find the right SA to encrypt and send the packet out with. if an incoming ipsec packet arrives with TDBF_IFACE set, it's passed to sec(4) to be injected back into the network stack as if it was received on the sec interface, instead of being reinjected into the IP stack like normal SA/SPD processing does. note that this means you do not have to configure tunnel endpoints on sec(4) interfaces, instead you line the interface unit number in the ipsec config up with the minor number of the sec(4) interfaces. the peer IPs used on the SAs are what's used as the traffic endpoints. support from many including markus@ tobhe@ claudio@ sthen@ patrick@ now is a good time deraadt@
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2023/08/06 21:35:06 Modified files: sys/net: pfkeyv2.c pfkeyv2.h pfkeyv2_convert.c pfkeyv2_parsemessage.c Log message: add a struct sadb_x_iface message for interface SAs this allows userland to install (and see) security associations for route-based ipsec vpns. if this message is part of an SA, it causes the TDBF_IFACE flag and associated fields in a tdb to be set. the interface unit field in this message maps to minor number of the sec(4) interface you want to the SA to work with. ie, set the sadb_x_iface_unit field in struct sadb_x_iface to 1 to set up an SA for use with sec1. the sadb_x_iface_direction in the message uses IPSP_DIRECTION_IN and IPSP_DIRECTION_OUT to specify in which direction that SA is supposed to process traffic. support from many including markus@ tobhe@ claudio@ sthen@ patrick@ now is a good time deraadt@
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2023/08/06 21:17:42 Modified files: share/man/man4 : Makefile Added files: share/man/man4 : sec.4 Log message: sec(4) to support route-based ipsec vpns. committing it now so jmc@ gets commits for any fixes he makes.
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2023/08/06 19:59:38 Modified files: sys/conf : files Log message: wire sec(4) into the kernel config. this makes #include "sec.h" and #if NSEC > 0 work in kernel code.
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2023/08/06 19:57:33 Added files: sys/net: if_sec.c if_sec.h Log message: add sec(4) to support route based ipsec vpns. ipsec security associations (SAs, aka tdbs inside the kernel) can now specify that they're to be used with an interface (using TDBF_IFACE) rather than the ipsec security policy database. sec(4) is the driver providing that interface. the name is specifically chosen to not be ipsec(4) because that's already taken by the manpage for the ipsec stack generally. sec(4) is short, easy to type and pronounce, and kind of sounds like ipsec anyway. the names for this type of interface in other platforms seems to be universally terrible and too generic, so i didn't want to copy any of those either. sec(4) can be considered equivalent to gif(4) protected by ipsec, and on the wire it actually looks the same. sec(4) exists to better support how security associations for route-based ipsec VPNs are negotiated and to avoid SPD entries for them. the code is a little green, but i'm putting it in now so it can be hacked on in the tree. support from many including markus@ tobhe@ claudio@ sthen@ patrick@ now is a good time deraadt@
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2023/08/06 19:44:51 Modified files: sys/netinet: ip_ipsp.h Log message: start adding support for route-based ipsec vpns. rather than use ipsec flows (aka, entries in the ipsec security policy database) to decide which traffic should be encapsulated in ipsec and sent to a peer, this tweaks security associations (SAs) so they can refer to a tunnel interface. when traffic is routed over that tunnel interface, an ipsec SA is looked up and used to encapsulate traffic before being sent to the peer on the SA. When traffic is received from a peer using an interface SA, the specified interface is looked up and the packet is handed to it so it looks like packets come out of the tunnel. to support this, SAs get a TDBF_IFACE flag and iface and iface_dir fields. When TDBF_IFACE is set the iface and dir fields are considered valid, and the tdb/SA should be used with the tunnel interface instead of the SPD. support from many including markus@ tobhe@ claudio@ sthen@ patrick@ now is a good time deraadt@
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2023/07/31 05:13:10 Modified files: sys/net: pf.c if_pfsync.c if_pfsync.h Log message: don't let pfsync send an insert message for a state pfsync just inserted sthen@ upgraded and ended up with a lot of pfsync traffic which was mostly made up of the two firewalls telling each other to insert the same state over and over again. this has each of the paths that insert states (actual pf, ioctls, and pfsync) identify themselves so pfsync can enter them into its own state machine in the right place. when pfsync inserts a state into pf, it knows it should just swallow the state silently without sending out another insert for it. ok sthen@ sashan@
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2023/07/29 23:39:52 Modified files: sys/net: ifq.c ifq.h Log message: count the number of times a ring was marked as oactive. this is interesting as an indicator of how busy or overloaded a transmit queue is before the next indicator which is the number of qdrops.
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2023/07/29 22:27:01 Modified files: sys/dev/pci: if_vmx.c Log message: move rx head register writes out of rx completions and into rxfill rxfill is always called after rx completions are done anyway, and it makes more sense to give the hypervisor an update about new mbufs on the ring after we put them there.
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2023/07/29 22:10:58 Modified files: sys/dev/pci: if_vmx.c Log message: fix generation handling on rx ring wraparound.
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2023/07/29 21:40:08 Modified files: sys/dev/pci: if_vmx.c Log message: white space fixes, no functional change
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2023/07/29 21:35:50 Modified files: sys/dev/pci: if_vmx.c Log message: add bus_dmamap_sync() ops around the rx handling.
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2023/07/29 20:10:00 Modified files: sys/dev/pci: if_vmx.c Log message: clear oactive on each txq, not just txq 0 when the iface goes up or down if the driver did get into a situation where the tx rings were out of sync (which should be fixed now) and were stuck oactive, taking the interface down and up didnt clear that on anything except ring 0.
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2023/07/29 19:59:23 Modified files: sys/dev/pci: if_vmx.c Log message: add bus_dmamap_syncs around tx ring handling. this copies the dmamem wrapper from ixl (which has been copied around lots of other places too) so it makes the bus_dma ops around them more consistent with other drivers. before this vmx would use the bus dma api to allocate physical memory, but then free the dmamap so it wasnt available for use with bus_dmamap_sync().
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2023/07/29 19:41:05 Modified files: sys/dev/pci: if_vmx.c Log message: tighten up the tx start/completion handling of the producer and consumer. the hypervisor obvious snoops the descriptor rings like crazy, and it can run and complete transmit of packets as soon as the ownership bit is set on the descriptor and before the txh register is updated with the producer index. txintr would only process tx completions if the producer and consumer indexes the driver maintains were different, but would then go and pop every packet the hardware said was done off the ring. this changes txintr so it will only iterate over packets between the driver consumer and producer indexes. also, have the start code update the producer before flipping the ownership bit in the ring. this keeps the start and intr code in sync.
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2023/07/29 19:15:42 Modified files: sys/dev/pci: if_vmx.c Log message: post tx ring producer updates to each rings own txh register. before this change all the different ring producer updates were posted to ring 0.
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2023/07/05 22:55:05 Modified files: sys/net: if.c if_pfsync.c if_pfsync.h netisr.h pf.c pf_ioctl.c pf_norm.c pfvar.h pfvar_priv.h sys/netinet: in_proto.c ip_ipsp.h Log message: big update to pfsync to try and clean up locking in particular. moving pf forward has been a real struggle, and pfsync has been a constant source of pain. we have been papering over the problems for a while now, but it reached the point that it needed a fundamental restructure, which is what this diff is. the big headliner changes in this diff are: - pfsync specific locks this is the whole reason for this diff. rather than rely on NET_LOCK or KERNEL_LOCK or whatever, pfsync now has it's own locks to protect it's internal data structures. this is important because pfsync runs a bunch of timeouts and tasks to push pfsync packets out on the wire, or when it's handling requests generated by incoming pfsync packets, both of which happen outside pf itself running. having pfsync specific locks around pfsync data structures makes the mutations of these data structures a lot more explicit and auditable. - partitioning to enable future parallelisation of the network stack, this rewrite includes support for pfsync to partition states into different "slices". these slices run independently, ie, the states collected by one slice are serialised into a separate packet to the states collected and serialised by another slice. states are mapped to pfsync slices based on the pf state hash, which is the same hash that the rest of the network stack and multiq hardware uses. - no more pfsync called from netisr pfsync used to be called from netisr to try and bundle packets, but now that there's multiple pfsync slices this doesnt make sense. instead it uses tasks in softnet tqs. - improved bulk transfer handling there's shiny new state machines around both the bulk transmit and receive handling. pfsync used to do horrible things to carp demotion counters, but now it is very predictable and returns the counters back where they started. - better tdb handling the tdb handling was pretty hairy, but hrvoje has kicked this around a lot with ipsec and sasyncd and we've found and fixed a bunch of issues as a result of that testing. - mpsafe pf state purges this was committed previously, but because the locks pfsync relied on weren't clear this just caused a ton of bugs. as part of this diff it's now reliable, and moves a big chunk of work out from under KERNEL_LOCK, which in turn improves the responsiveness and throughput of a firewall even if you're not using pfsync. there's a bunch of other little changes along the way, but the above are the big ones. hrvoje has done performance testing with this diff and notes a big improvement when pfsync is not in use. performance when pfsync is enabled is about the same, but im hoping the slices means we can scale along with pf as it improves. lots (months) of testing by me and hrvoje on pfsync boxes tests and ok sashan@ deraadt@ says this is a good time to put it in
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2023/07/03 21:59:21 Modified files: usr.bin/ssh: channels.c channels.h ssh.c Log message: add support for unix domain sockets to ssh -W ok djm@ dtucker@
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2023/07/03 20:56:11 Modified files: usr.sbin/ospf6d: parse.y Log message: a little knf, no functional change
