Re: uvm_map_inentry() & KERNEL_LOCK()

Ted Unangst wrote: > Theo de Raadt wrote: > > In uvm_map_inentry_fix(), two variables in the map are now being read > > without a per-map read lock, this was previously protected by the > > kernel lock > > > > if (addr < map->min_offset || addr >= map->max_offset) > >

Re: uvm_map_inentry() & KERNEL_LOCK()

Theo de Raadt wrote: > In uvm_map_inentry_fix(), two variables in the map are now being read > without a per-map read lock, this was previously protected by the > kernel lock > > if (addr < map->min_offset || addr >= map->max_offset) > return (FALSE); > > When I wrote

Re: uvm_map_inentry() & KERNEL_LOCK()

In uvm_map_inentry_fix(), two variables in the map are now being read without a per-map read lock, this was previously protected by the kernel lock if (addr < map->min_offset || addr >= map->max_offset) return (FALSE); When I wrote this I was told to either use

uvm_map_inentry() & KERNEL_LOCK()

When a userland program triggers a fault or does a syscall its SP and/or PC are checked to be sure they are in expected regions. The result of this check is cached in the "struct proc" such that a lookup isn't always necessary. Currently when the cache is outdated the KERNEL_LOCK() is taken

_pbuild user to have priority=5

I suggest adding a priority=5 to _pbuild user. I tried on a macppc, a core 2 duo laptop and i7 laptop. It helped a lot the macppc and core2 to stay responsive on ssh or being barely usable while building. On the i7, the benefits are less. At best this allows firefox to stay responsive on bloated

Re: Opportunistic DoT for unwind(8)

Hi, So here's a new diff that incorporates the bug fix mentioned plus debug printf line changes suggested by Stuart. Please note that this is a diff on top of very recent current, i.e. florian's work he committed today. That means that you need to be up-to-date (including a recent libc update

[PATCH] Add new warning to useradd

Hi I think I found a scenario with useradd(8) where a warning would be nice. Given the following setup: foo# useradd test_user useradd: Warning: home directory `/home/test_user' doesn't exist, and -m was not specified foo# cat /etc/passwd cvs:*:1003:1003::/home/cvs:/bin/ksh

Re: iwm: add support for firmware paging

Hi Stefan, I tested it for dozen hours of YT streaming and usual web browsing. No issues observed. iwm0: hw rev 0x230, fw ver 22.361476.0, address e4:0e:ee:81:3d:a0 -- Krystian

Re: ix(4) need support for X553

On Thu, Oct 31, 2019 at 9:49 AM sven falempin wrote: > > > On Thu, Oct 31, 2019 at 9:17 AM Stuart Henderson > wrote: > >> On 2019/10/31 08:25, sven falempin wrote: >> > Thank you, the ./dev/pci/pcidevs_data.h, pcidevs.h are completly >> removed from this >> >> The pcidevs update is no longer

Re: acpivout(4): backlights without method to query current level

> Date: Thu, 31 Oct 2019 11:31:50 +0100 > From: Patrick Wildt > > Hi, > > some machines have no _BQC method, which is used to query the > current display backlight level. We can still work on those by > starting with the highest level (when there's no _BQC method) > and keeping track of the

OpenBGPD 6.6p0 released

We have released OpenBGPD 6.6p0, which will be arriving in the OpenBGPD directory of your local OpenBSD mirror soon. This is the first stable release for the 6.6 version. It includes the following changes: * Changed the Adj-RIB-Out to a per-peer set of RB trees, improving speed. *

Re: ix(4) need support for X553

On Thu, Oct 31, 2019 at 9:17 AM Stuart Henderson wrote: > On 2019/10/31 08:25, sven falempin wrote: > > Thank you, the ./dev/pci/pcidevs_data.h, pcidevs.h are completly > removed from this > > The pcidevs update is no longer needed since pcidevs r1.1889. > > > I may have time to test it against

Re: ix(4) need support for X553

On 2019/10/31 08:25, sven falempin wrote: > Thank you, the ./dev/pci/pcidevs_data.h,  pcidevs.h are completly removed > from this The pcidevs update is no longer needed since pcidevs r1.1889. > I may have time to test it against 6.6, see if it is still working since 6.4 > (where it was >

Re: Opportunistic DoT for unwind(8)

On Thu, Oct 31, 2019 at 10:04:07AM +, Stuart Henderson wrote: > Writing as a note to myself to check later when I have more time as > much as anything, is there a hold-off on re-checking if there is a > cert failure (or indeed if DoT port isn't answered), or does it > re-check for every query

Re: ix(4) need support for X553

On Wed, Oct 30, 2019 at 5:43 PM Stuart Henderson wrote: > On 2019/10/30 07:34, sven falempin wrote: > > https://github.com/dohnuts/wip/blob/master/ixgbe.diff > > > > Needs lots of cleaning > > > > On Wed, Oct 30, 2019 at 6:59 AM Joerg Goltermann wrote: > > > > > Hello, > > > > > > I have a new

acpivout(4): backlights without method to query current level

Hi, some machines have no _BQC method, which is used to query the current display backlight level. We can still work on those by starting with the highest level (when there's no _BQC method) and keeping track of the current level. Patrick diff --git a/sys/dev/acpi/acpivideo.c

Re: Opportunistic DoT for unwind(8)

On 2019/10/31 10:18, Otto Moerbeek wrote: > On Wed, Oct 30, 2019 at 08:51:00PM +, Stuart Henderson wrote: > > > - unwind doesn't have keepalives, so it's a new TCP session and TLS > > handshake for every query, which can be bad in some cases (and could get > > expensive with metered mobile

Re: Opportunistic DoT for unwind(8)

On Wed, Oct 30, 2019 at 08:51:00PM +, Stuart Henderson wrote: > On 2019/10/30 15:57, Otto Moerbeek wrote: > > Hi, > > > > I got *very* little feedback on this request for testing. > > > > If not enough enough testing is done, I'll either abandon the diff or > > commit it as-is, introducing

Re: Opportunistic DoT for unwind(8)

On Wed, Oct 30, 2019 at 11:46:36PM +0100, Remi Locherer wrote: > Hi Otto, > > On Wed, Oct 30, 2019 at 03:57:15PM +0100, Otto Moerbeek wrote: > > Hi, > > > > I got *very* little feedback on this request for testing. > > > > If not enough enough testing is done, I'll either abandon the diff or >