amap: panic -> KASSERT

Convert various "if (x) panic()" idioms into "KASSERT(!x)". The panic message isn't helping for such sanity checks and this help reducing the diff with NetBSD. ok? Index: uvm/uvm_amap.c === RCS file: /cvs/src/sys/uvm/uvm_amap.c,v re

Re: amap: panic -> KASSERT

> Date: Thu, 24 Sep 2020 11:53:59 +0200 > From: Martin Pieuchot > > Convert various "if (x) panic()" idioms into "KASSERT(!x)". The panic > message isn't helping for such sanity checks and this help reducing the > diff with NetBSD. > > ok? Yes, the KASSERTs are probably more useful for debuggi

Re: amap: panic -> KASSERT

Mark Kettenis wrote: > > Date: Thu, 24 Sep 2020 11:53:59 +0200 > > From: Martin Pieuchot > > > > Convert various "if (x) panic()" idioms into "KASSERT(!x)". The panic > > message isn't helping for such sanity checks and this help reducing the > > diff with NetBSD. > > > > ok? > > Yes, the KA

Push back kernel lock a bit in amd64 pageflttrap()

This avoids taking the kernel lock when ci_inatomic is set. This might speed up inteldrm(4) a bit. Since uvm_grow() still needs the kernel lock, some reorganization of the code is necessary. I'm not sure this actaully has an impact. If we end up here with ci_inatomic set we're going to return E

bsd.regress.mk REGRESS_SETUP vs REGRESS_SETUP_ONCE

Dear tech@, given the following Makefile: # REGRESS_SETUP vs REGRESS_SETUP_ONCE example setup: @echo setup setup_once: @echo setup_once test1: @echo test1 test2: @echo test2 cleanup: @echo cleanup REGRESS_SETUP = setup REGRESS_SETUP_ONCE =

Call uvm_grow() on powerpc64

The call is missing from the trap handler, probably because I was looking at arm64 where it is missing as well. The result is that the stack size accounting will be wrong. In the diff below I only added the call to the "data" trap. That means that an "instruction" trap will not run the accountin

Re: Call uvm_grow() on powerpc64

>The call is missing from the trap handler, probably because I was >looking at arm64 where it is missing as well. The result is that the >stack size accounting will be wrong. Nice find. >In the diff below I only added the call to the "data" trap. That >means that an "instruction" trap will not

Call uvm_grow() on arm64

As noted in the "Call uvm_grow() on powerpc64" mail, arm64 doesn't call it either. Diff below fixes that. ok? Index: arch/arm64/arm64/trap.c === RCS file: /cvs/src/sys/arch/arm64/arm64/trap.c,v retrieving revision 1.30 diff -u -p -

Re: apmd(8) and hw.perfpolicy quirks

On Wed, Sep 23 2020, "Ted Unangst" wrote: > On 2020-09-23, Jeremie Courreges-Anglas wrote: > >> ok? > > Seems fine. > > >> Note: I inlined the apmd(8)->apm(8) perfpolicy conversion for now, which >> brings a question. I find it weird that there is a special "high" >> perfpolicy (effectively simil

Re: Call uvm_grow() on powerpc64

> From: Theo de Raadt > Date: Thu, 24 Sep 2020 15:27:06 -0600 (MDT) > > >The call is missing from the trap handler, probably because I was > >looking at arm64 where it is missing as well. The result is that the > >stack size accounting will be wrong. > > Nice find. > > >In the diff below I onl

Re: Call uvm_grow() on powerpc64

>> From: Theo de Raadt >> Date: Thu, 24 Sep 2020 15:27:06 -0600 (MDT) >> >> >The call is missing from the trap handler, probably because I was >> >looking at arm64 where it is missing as well. The result is that the >> >stack size accounting will be wrong. >> >> Nice find. >> >> >In the diff b

Re: uvm_map_inentry() checks in trap()

> Repeating diffs from i386, amd64, sh. Improve alpha diff to handle an > additional fault case. Adding diffs for powerpc, powerc64, and m88k. The m88k diff is incomplete: - changes need to be done in both m88100_trap() and m88110_trap(). - the uvm_map_inentry() check should be put after the use