On Mon, Mar 22, 2021 at 08:18:45PM +0100, Klemens Nanni wrote:
> I was too stupid to look at `wsconsctl' output (which needs root) and
> only looked here.
>
> Mailing the diff for my lack of better wording, plus the knob atually
> takes three values which I have yet to decode by reading
So I've really wanted to try OpenBSD in a non-server configuration
where I'm not installing over the internet on a remote server but on
the local machine, but to my knowledge the OpenBSD installation media
has no accessibility functionality whatsoever. (I'm not even sure if
the installed system or
Hi,
By specifying an invalid offset when reading /dev/kmem it is easy
to crash the kernel from userland. sysctl kern.allowkmem=0 prevents
this per default
kernel: protection fault trap, code=0
Stopped at copyout+0x53: repe movsq (%rsi),%es:(%rdi)
ddb> trace
copyout() at copyout+0x53
On Mon, Mar 22, 2021 at 08:18:45PM +0100, Klemens Nanni wrote:
> I was too stupid to look at `wsconsctl' output (which needs root) and
> only looked here.
>
> Mailing the diff for my lack of better wording, plus the knob atually
> takes three values which I have yet to decode by reading
On 3/22/21 10:19 PM, Klemens Nanni wrote:
> On Mon, Mar 22, 2021 at 08:18:45PM +0100, Klemens Nanni wrote:
>> I was too stupid to look at `wsconsctl' output (which needs root) and
>> only looked here.
>>
>> Mailing the diff for my lack of better wording, plus the knob atually
>> takes three values
In the next version of Linux glibc, SIGSTKSZ is defined at runtime if
source is built with _GNU_SOURCE. On LibreSSL-portable, this is set to
bring in asprintf/vasprintf, which causes the explicit_bzero test to
fail to compile since the size of SIGSTKSZ is no longer known at compile
time. This
Fine with me.
The malloc'd memory is not identical to bss memory, but this still matches
the spirit of the test.
Brent Cook wrote:
> In the next version of Linux glibc, SIGSTKSZ is defined at runtime if
> source is built with _GNU_SOURCE. On LibreSSL-portable, this is set to
> bring in
On Fri, Mar 19, 2021 at 10:44:24AM +0100, Theo Buehler wrote:
> On Thu, Mar 18, 2021 at 05:06:53PM -0400, Dave Voutila wrote:
> >
> > Preben Guldberg writes:
> >
> > > In "vmctl status", VMs that are being stopped but are still running
> > > will simply show up as "running".
> > >
> > > The diff
I was too stupid to look at `wsconsctl' output (which needs root) and
only looked here.
Mailing the diff for my lack of better wording, plus the knob atually
takes three values which I have yet to decode by reading wsconsctl(8)
code.
Anyone with a better text for the example so grepping "mouse"
On Sun, Mar 21, 2021 at 10:58:02PM +, Raf Czlonka wrote:
>
> Hi Laurie,
>
> I'd simply use the existing wording, without getting into details.
>
> While there, "braces" dominate the manual page, with a single
> occurrence of "brackets" so let's change that too, for consistency.
>
>
On 2021/03/22 00:20, Martijn van Duren wrote:
> There's two things I'd like to know before going further with this:
>
> 1) according to RFC2578 section 3.6:
> (1) registration: the definition of a particular item is registered as
> a particular OBJECT IDENTIFIER value, and associated with a
Convert the last MI uvm_km_zalloc(9) to km_alloc(9), ok?
Index: uvm/uvm_page.c
===
RCS file: /cvs/src/sys/uvm/uvm_page.c,v
retrieving revision 1.155
diff -u -p -r1.155 uvm_page.c
--- uvm/uvm_page.c 19 Jan 2021 13:21:36 -
> On 21 Mar 2021, at 02:31, Theo de Raadt wrote:
> Otto Moerbeek wrote:
>> On Fri, Mar 19, 2021 at 04:15:31PM +, Stuart Henderson wrote:
>>
>>> On 2021/03/19 17:05, Jan Klemkow wrote:
Hi,
I had the same issue a few days ago a server hardware of mine. I just
ran 'cvs
The top frame is always `witness_checkorder', at least on amd64. Diff
below makes use of stacktrace_save_at() to skip it.
Previous output:
lock order ">lock"(rwlock) -> ">am_lock"(rwlock) first seen at:
#0 witness_checkorder+0x4d7 [/home/os/openbsd/sys/sys/stacktrace.h:0]
#1
Hi,
The following diff tries to simplify a bit the entanglement of namei
data and execve(2) syscall.
Currently, when called, sys_execve() might doing recursive calls of
check_exec() with a shared `struct nameidata' (`ep_ndp' inside
`struct exec_package').
I would like to disassociate them, and
> Date: Mon, 22 Mar 2021 11:27:40 +0100
> From: Martin Pieuchot
>
> Diff below convert a use of uvm_km_zalloc(9) to km_alloc(9), this memory
> is never released, ok?
This will need some careful testing on multiple architectures.
> Index: kern/kern_malloc.c
>
> Date: Mon, 22 Mar 2021 11:29:52 +0100
> From: Martin Pieuchot
>
> Convert the last MI uvm_km_zalloc(9) to km_alloc(9), ok?
Also needs some careful testing on multiple architectures.
> Index: uvm/uvm_page.c
> ===
> RCS file:
Diff below convert a use of uvm_km_zalloc(9) to km_alloc(9), this memory
is never released, ok?
Index: kern/kern_malloc.c
===
RCS file: /cvs/src/sys/kern/kern_malloc.c,v
retrieving revision 1.144
diff -u -p -r1.144 kern_malloc.c
---
> On 22 Mar 2021, at 14:27, Bryan Steele wrote:
> On Mon, Mar 22, 2021 at 01:47:18PM +0100, Mischa wrote:
>>
>>> On 22 Mar 2021, at 13:43, Stuart Henderson wrote:
>>>
> Created a fresh install qcow2 image and derived 35 new VMs from it.
> Then I started all the VMs in four cycles, 10
On Mon, Mar 22, 2021 at 07:08:32AM GMT, Jason McIntyre wrote:
> On Sun, Mar 21, 2021 at 10:58:02PM +, Raf Czlonka wrote:
> >
> > Hi Laurie,
> >
> > I'd simply use the existing wording, without getting into details.
> >
> > While there, "braces" dominate the manual page, with a single
> >
> > I'm more familiar with the vmd(8) codebase than any ffs stuff, but I
> > don't think the issue is the base image being r/w.
>
> AFAIKS, the issue is that if you start a vm modifying the base because it
> uses it as a regular image, that r/o open for the other vms does not
> matter a lot,
vmd
> Date: Sun, 21 Mar 2021 16:56:47 +0100
> From: Martin Pieuchot
>
> On 21/03/21(Sun) 13:42, Mark Kettenis wrote:
> > > Date: Sat, 20 Mar 2021 13:10:17 +0100
> > > From: Martin Pieuchot
> > >
> > > On SP systems, like bluhm@'s armv7 regression machine, the kern/ptrace2
> > > test is failing due
> > Created a fresh install qcow2 image and derived 35 new VMs from it.
> > Then I started all the VMs in four cycles, 10 VMs per cycle and waiting 240
> > seconds after each cycle.
> > Similar to the staggered start based on the amount of CPUs.
> For me this is not enough info to even try to
On Mon, Mar 22, 2021 at 01:47:18PM +0100, Mischa wrote:
>
>
> > On 22 Mar 2021, at 13:43, Stuart Henderson wrote:
> >
> >>> Created a fresh install qcow2 image and derived 35 new VMs from it.
> >>> Then I started all the VMs in four cycles, 10 VMs per cycle and waiting
> >>> 240 seconds after
> On 22 Mar 2021, at 14:30, Otto Moerbeek wrote:
> On Mon, Mar 22, 2021 at 01:47:18PM +0100, Mischa wrote:
>>> On 22 Mar 2021, at 13:43, Stuart Henderson wrote:
>>>
> Created a fresh install qcow2 image and derived 35 new VMs from it.
> Then I started all the VMs in four cycles, 10 VMs
On Mon, Mar 22, 2021 at 11:34:25AM +0100, Mischa wrote:
> > On 21 Mar 2021, at 02:31, Theo de Raadt wrote:
> > Otto Moerbeek wrote:
> >> On Fri, Mar 19, 2021 at 04:15:31PM +, Stuart Henderson wrote:
> >>
> >>> On 2021/03/19 17:05, Jan Klemkow wrote:
> Hi,
>
> I had the same
> On 22 Mar 2021, at 13:08, Otto Moerbeek wrote:
> On Mon, Mar 22, 2021 at 11:34:25AM +0100, Mischa wrote:
>
>>> On 21 Mar 2021, at 02:31, Theo de Raadt wrote:
>>> Otto Moerbeek wrote:
On Fri, Mar 19, 2021 at 04:15:31PM +, Stuart Henderson wrote:
> On 2021/03/19 17:05, Jan
On Mon, Mar 22, 2021 at 01:47:18PM +0100, Mischa wrote:
>
>
> > On 22 Mar 2021, at 13:43, Stuart Henderson wrote:
> >
> >>> Created a fresh install qcow2 image and derived 35 new VMs from it.
> >>> Then I started all the VMs in four cycles, 10 VMs per cycle and waiting
> >>> 240 seconds
On Mon, Mar 22, 2021 at 09:51:19AM -0400, Dave Voutila wrote:
>
> Otto Moerbeek writes:
>
> > On Mon, Mar 22, 2021 at 01:47:18PM +0100, Mischa wrote:
> >
> >>
> >>
> >> > On 22 Mar 2021, at 13:43, Stuart Henderson wrote:
> >> >
> >> >>> Created a fresh install qcow2 image and derived 35 new
> On 22 Mar 2021, at 13:43, Stuart Henderson wrote:
>
>>> Created a fresh install qcow2 image and derived 35 new VMs from it.
>>> Then I started all the VMs in four cycles, 10 VMs per cycle and waiting 240
>>> seconds after each cycle.
>>> Similar to the staggered start based on the amount
Otto Moerbeek writes:
> On Mon, Mar 22, 2021 at 01:47:18PM +0100, Mischa wrote:
>
>>
>>
>> > On 22 Mar 2021, at 13:43, Stuart Henderson wrote:
>> >
>> >>> Created a fresh install qcow2 image and derived 35 new VMs from it.
>> >>> Then I started all the VMs in four cycles, 10 VMs per cycle and
Otto Moerbeek writes:
> On Mon, Mar 22, 2021 at 09:51:19AM -0400, Dave Voutila wrote:
>
>>
>> Otto Moerbeek writes:
>>
>> > On Mon, Mar 22, 2021 at 01:47:18PM +0100, Mischa wrote:
>> >
>> >>
>> >>
>> >> > On 22 Mar 2021, at 13:43, Stuart Henderson wrote:
>> >> >
>> >> >>> Created a fresh
On Mon, Mar 22, 2021 at 03:06:40PM +0100, Mischa wrote:
> > On 22 Mar 2021, at 15:05, Dave Voutila wrote:
> > Otto Moerbeek writes:
> >> On Mon, Mar 22, 2021 at 09:51:19AM -0400, Dave Voutila wrote:
> >>> Otto Moerbeek writes:
> On Mon, Mar 22, 2021 at 01:47:18PM +0100, Mischa wrote:
>
On Mon, Mar 22, 2021 at 03:20:37PM +0100, Mischa wrote:
>
>
> > On 22 Mar 2021, at 15:18, Otto Moerbeek wrote:
> >
> > On Mon, Mar 22, 2021 at 03:06:40PM +0100, Mischa wrote:
> >
> >>> On 22 Mar 2021, at 15:05, Dave Voutila wrote:
> >>> Otto Moerbeek writes:
> On Mon, Mar 22, 2021 at
> On 22 Mar 2021, at 15:05, Dave Voutila wrote:
> Otto Moerbeek writes:
>> On Mon, Mar 22, 2021 at 09:51:19AM -0400, Dave Voutila wrote:
>>> Otto Moerbeek writes:
On Mon, Mar 22, 2021 at 01:47:18PM +0100, Mischa wrote:
>> On 22 Mar 2021, at 13:43, Stuart Henderson wrote:
>>
On Mon, Mar 22, 2021 at 01:59:17PM +, Stuart Henderson wrote:
> > > I'm more familiar with the vmd(8) codebase than any ffs stuff, but I
> > > don't think the issue is the base image being r/w.
> >
> > AFAIKS, the issue is that if you start a vm modifying the base because it
> > uses it as a
> On 22 Mar 2021, at 15:18, Otto Moerbeek wrote:
>
> On Mon, Mar 22, 2021 at 03:06:40PM +0100, Mischa wrote:
>
>>> On 22 Mar 2021, at 15:05, Dave Voutila wrote:
>>> Otto Moerbeek writes:
On Mon, Mar 22, 2021 at 09:51:19AM -0400, Dave Voutila wrote:
> Otto Moerbeek writes:
>> On
On Mon, Mar 22, 2021 at 01:33:34PM +, Raf Czlonka wrote:
> On Mon, Mar 22, 2021 at 07:08:32AM GMT, Jason McIntyre wrote:
> > On Sun, Mar 21, 2021 at 10:58:02PM +, Raf Czlonka wrote:
> > >
> > > Hi Laurie,
> > >
> > > I'd simply use the existing wording, without getting into details.
> >
> On 22 Mar 2021, at 15:23, Otto Moerbeek wrote:
> On Mon, Mar 22, 2021 at 03:20:37PM +0100, Mischa wrote:
>>> On 22 Mar 2021, at 15:18, Otto Moerbeek wrote:
>>> On Mon, Mar 22, 2021 at 03:06:40PM +0100, Mischa wrote:
>>>
> On 22 Mar 2021, at 15:05, Dave Voutila wrote:
> Otto Moerbeek
On Mon, Mar 22, 2021 at 06:19:14PM +0100, Mark Kettenis wrote:
> > @@ -167,7 +167,7 @@ cwfg_attach(struct device *parent, struc
> > free(batinfo, M_TEMP, len);
> >
> > sc->sc_monitor_interval = OF_getpropint(sc->sc_node,
> > - "cellwise,monitor-interval",
> Date: Mon, 22 Mar 2021 19:07:23 +0100
> From: Klemens Nanni
>
> On Mon, Mar 22, 2021 at 06:19:14PM +0100, Mark Kettenis wrote:
> > > @@ -167,7 +167,7 @@ cwfg_attach(struct device *parent, struc
> > > free(batinfo, M_TEMP, len);
> > >
> > > sc->sc_monitor_interval =
On Mon, Mar 22, 2021 at 05:48:56PM +0100, Klemens Nanni wrote:
> Using our dtb package's blobs cwfg(4) won't attach on the Pinebook Pro
> since linux changed it:
>
> https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/power/supply/cw2015_battery.yaml
>
> Thanks to
> Date: Mon, 22 Mar 2021 17:48:56 +0100
> From: Klemens Nanni
>
> Using our dtb package's blobs cwfg(4) won't attach on the Pinebook Pro
> since linux changed it:
>
> https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/power/supply/cw2015_battery.yaml
>
> Thanks to
Using our dtb package's blobs cwfg(4) won't attach on the Pinebook Pro
since linux changed it:
https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/power/supply/cw2015_battery.yaml
Thanks to kettenis and patrick for pointing this out.
This diff makes the sensor attach
Better diff at the end thanks to jca's eyeballing, see comments inline.
kettenis: I see room for improvement in our subsystems and their
interactions, but I don't think the current situation is bad enough to
leave those bits out for now.
Feedback? OK?
On Mon, Mar 22, 2021 at 01:21:02AM +0100,
45 matches
Mail list logo
