| created | 2021-11-13T12:06:13Z |
|---|---|
| begin | 2021-11-06T00:00:00Z |
| end | 2021-11-07T00:00:00Z |
| path | src/sys |
| commits | 3 |
| date | 2021-11-06T05:26:33Z | |||
|---|---|---|---|---|
| author | visa | |||
| files | src/sys/kern/uipc_socket.c | log | diff | annotate |
| src/sys/kern/uipc_socket2.c | log | diff | annotate | |
| src/sys/sys/socketvar.h | log | diff | annotate | |
| message |
Allocate socket and initialize so_lock in one place This makes witness(4) use a single lock type for tracking so_lock. Previously, so_lock was covered by two distinct lock types because there were separate rw_init() initializers in socreate() and sonewconn(). OK kettenis@ |
|||
| date | 2021-11-06T05:48:47Z | |||
|---|---|---|---|---|
| author | visa | |||
| files | src/sys/kern/kern_event.c | log | diff | annotate |
| message |
Make kqread event filter MP-safe Use the monitored kqueue's kq_lock to serialize kqueue and knote access. Typically, the "object lock" would cover also the klist, but that is not possible with kqueues. knote_activate() needs kq_lock of the monitoring kqueue, which would create lock order troubles if kq_lock was held when calling KNOTE(&kq->kq_sel.si_note). Avoid this by using a separate klist lock for kqueues. The new klist lock is system-wide. Each kqueue instance could have a dedicated klist lock. However, the efficacy of dedicated versus system-wide lock is somewhat limited because the current implementation activates kqueue knotes through a single thread. OK mpi@ |
|||
| date | 2021-11-06T17:35:14Z | |||
|---|---|---|---|---|
| author | mvs | |||
| files | src/sys/kern/uipc_usrreq.c | log | diff | annotate |
| src/sys/sys/unpcb.h | log | diff | annotate | |
| message |
Make `unp_msgcount' and `unp_file' atomic. Introduce `unp_rights_mtx' mutex(9) to protect `unp_rights'. This removes global rwlock(9) from unp_internalize() and unp_externalize() normal paths and leaves it in the unp_externalize() error path only. Also we don't need to simultaneously hold fdplock() and `unp_lock' within unp_internalize(). The `unp_rights' can't be atomic. Otherwise the thread which exceeding the limit will break all other not-exceeding threads until it decrements `unp_rights'. That why the mutex(9) used for protection. It's safe to call fptounp() without `unp_lock' held. We always got this file descriptor by fd_getfile(9) so we always have the extra reference and this descriptor can't be closed by concurrent thread. Some sockets could be destroyed through 'PRU_ABORT' path but they don't have associated file descriptor and they are not accessible in the unp_internalize() path. The `unp_file' access without `unp_lock' held is also safe. Each socket could have the only associated file descriptor and each file descriptor could have the only associated socket. We only assign `unp_file' in the unp_internalize() path where we got the socket by fd_getfile(9). This descriptor has the extra reference and couldn't be closed concurrently. We could override `unp_file' but with the same address because the associated file descriptor can't be changed so the address will be also the same. While unp_gc() concurrently runs the dereference of non-NULL `unp_file' is always safe. Discussed with kettenis@ and mpi@. ok mpi@ |
|||