On Tue, Sep 01, 2020 at 10:24:11AM -0500, Scott Cheloha wrote:
> On Mon, Aug 17, 2020 at 05:55:34PM -0500, Scott Cheloha wrote:
> >
> > [...]
>
> Two week bump.
>
> In summary:
>
> - Merge the critical sections so that "timer swap" with setitimer(2)
> is atomic.
>
> - To do this, move error-
David Riley wrote:
> On Sep 25, 2020, at 3:13 PM, Todd C. Miller wrote:
> >
> > On Fri, 25 Sep 2020 13:58:01 -0500, Scott Cheloha wrote:
> >
> >> `found' serves as a boolean here. I'd prefer to simple and set it to
> >> 1 instead of incrementing it when we find what we're looking for.
> >
>
On Sep 25, 2020, at 3:13 PM, Todd C. Miller wrote:
>
> On Fri, 25 Sep 2020 13:58:01 -0500, Scott Cheloha wrote:
>
>> `found' serves as a boolean here. I'd prefer to simple and set it to
>> 1 instead of incrementing it when we find what we're looking for.
>
> Makes sense to me, the use of var++
We can't have 2 billion processes to reach a wrap.
But I agree, it seems quite wrong, and seems better to just observe
match rather than count.
Scott Cheloha wrote:
> `found' serves as a boolean here. I'd prefer to simple and set it to
> 1 instead of incrementing it when we find what we're lo
On Fri, 25 Sep 2020 13:58:01 -0500, Scott Cheloha wrote:
> `found' serves as a boolean here. I'd prefer to simple and set it to
> 1 instead of incrementing it when we find what we're looking for.
Makes sense to me, the use of var++ instead of var=1 is old-school
style ;-)
- todd
`found' serves as a boolean here. I'd prefer to simple and set it to
1 instead of incrementing it when we find what we're looking for.
ok?
Index: kern_resource.c
===
RCS file: /cvs/src/sys/kern/kern_resource.c,v
retrieving revision
This adds the magic numbers for powerpc64 to cut away the noise in
stack traces.
ok?
Index: dev/dt/dt_dev.c
===
RCS file: /cvs/src/sys/dev/dt/dt_dev.c,v
retrieving revision 1.9
diff -u -p -r1.9 dt_dev.c
--- dev/dt/dt_dev.c 13 Au
Mark Kettenis wrote:
> And as I implied, KASSERTs are no-ops in RAMDISK kernels so they don't
> stop things going horribly of the rails in that context, whereas a
> panic would still happen.
That's an important point, with big consequences.
Compile a RAMDISK, and the KASSERT gets removed. Also
> From: Scott Cheloha
> Date: Fri, 25 Sep 2020 09:48:20 -0400
>
> > On Sep 24, 2020, at 07:43, Theo de Raadt wrote:
> >
> > Mark Kettenis wrote:
> >
> >>> Date: Thu, 24 Sep 2020 11:53:59 +0200
> >>> From: Martin Pieuchot
> >>>
> >>> Convert various "if (x) panic()" idioms into "KASSERT(!x)
> On Sep 24, 2020, at 07:43, Theo de Raadt wrote:
>
> 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 reduc
Scott Cheloha wrote:
> Is there any scenario where
>
> if (condition)
> panic();
>
> is preferable to
>
> KASSERT(condition);
>
> outside of function calls with side effects?
Definately, sometimes you want to use simple english language for the
failure conditi
> Date: Fri, 25 Sep 2020 15:18:40 +0200
> From: Peter Hessler
>
> On 2020 Sep 25 (Fri) at 14:51:01 +0200 (+0200), Mark Kettenis wrote:
> :> Date: Fri, 25 Sep 2020 14:38:23 +0200
> :> From: Peter Hessler
> :>
> :> After Mark noticed that arm64 didn't have it, I checked armv7 and it
> :> also doe
On 2020 Sep 25 (Fri) at 14:51:01 +0200 (+0200), Mark Kettenis wrote:
:> Date: Fri, 25 Sep 2020 14:38:23 +0200
:> From: Peter Hessler
:>
:> After Mark noticed that arm64 didn't have it, I checked armv7 and it
:> also doesn't have it.
:>
:> Successfully tested on a Tinker-RK3288
:>
:> OK?
:>
:>
> Date: Fri, 25 Sep 2020 14:38:23 +0200
> From: Peter Hessler
>
> After Mark noticed that arm64 didn't have it, I checked armv7 and it
> also doesn't have it.
>
> Successfully tested on a Tinker-RK3288
>
> OK?
>
>
> Index: sys/arch/arm/arm/fault.c
> ===
After Mark noticed that arm64 didn't have it, I checked armv7 and it
also doesn't have it.
Successfully tested on a Tinker-RK3288
OK?
Index: sys/arch/arm/arm/fault.c
===
RCS file: /home/cvs/openbsd/src/sys/arch/arm/arm/fault.c,v
re
Introduce a new helper to check global variables that will need to be
protected from concurrent access.
The name is taken from NetBSD in order to reduce the difference between
our trees.
Diff below introduces a syntax change in uvmpd_scan() where the boolean
test "<" becomes "!=". This shouldn't
On 24/09/20(Thu) 16:35, Mark Kettenis wrote:
> 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 e
17 matches
Mail list logo
