summaryrefslogtreecommitdiffstats
path: root/sys (follow)
Commit message (Collapse)AuthorAgeFilesLines
...
* Move `pgo_fault' handler outside of uvm_fault_lower().mpi2021-02-231-25/+32
| | | | | | Reduce differences with NetBSD and prepare for `uobj' locking. No functionnal change. ok chris@, kettenis@
* remove some unused includesjsg2021-02-2319-2387/+0
|
* use the ipv6 dst addr to look up an ipsec tdb in bridge_ipsec in.dlg2021-02-231-2/+2
| | | | | | | | | using the ipv6 next protocol header probably doesnt work. it also probably doesnt matter cos i'm not sure anyone uses this feature in bridge. or maybe there isn't anyone who uses ipv6. both are plausible options. hahaha^Wok patrick@
* use link0 to allow vlans to cross the bridge.dlg2021-02-231-2/+2
|
* implement support for the blocknonip port flag.dlg2021-02-231-2/+25
|
* add support for setting and getting bridge port flags.dlg2021-02-231-1/+48
|
* timecounting: use C99-style initialization for all timecounter structscheloha2021-02-2326-111/+238
| | | | | | | | | | | | | | | | | | The timecounter struct is large and I think it may change in the future. Changing it later will be easier if we use C99-style initialization for all timecounter structs. It also makes reading the code a bit easier. For reasons I cannot explain, switching to C99-style initialization sometimes changes the hash of the resulting object file, even though the resulting struct should be the same. So there is a binary change here, but only sometimes. No behavior should change in either case. I can't compile-test this everywhere but I have been staring at the diff for days now and I'm relatively confident this will not break compilation. Fingers crossed. ok gnezdo@
* filter MAC Bridge component Reserved addressdlg2021-02-231-1/+21
| | | | | | im considering converting ethernet addresses into uint64_ts to make comparisons (and masking) easier. im trialling it here, and it doesn't seem like the worst.
* add veb(4), a Virtual Ethernet Bridge driver.dlg2021-02-232-1/+1745
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | my intention is to replace bridge(4), but the way it works is different enough from from bridge that a name change is justified to distinguish them. it also makes it easier to commit it to the tree and work on it in parallel to bridge, and allows a window of migration. the main difference between veb(4) and bridge(4) is how they use interfaces as ports. veb takes over interfaces completely and only uses them to receive and transmit ethernet packets. bridge also use each interface as a port to the ethernet segment it's connected to, but also tries to continue supporting the use of the interface as a way to talk to the network stack on the local system. supporting the use of interfaces for both external and local communication is where most of my confusion with bridge comes from, both when i'm trying to operate it and also understand the code. changing this semantic is where most of the simplification in veb comes from compared to bridge. because veb takes over interfaces, the ethernet network set up on a veb is isolated from the host network stack. by default veb does not interact with pf or the ip (and mpls) stacks. to enable pf for ip frames going over veb ports link1 on the veb interface must be set. to have the stack interact with a veb network, vport interfaces must be created and added as ports to a veb. the vport interface driver is provided as part of veb, and is handled specially by veb. veb usually prevents the use of ports by the stack for sending an receiving packets, but that's why vports exist, so veb has special handling for them. veb already supports a lot of the other features that bridge has, including bridge rules and protected domains, but i got tired of working out of the tree and stopped implementing them. the main outstanding features is better address table management, the blocknonip flag on ports, transparent ipsec interception, and spanning tree. i may not bother with spanning tree unless someone tells me that they actually use it. the core ethernet learning bridge functionality is provided by the etherbridge code that was factored out of nvgre and bpe. veb is already (a lot) faster than bridge, and is better prepared to operate in parallel on multiple CPUs concurrently. thanks to hrvoje popovski for testing some earlier versions of this. discussed with many ok patrick@ jmatthew@
* remove unused acpiec_lock() acpiec_unlock() functionsjsg2021-02-231-28/+1
| | | | ok kettenis@ pirofti@
* Terminate backtrace of secondary processors in ddb.kettenis2021-02-221-1/+4
| | | | From miod@
* Enable bge(4).kettenis2021-02-222-2/+4
|
* Enable apldog(4).kettenis2021-02-223-3/+9
|
* Add apldog(4), a driver for the watchdog on Apple M1 SoCs.kettenis2021-02-221-0/+117
| | | | | | This allows us to reboot the machine. ok patrick@
* Move UNIX socket's garbage collector to `systqmp'. It touches nothingmvs2021-02-221-3/+3
| | | | | | which requires kernel lock to be held. ok mpi@
* Disable double-data rate modes if 1.8V signalling is not possible.patrick2021-02-221-2/+4
| | | | ok kettenis@
* Slow mode is only relevant for legacy and high speed timings.patrick2021-02-221-3/+3
| | | | ok kettenis@
* Improve support for the variant found on the Apple M1 SoC.kettenis2021-02-222-64/+161
| | | | | | | This mostly adjust the interrupt masking and status support since this variant lacks the UINTM and UINTP registers. ok patrick@
* When cutting of the head of an overlapping fragment during pfbluhm2021-02-221-1/+26
| | | | | | | reassembly, reinsert the fragment into the lookup table with correct index. Reported-by: syzbot+d043455a5346f726f1c4@syzkaller.appspotmail.com OK claudio@
* regenjsg2021-02-222-8/+120
|
* add some AMD 500 series, 17h/71h, Navi 10 and Kingston NVMe idsjsg2021-02-221-4/+28
| | | | initial diff from Sven Wolf
* how about sticking to standard C.deraadt2021-02-211-2/+2
|
* Add cryptox(4), a driver for armv8 cryptographic extensions.tobhe2021-02-215-3/+1660
| | | | | | | | The driver currently only supports AES-CBC mode but can easily be extended to other algorithms and modes. The aesv8-armx.S file was generated from the CRYPTOGAMS project. Asked to commit by and ok patrick@
* One CPUs that implement the VHE extension and have the E2H bit set, keepkettenis2021-02-212-6/+12
| | | | | | running the kernel in EL2. ok patrick@
* cut nvgre(4) over to use common etherbridge code.dlg2021-02-212-317/+129
| | | | | | | the "ports" that nvgre provides to etherbridge are ip addresses used in the underlay network. ok patrick@ jmatthew@
* cut bpe(4) over to using the common etherbridge code.dlg2021-02-212-292/+127
| | | | | | | | | it's pretty straightforward since etherbridge was mostly based on this code in the first place. the etherbridge_ops that bpe provides to etherbridge set entries up to point at mac addresses in the underlay network. ok patrick@ jmatthew@
* add etherbridge, the guts of a learning bridge that can be reused.dlg2021-02-213-2/+693
| | | | | | | | | | | | | | | | | | | | | | | | | | this allows for the factoring out of the learning bridge code i wrote in bpe and nvme, and should be reusable for other drivers needing a mac learning bridge. the core data structures are an etherbridge struct to represent the learning bridge, eb_entry structs for each mac address entry that the bridge knows about, and an etherbridge_ops struct that drivers fill in so that they can use this code. eb_entry structs are stored in a hash table made up of SMR_TAILQs to support lookups of entries quickly and concurrently in the forwarding path. they are also stored in a locked red-black tree to help manage the uniqueness of the mac address in the table. the etherbridge_ops handlers mostly deal with comparing and testing the "ports" associated with mac address table entries. the "port" that a mac address entry is associated with is opaque to the etherbridge code, which allows for this code to be used by nvgre and bpe which map mac addresses inside the bridge to addresses in their underlay networks. it also supports traditional bridges where "ports" are actual interfaces. ok patrick@ jmatthew@
* add stoeplitz_eaddr, for getting a hash value from an ethernet address.dlg2021-02-212-2/+16
|
* remove warning about amdgpu userptr ioctl being unimplementedjsg2021-02-201-1/+0
| | | | | matches radeon and i915 reported by Benjamin Baier
* Fix disestablishing of PCI interrupt handlers.visa2021-02-201-9/+2
|
* move from calling l3 protocol input handlers to using if_vinput.dlg2021-02-202-40/+14
| | | | | | if_vinput requires mpsafe interface counters, so add those in. this factors out some more code between drivers. monitor mode will work on these interfaces now too.
* move gre and mgre from calling l3 input handlers to using if_vinput.dlg2021-02-201-46/+11
| | | | | | | | using if_vinput factors out a lot of repeated code between tunnel drivers, and it means monitor mode works on gre and mgre now too. make the l2 gre interfaces do some things in the same order while here.
* move gif from calling l3 protocol input handlers to using if_vinput.dlg2021-02-201-25/+5
| | | | | | if_vinput requires mpsafe interface counters, so gif is a bit more mpsafe now than it was before. using if_vinput means monitor mode works on gif now too.
* add p2p_input, like ether_input but for l3 tunnel interfaces.dlg2021-02-202-2/+44
| | | | | | | | the l3 protocol input to push the packet is based on a value in m->m_pkthdr.ph_family, which tunnel drivers should set before calling if_vinput. add p2p_bpf_mtap to call bpf_mtap_af also using m->m_pkthdr.ph_family.
* let tun use bpf_mtap for handling input packets.dlg2021-02-201-1/+4
| | | | | | | tun (not tap) input packets are written from userland in the same format that it's bpf dlt is expecting, so we can push the packet straight into bpf with bpf_mtap. this is more correct that using bpf_mtap_ether for tun.
* default interfaces to bpf_mtap_ether for their if_bpf_mtap handler.dlg2021-02-202-4/+8
| | | | | call (*ifp->if_bpf_mtap) instead of bpf_mtap_ether in ifiq_input and if_vinput.
* give interfaces an if_bpf_mtap handler.dlg2021-02-201-1/+2
| | | | | | | | the network stack is now responsible for calling bpf for packets that the interface receives, and we so far got away with using bpf_mtap_ether for everything. this doesn't work if layer 3 input goes through the same functions, so letting drivers specify the appropriate bpf mtap function means they will be able to cope.
* add a MONITOR flag to ifaces to say they're only used for watching packets.dlg2021-02-203-8/+12
| | | | | | | | | | | an example use of this is when you have a span port on a switch and you want to be able to see the packets coming out of it with tcpdump, but do not want these packets to enter the network stack for processing. this is particularly important if the span port is pushing a copy of any packets related to the machine doing the monitoring as it will confuse pf states and the stack. ok benno@
* we dont need to wrap some short lines.dlg2021-02-191-5/+3
|
* check the state for PF_ROUTE when undeferring a packet, not the rule.dlg2021-02-191-2/+2
|
* Make kernel ld.script similar to octeon's on loongson and sgi.visa2021-02-182-14/+74
|
* Release mbuf(9) chain with a simple m_freem(9) loop in sorflush().mvs2021-02-182-8/+8
| | | | | | | | | | | | Passing local copy of socket to sbrelease() is too complicated to just free receive buffer. We don't allocate large object on the stack. Also we don't pass unlocked socket to soassertlocked() within sbdrop(). This was not triggered because we lock the whole layer with one lock. Also sorflush() is now private to kern/uipc_socket.c, so it's definition was made to be in accordance. ok claudio@ mpi@
* handle "simple-pm-bus" in simplebusjsg2021-02-181-5/+10
| | | | | | | Enables a clock and/or power domain for a group of devices. Required to use linux 5.11 dtbs on am335x and omap4. ok kettenis@
* Unify unit initialization.mglocker2021-02-171-9/+7
|
* If the device driver open call fails, don't set sc_open since in that casemglocker2021-02-171-5/+7
| | | | | | | we don't get a file handle back which could be closed again, and therefore we couldn't toggle sc_open back to zero. Spotted and ok anton@
* Skip gp initialization in loongson bootblocksvisa2021-02-172-3/+1
| | | | | | | The loongson bootblocks are compiled with -mno-abicalls and do not use gp-relative addressing. A similar change has been made to the mips64 kernels recently.
* Do not reprogram address filter after MII status changevisa2021-02-171-5/+1
| | | | | The address filter is not affected by link parameter changes, so its reprogramming can be skipped.
* Add support for FIQs. We need these to support agtimer(4) on Apple M1 SoCskettenis2021-02-179-49/+104
| | | | | | | | since its interrupts seem to be hardwared to trigger an FIQ instead of an IRQ. This means we need to manipulate both the F and the I bit in the DAIF register when enabling and disabling interrupts. ok patrick@
* Call 'struct process' parameters 'pr' to distinguish from 'struct proc'mglocker2021-02-171-4/+4
| | | | | | parameters which are usually called 'p'. Spotted and ok anton@
* Collect return code of video_stop() for ioctls calls.mglocker2021-02-171-2/+2
| | | | Spotted and ok anton@
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.