| created | 2020-11-29T23:30:10Z |
|---|---|
| begin | 2020-10-07T00:00:00Z |
| end | 2020-10-08T00:00:00Z |
| path | src/sys |
| commits | 20 |
| date | 2020-10-07T01:15:18Z | |||
|---|---|---|---|---|
| author | jsg | |||
| files | src/sys/dev/pci/pcidevs | log | diff | annotate |
| message | add Intel 495 Series LP PCH and Ice Lake graphics ids | |||
| date | 2020-10-07T01:18:26Z | |||
|---|---|---|---|---|
| author | jsg | |||
| files | src/sys/dev/pci/pcidevs.h | log | diff | annotate |
| message | regen | |||
| date | 2020-10-07T01:18:27Z | |||
|---|---|---|---|---|
| author | jsg | |||
| files | src/sys/dev/pci/pcidevs_data.h | log | diff | annotate |
| message | regen | |||
| date | 2020-10-07T06:26:43Z | |||
|---|---|---|---|---|
| author | jsg | |||
| files | src/sys/dev/pci/pcidevs | log | diff | annotate |
| message | add Intel 400 Series and 400 Series V PCH ids | |||
| date | 2020-10-07T06:27:22Z | |||
|---|---|---|---|---|
| author | jsg | |||
| files | src/sys/dev/pci/pcidevs.h | log | diff | annotate |
| message | regen | |||
| date | 2020-10-07T06:27:23Z | |||
|---|---|---|---|---|
| author | jsg | |||
| files | src/sys/dev/pci/pcidevs_data.h | log | diff | annotate |
| message | regen | |||
| date | 2020-10-07T11:14:59Z | |||
|---|---|---|---|---|
| author | jsg | |||
| files | src/sys/dev/pci/pcidevs | log | diff | annotate |
| message | add more Intel 100, 200 and 300 Series PCH ids | |||
| date | 2020-10-07T11:15:31Z | |||
|---|---|---|---|---|
| author | jsg | |||
| files | src/sys/dev/pci/pcidevs.h | log | diff | annotate |
| src/sys/dev/pci/pcidevs_data.h | log | diff | annotate | |
| message | regen | |||
| date | 2020-10-07T11:17:59Z | |||
|---|---|---|---|---|
| author | jsg | |||
| files | src/sys/dev/pci/dwiic_pci.c | log | diff | annotate |
| message | match on more Intel dwiic pci ids | |||
| date | 2020-10-07T11:19:28Z | |||
|---|---|---|---|---|
| author | jsg | |||
| files | src/sys/dev/pci/pchtemp.c | log | diff | annotate |
| message | match on more pch thermal ids | |||
| date | 2020-10-07T11:20:41Z | |||
|---|---|---|---|---|
| author | jsg | |||
| files | src/sys/dev/pci/pucdata.c | log | diff | annotate |
| message | match on more pch kt ids | |||
| date | 2020-10-07T11:23:05Z | |||
|---|---|---|---|---|
| author | jsg | |||
| files | src/sys/dev/pci/ichiic.c | log | diff | annotate |
| message | match more Intel PCH SMBus ids | |||
| date | 2020-10-07T12:13:23Z | |||
|---|---|---|---|---|
| author | mpi | |||
| files | src/sys/arch/m88k/m88k/softintr.c | log | diff | annotate |
| src/sys/arch/mips64/mips64/softintr.c | log | diff | annotate | |
| src/sys/arch/powerpc64/powerpc64/softintr.c | log | diff | annotate | |
| src/sys/arch/sh/sh/interrupt.c | log | diff | annotate | |
| message |
Include <sys/systm.h> directly instead of relying on hidden UVM includes. The header is being pulled via uvm_extern.h -> uvm_map.h |
|||
| date | 2020-10-07T12:26:20Z | |||
|---|---|---|---|---|
| author | mpi | |||
| files | src/sys/uvm/uvm_mmap.c | log | diff | annotate |
| message |
Do not release the KERNEL_LOCK() when mmap(2)ing files. Previous attempt to unlock amap & anon exposed a race in vnode reference counting. So be conservative with the code paths that we're not fully moving out of the KERNEL_LOCK() to allow us to concentrate on one area at a time. The panic reported was: ....panic: vref used where vget required ....db_enter() at db_enter+0x5 ....panic() at panic+0x129 ....vref(ffffff03b20d29e8) at vref+0x5d ....uvn_attach(1010000,ffffff03a5879dc0) at uvn_attach+0x11d ....uvm_mmapfile(7,ffffff03a5879dc0,2,1,13,100000012) at uvm_mmapfile+0x12c ....sys_mmap(c50,ffff8000225f82a0,1) at sys_mmap+0x604 ....syscall() at syscall+0x279 Note that this change has no effect as long as mmap(2) is still executed with ze big lock. ok kettenis@ |
|||
| date | 2020-10-07T12:33:03Z | |||
|---|---|---|---|---|
| author | mpi | |||
| files | src/sys/kern/vfs_vops.c | log | diff | annotate |
| message |
Document that `a_p' is always curproc by using a KASSERT(). One exception of this rule is VOP_CLOSE() where NULL is used instead of curproc when the garbace collector of unix sockets, that runs in a kernel thread, drops the last reference of a file. This will allows for future simplifications of the VFS interfaces. Previous version ok visa@, anton@. ok kn@ |
|||
| date | 2020-10-07T13:37:32Z | |||
|---|---|---|---|---|
| author | jan | |||
| files | src/sys/arch/arm64/arm64/conf.c | log | diff | annotate |
| message |
Remove dead marko cdev_joy_init. ok mpi@, kettenis@, patrick@ |
|||
| date | 2020-10-07T13:37:33Z | |||
|---|---|---|---|---|
| author | jan | |||
| files | src/sys/arch/amd64/amd64/conf.c | log | diff | annotate |
| message |
Remove dead marko cdev_joy_init. ok mpi@, kettenis@, patrick@ |
|||
| date | 2020-10-07T15:45:00Z | |||
|---|---|---|---|---|
| author | cheloha | |||
| files | src/sys/kern/kern_time.c | log | diff | annotate |
| message |
getitimer(2), setitimer(2): merge critical sections Merge the common code from sys_getitimer() and sys_setitimer() into a new kernel subroutine, setitimer(). setitimer() performs all of the error-free work for both system calls within a single critical section. We need a single critical section to make the setitimer(2) timer swap operation atomic relative to realitexpire() and hardclock(9). The downside of the new atomicity is that the behavior of setitimer(2) must change. With a single critical section we can no longer copyout(9) the old timer before installing the new timer. So If SCARG(uap, oitv) points to invalid memory, setitimer(2) now fail with EFAULT but the new timer will be left running. You can see this in action with code like the following: struct itv, olditv; itv.it_value.tv_sec = 1; itv.it_value.tv_usec = 0; itv.it_interval = itv.it_value; /* This should EFAULT. 0x1 is probably an invalid address. */ if (setitimer(ITIMER_REAL, &itv, (void *)0x1) == -1) warn("setitimer"); /* The timer will be running anyway. */ getitimer(ITIMER_REAL, &olditv); printf("time left: %lld.%06ld\n", olditv.it_value.tv_sec, olditv.it_value.tv_usec); There is no easy way to work around this. Both FreeBSD's and Linux's setitimer(2) implementations have a single critical section and they too fail with EFAULT in this case and leave the new timer running. I imagine their developers decided that fixing this error case was a waste of effort. Without permitting copyout(9) from within a mutex I'm not sure it is even possible to avoid it on OpenBSD without sacrificing atomicity during a setitimer(2) timer swap. Given the rarity of this error case I would rather have an atomic swap. Behavior change discussed with deraadt@. |
|||
| date | 2020-10-07T16:17:25Z | |||
|---|---|---|---|---|
| author | cheloha | |||
| files | src/sys/kern/kern_time.c | log | diff | annotate |
| message |
getitimer(2), setitimer(2): ITIMER_REAL: call getnanouptime(9) once Now that the critical sections are merged we should call getnanouptime(9) once. This makes an ITIMER_REAL timer swap atomic with respect to the clock: the time remaining on the old timer is computed with the same timestamp used to schedule the new timer. |
|||
| date | 2020-10-07T17:53:44Z | |||
|---|---|---|---|---|
| author | cheloha | |||
| files | src/sys/kern/kern_time.c | log | diff | annotate |
| message |
sys_getitimer(), sys_setitimer(): style(9), misc. cleanup - Consolidate variable declarations. - Remove superfluous parentheses from return statements. - Prefer sizeof(variable) to sizeof(type) for copyin(9)/copyout(9). - Remove some intermediate pointers from sys_setitimer(). Using SCARG() directly here makes it more obvious to the reader what you're copying. |
|||