| created | 2021-06-26T20:37:50Z |
|---|---|
| begin | 2021-06-23T00:00:00Z |
| end | 2021-06-24T00:00:00Z |
| path | src/sys |
| commits | 12 |
| date | 2021-06-23T04:16:32Z | |||
|---|---|---|---|---|
| author | dlg | |||
| files | src/sys/net/pf.c | log | diff | annotate |
| src/sys/net/pfvar.h | log | diff | annotate | |
| message |
rework pf_state_expires to avoid confusion around state->timeout. im going to make it so pf_purge_expired_states() can gather states largely without sharing a lock with pfsync or actual packet processing in pf. if pf or pfsync unlink a state while pf_purge_expired_states is looking at it, we can race with some checks and fall over a KASSERT. i'm fixing this by having the caller of pf_state_expires read state->timeout first, do it's checks, and then pass the value as an argument into pf_state_expires. this means there's a consistent view of the state->timeout variable across all the checks that pf_purge_expired_states in particular does. if pf/pfsync does change the timeout while pf_purge_expired_states is looking at it, the worst thing that happens is that it doesn't get picked as a candidate for purging in this pass and will have to wait for the next sweep. ok sashan@ as part of a bigger diff |
|||
| date | 2021-06-23T05:43:53Z | |||
|---|---|---|---|---|
| author | dlg | |||
| files | src/sys/net/if_pfsync.c | log | diff | annotate |
| message |
pfsync_undefer_notify needs to be careful before dereferecing state keys. pfsync_undefer_notify uses the state keys to look up the address family, which is used to figure out if it should call ipv4 or ipv6 functions. however, the pf state purge code can unlink a state from the trees (ie, the state keys get removed) while the pfsync defer code is holding a reference to it and expects to be able to send the deferred packet in the future. we can test if the state keys are set by checking if the timeout state is PFTM_UNLINK or not. this currently relies on both pf_remove_state and pfsync_undefer_notify being called with the NET_LOCK held. this probably needs to be rethought later but is good enough for now. found the hard way on a production firewall at work. |
|||
| date | 2021-06-23T05:51:27Z | |||
|---|---|---|---|---|
| author | dlg | |||
| files | src/sys/net/pf.c | log | diff | annotate |
| message | pf_purge_expired_states can check the time once instead of for every state. | |||
| date | 2021-06-23T06:53:51Z | |||
|---|---|---|---|---|
| author | dlg | |||
| files | src/sys/net/if_pfsync.c | log | diff | annotate |
| message |
augment the global pf state list with its own locks. before this, things that iterated over the global list of pf states had to take the net, pf, or pf state locks. in particular, the ioctls that dump the state table took the net and pf state locks before iterating over the states and using copyout to export them to userland. when we tried replacing the use rwlocks with mutexes under the pf locks, this blew up because you can't sleep when holding a mutex and there's a sleeping lock used inside copyout. this diff introduces two locks around the global state list: a mutex that protects the head and tail of the list, and an rwlock that protects the links between elements in the list. inserts on the state list only occur during packet handling and can be done by taking the mutex and putting the state on the tail before releasing the mutex. iterating over states is only done from thread/process contexts, so we can take a read lock, then the mutex to get a snapshot of the head and tail pointers, and then keep the read lock to iterate between the head and tail points. because it's a read lock we can then take other sleeping locks (eg, the one inside copyout) without (further) gymnastics. the pf state purge code takes the rwlock exclusively and the mutex to remove elements from the list. this allows the ioctls and purge code to loop over the list concurrently and largely without blocking the creation of states when pf is processing packets. pfsync also iterates over the state list when doing bulk sends, which the state purge code needs to be careful around. ok sashan@ |
|||
| date | 2021-06-23T06:53:52Z | |||
|---|---|---|---|---|
| author | dlg | |||
| files | src/sys/net/pf.c | log | diff | annotate |
| src/sys/net/pf_ioctl.c | log | diff | annotate | |
| src/sys/net/pfvar.h | log | diff | annotate | |
| src/sys/net/pfvar_priv.h | log | diff | annotate | |
| message |
augment the global pf state list with its own locks. before this, things that iterated over the global list of pf states had to take the net, pf, or pf state locks. in particular, the ioctls that dump the state table took the net and pf state locks before iterating over the states and using copyout to export them to userland. when we tried replacing the use rwlocks with mutexes under the pf locks, this blew up because you can't sleep when holding a mutex and there's a sleeping lock used inside copyout. this diff introduces two locks around the global state list: a mutex that protects the head and tail of the list, and an rwlock that protects the links between elements in the list. inserts on the state list only occur during packet handling and can be done by taking the mutex and putting the state on the tail before releasing the mutex. iterating over states is only done from thread/process contexts, so we can take a read lock, then the mutex to get a snapshot of the head and tail pointers, and then keep the read lock to iterate between the head and tail points. because it's a read lock we can then take other sleeping locks (eg, the one inside copyout) without (further) gymnastics. the pf state purge code takes the rwlock exclusively and the mutex to remove elements from the list. this allows the ioctls and purge code to loop over the list concurrently and largely without blocking the creation of states when pf is processing packets. pfsync also iterates over the state list when doing bulk sends, which the state purge code needs to be careful around. ok sashan@ |
|||
| date | 2021-06-23T13:39:12Z | |||
|---|---|---|---|---|
| author | kettenis | |||
| files | src/sys/dev/fdt/ociic.c | log | diff | annotate |
| message |
Make sure the bus is idle before starting a transfer. ok deraadt@ |
|||
| date | 2021-06-23T14:09:01Z | |||
|---|---|---|---|---|
| author | claudio | |||
| files | src/sys/kern/kern_unveil.c | log | diff | annotate |
| message |
In unveil_add_vnode() refactor code around the indexes i and j. In one place the wrong index is used resulting in re-evaluating all unveil nodes. Also loop over over all but the last (just added vnode) -- again there is no need to re-evaluate the cover of the just added unveil. OK anton@ semarie@ |
|||
| date | 2021-06-23T14:12:59Z | |||
|---|---|---|---|---|
| author | cheloha | |||
| files | src/sys/arch/macppc/dev/adb.c | log | diff | annotate |
| message |
adb(4/macppc): fix adb_cuda_tickle() prototype Timeout callback functions are of type void (*)(void *). adb_cuda_tickle() needs a void pointer for a first parameter. ok mpi@ |
|||
| date | 2021-06-23T15:25:39Z | |||
|---|---|---|---|---|
| author | kettenis | |||
| files | src/sys/dev/i2c/files.i2c | log | diff | annotate |
| src/sys/dev/i2c/tmp451.c | log | diff | annotate | |
| message |
Add titmp(4), a driver for the TI TMP451 temperature sensor. ok deraadt@ |
|||
| date | 2021-06-23T15:26:10Z | |||
|---|---|---|---|---|
| author | kettenis | |||
| files | src/sys/arch/riscv64/conf/GENERIC | log | diff | annotate |
| message |
Enable titmp(4). ok deraadt@ |
|||
| date | 2021-06-23T16:10:45Z | |||
|---|---|---|---|---|
| author | cheloha | |||
| files | src/sys/net/rtsock.c | log | diff | annotate |
| message | rtsock: revert from timeout_set_flags(9) to timeout_set_proc(9); ok mvs@ | |||
| date | 2021-06-23T19:46:13Z | |||
|---|---|---|---|---|
| author | patrick | |||
| files | src/sys/arch/arm64/dev/smmu.c | log | diff | annotate |
| message |
The first page of the I/O virtual address space is reserved so that is easier to spot misconfiguration or wrong behaviour where NULL is used as address. Right now that page is not part of the IOVA at all, so when we reserve regions, like PCI I/O space, which can cover that page as well, extent(9) will panic. Instead, include it in the IOVA but reserve it right away. This way that page can be reserved twice. |
|||