| created | 2019-06-12T22:44:53Z |
|---|---|
| begin | 2019-05-04T00:00:00Z |
| end | 2019-05-05T00:00:00Z |
| path | src/sys |
| commits | 13 |
| date | 2019-05-04T06:40:33Z | |||
|---|---|---|---|---|
| author | jmatthew | |||
| files | src/sys/dev/pci/files.pci | log | diff | annotate |
| src/sys/dev/pci/if_mcx.c | log | diff | annotate | |
| message |
Add mcx(4), a driver for Mellanox ConnectX-4 (and later) Ethernet controllers, written by dlg@ and me based on the cut down non-NDA programming reference manual Mellanox were nice enough to release. ok dlg@ deraadt@ |
|||
| date | 2019-05-04T07:55:31Z | |||
|---|---|---|---|---|
| author | jsg | |||
| files | src/sys/dev/pci/drm/drm_file.c | log | diff | annotate |
| message |
drm: Fix drm_release() and device unplug From Noralf Tronnes c5eb9a424ebd2d9f9e3cccdf2bfbb415c2921261 in linux 4.19.y/4.19.39 3f04e0a6cfebf48152ac64502346cdc258811f79 in mainline linux |
|||
| date | 2019-05-04T11:34:47Z | |||
|---|---|---|---|---|
| author | kettenis | |||
| files | src/sys/arch/amd64/amd64/efifb.c | log | diff | annotate |
| src/sys/arch/amd64/amd64/mainbus.c | log | diff | annotate | |
| src/sys/arch/amd64/conf/GENERIC | log | diff | annotate | |
| src/sys/arch/amd64/include/efifbvar.h | log | diff | annotate | |
| src/sys/arch/i386/conf/GENERIC | log | diff | annotate | |
| src/sys/conf/files | log | diff | annotate | |
| src/sys/dev/pci/drm/drm_drv.c | log | diff | annotate | |
| src/sys/dev/pci/drm/files.drm | log | diff | annotate | |
| src/sys/dev/pci/drm/i915/i915_drv.c | log | diff | annotate | |
| src/sys/dev/pci/drm/i915/i915_drv.h | log | diff | annotate | |
| message |
Improve the interaction between efifb(4), inteldrm(4) and radeondrm(4) when we have a serial console by introducing the notion of a "primary" graphics device. The primary graphics device is the one set up and used by firmware (BIOS, UEFI). The goal is to make sure that wsdisplay0 and drm0 reliably attach to the primary graphics device such that X works out of the box even if you have multiple cards or if you are using a serial console. This also fixes the situation where inteldrm(4) or radeondrm(4) would take over the console on UEFI systems even if the kernel was booted with a serial console. ok jsg@ |
|||
| date | 2019-05-04T11:34:48Z | |||
|---|---|---|---|---|
| author | kettenis | |||
| files | src/sys/dev/pci/drm/include/drm/drmP.h | log | diff | annotate |
| src/sys/dev/pci/drm/radeon/radeon.h | log | diff | annotate | |
| src/sys/dev/pci/drm/radeon/radeon_kms.c | log | diff | annotate | |
| src/sys/dev/wscons/wsdisplay.c | log | diff | annotate | |
| src/sys/dev/wscons/wsdisplayvar.h | log | diff | annotate | |
| message |
Improve the interaction between efifb(4), inteldrm(4) and radeondrm(4) when we have a serial console by introducing the notion of a "primary" graphics device. The primary graphics device is the one set up and used by firmware (BIOS, UEFI). The goal is to make sure that wsdisplay0 and drm0 reliably attach to the primary graphics device such that X works out of the box even if you have multiple cards or if you are using a serial console. This also fixes the situation where inteldrm(4) or radeondrm(4) would take over the console on UEFI systems even if the kernel was booted with a serial console. ok jsg@ |
|||
| date | 2019-05-04T13:37:47Z | |||
|---|---|---|---|---|
| author | jsg | |||
| files | src/sys/dev/pci/drm/i915/intel_bios.c | log | diff | annotate |
| message |
drm/i915/bios: assume eDP is present on port A when there is no VBT From Thomas Preston 6e0473633af059a559ce7b4cbaa51e389c94085e in mainline linux Makes inteldrm(4) work on James Hastings's 'HP Stream Laptop 14-cb1XX' a Gemini Lake system where finding the VBT fails. ok kettenis@ |
|||
| date | 2019-05-04T13:42:12Z | |||
|---|---|---|---|---|
| author | jsg | |||
| files | src/sys/dev/pci/if_ixl.c | log | diff | annotate |
| message |
fix array bounds check in ixl_search_link_speed() ok dlg@ |
|||
| date | 2019-05-04T14:42:44Z | |||
|---|---|---|---|---|
| author | mpi | |||
| files | src/sys/kern/kern_event.c | log | diff | annotate |
| message |
Relax the check in knote_{de,en}queue: don't panic w/o KERNEL_LOCK(). Use splassert_fail() instead, please set kern.splassert to 2 and report the corresponding stack trace if you see a warning. ok dlg@ |
|||
| date | 2019-05-04T14:52:45Z | |||
|---|---|---|---|---|
| author | mpi | |||
| files | src/sys/kern/kern_event.c | log | diff | annotate |
| message |
Removed all diagnostic, calling printf() here might create a recursion. Should be revisited once logwakeup() is fixed. |
|||
| date | 2019-05-04T15:38:12Z | |||
|---|---|---|---|---|
| author | deraadt | |||
| files | src/sys/ufs/ufs/dir.h | log | diff | annotate |
| message |
Add DIR_ROUNDUP define, from Kirk McKusick ok millert otto kettenis |
|||
| date | 2019-05-04T16:18:35Z | |||
|---|---|---|---|---|
| author | kettenis | |||
| files | src/sys/arch/arm64/include/asm.h | log | diff | annotate |
| message |
Remove some junk that we don't use. ok patrick@ |
|||
| date | 2019-05-04T17:14:12Z | |||
|---|---|---|---|---|
| author | kettenis | |||
| files | src/sys/dev/pci/drm/radeon/radeon_agp.c | log | diff | annotate |
| message |
Silence "Uunable to acquire AGP" message since we don't support AGP on all AGP-capable chipsets and probably never will. |
|||
| date | 2019-05-04T17:57:46Z | |||
|---|---|---|---|---|
| author | deraadt | |||
| files | src/sys/ufs/ufs/ufs_lookup.c | log | diff | annotate |
| message |
3 bytes of kernel stack address space were leaked into on-disk directories. With some gritty work up to 254 bytes can be discovered. More details at https://svnweb.freebsd.org/changeset/base/347066 The impact on OpenBSD is very limited: 1 - such stack bytes can be found in raw-device reads, from group operator. If you can read the raw disks you can undertake other more powerful actions. 2 - read(2) upon directory fd was disabled July 1997 because I didn't like how grep * would display garbage and mess up the tty, and applying vis(3) for just directory reads seemed silly. read(2) was changed to return 0 (EOF). Sep 2016 this was further changed to EISDIR, so you still cannot see the bad bytes. 3 - In 2013 when guenther adapted the getdents(2) directory-reading system call to 64-bit ino_t, the userland data format changed to 8-byte-alignment, making it incompatible with the 4-byte-alignment UFS on-disk format. As a result of code refactoring the bad bytes were not copied to userland. Bad bytes will remain in old directories on old filesystems, but nothing makes those bytes user visible. There will be no errata or syspatch issued. I urge other systems which do expose the information to userland to issue errata quickly, since this is a 254 byte infoleak of the stack which is great for ROP-chain building to attack some other bug. Especially if the kernel has no layout/link-order randomization ... ok kettenis jca millert otto ... |
|||
| date | 2019-05-04T17:59:40Z | |||
|---|---|---|---|---|
| author | deraadt | |||
| files | src/sys/arch/amd64/conf/GENERIC | log | diff | annotate |
| src/sys/arch/amd64/conf/RAMDISK_CD | log | diff | annotate | |
| message | let users try mcx(4) | |||