| Commit message (Collapse) | Author | Age | Files | Lines | |
|---|---|---|---|---|---|
| * | unbreak build on UP kernels. |   dlg | 2015-09-11 | 1 | -16/+8 |
| | | | | | found by deraadt@ | ||||
| * | make srp use refcnts so it can use refcnt_finalize instead of | dlg | 2015-09-11 | 1 | -18/+7 |
| | | | | | sleep_setup/sleep_finish. | ||||
| * | remove some bits of srp.h i had pasted in here by accident | dlg | 2015-09-11 | 1 | -7/+1 |
| | | |||||
| * | implement a singly linked list built with SRPs. | dlg | 2015-09-09 | 1 | -1/+15 |
| | | | | | | | | this allows us to build lists of things that can be followed by multiple cpus. ok mpi@ claudio@ | ||||
| * | mattieu baptiste reported a problem with bpf+srps where the per cpu | dlg | 2015-09-01 | 1 | -19/+42 |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | hazard pointers were becoming corrupt and therefore panics. the problem turned out to be that bridge_input calls if_input on behalf of a hardware interface which then calls bpf_mtap at splsoftnet, while the actual hardware nic calls if_input and bpf_mtap at splnet. the hardware interrupts ran in the middle of the bpf calls bridge runs at softnet. this means the same srps are being entered and left on the same cpu at different ipls, which led to races because of the order of operations on the per cpu hazard pointers. after a lot of experimentation, jmatthew@ figured out how to deal with this problem without introducing per cpu critical sections (ie, splhigh) calls in srp_enter and srp_leave, and without introducing atomic operations. the solution is to iterate forward through the array of hazard pointers in srp_enter, and backward in srp_leave to clear. if you guarantee that you leave srps in the reverse order to entering them, then you can use the same set of SRPs at different IPLs on the same CPU. the ordering requirement is a problem if we want to build linked data structures out of srps because you need to hold a ref to the current element containing the next srp to use it, before giving up the current ref. we're adding srp_follow() to support taking the next ref and giving up the current one while preserving the structure of the hazard pointer list. srp_follow() does this by reusing the hazard pointer for the current reference for the next ref. both mattieu baptiste and jmatthew@ have been hitting this pretty hard with a tweaked version of srp+bpf that uses srp_follow instead of interleaved srp_enter/srp_leave sequences. neither can reproduce the panics anymore. thanks to mattieu for the report and tests ok jmatthew@ | ||||
| * | introduce srp, which according to the manpage i wrote is short for | dlg | 2015-07-02 | 1 | -0/+265 |
| "shared reference pointers". srp allows concurrent access to a data structure by multiple cpus while avoiding interlocking cpu opcodes. it manages its own reference counts and the garbage collection of those data structure to avoid use after frees. internally srp is a twisted version of hazard pointers, which are a relative of RCU. jmatthew wrote the bulk of a hazard pointer implementation and changed bpf to use it to allow mpsafe access to bpfilters. however, at s2k15 we were trying to apply it to other data structures but the memory overhead of every hazard pointer would have blown out significantly in several uses cases. a bulk of our time at s2k15 was spent reworking hazard pointers into srp. this diff adds the srp api and adds the necessary metadata to struct cpuinfo on our MP architectures. srp on uniprocessor platforms has alternate code that is optimised because it knows there'll be no concurrent access to data by multiple cpus. srp is made available to the system via param.h, so it should be available everywhere in the kernel. the docs likely need improvement cos im too close to the implementation. ok mpi@ | |||||
 |
index : wireguard-openbsd | |
| WireGuard implementation for the OpenBSD kernel | Matt Dunwoodie |
| summaryrefslogtreecommitdiffstats |