Re: Update bgpd.conf man to reflect ROA changes
On Wed, Oct 03, 2018 at 08:19:26AM +0200, Denis Fondras wrote:
> On Tue, Oct 02, 2018 at 09:13:47PM +0100, Jason McIntyre wrote:
> > On Tue, Oct 02, 2018 at 08:26:02PM +0200, Denis Fondras wrote:
> > > Reorder text and be more precise.
> > >
> > > Index: bgpd.conf.5
> > > ===
> > > RCS file: /cvs/src/usr.sbin/bgpd/bgpd.conf.5,v
> > > retrieving revision 1.178
> > > diff -u -p -r1.178 bgpd.conf.5
> > > --- bgpd.conf.5 9 Sep 2018 17:11:26 - 1.178
> > > +++ bgpd.conf.5 2 Oct 2018 18:25:17 -
> > > @@ -445,6 +445,21 @@ The default is
> > > .Ic ignore .
> > > .Pp
> > > .It Xo
> > > +.Ic roa-set
> > > +.Ic { Ar address Ns Li / Ns Ar len Ic maxlen Ar len Ic source-as Ar asn
> > > ... Ic }
> > > +.Xc
> > > +A
> > > +.Ic roa-set
> > > +holds a collection of Validated ROA Payload (VRP).
> >
> > hi.
> >
> > i'm unsure about the terminology exactly. but can you have a "collection
> > of payload"? doesn;t it have to be "payload data" or something?
> >
> > i think at least it needs to be plural (payloads). like, you wouldn;t
> > have a collection of bent umbrella. er, that's as an example..
> >
> > or you could remove "collection of".
> >
>
> Reading RFC6811 (page 4&5), I understand that Validated ROA Payload is one
> prefix in the list. Am I wrong ?
> Ok to make it plural though.
I think we should not use technical terms that are not self explanatory
but lets put this in now as a start. I agree with jmc@ that it should be
payloads (plural). Lets start with this.
OK claudio@
--
:wq Claudio
> > jmc
> >
> > > +Each received prefix is checked against the
> > > +.Ic roa-set
> > > +and the Origin Validation Status (OVS) is set.
> > > +.Bd -literal -offset indent
> > > +roa-set { 192.0.2.0/24 maxlen 24 source-as 64511
> > > + 203.0.113.0/24 source-as 64496 }
> > > +.Ed
> > > +.Pp
> > > +.It Xo
> > > .Ic route-collector
> > > .Pq Ic yes Ns | Ns Ic no
> > > .Xc
> > > @@ -1386,6 +1401,14 @@ can be set to
> > > in which case the nexthop is compared against the address of the
> > > neighbor.
> > > Nexthop filtering is not supported on locally announced networks and one
> > > must
> > > take into consideration previous rules overwriting nexthops.
> > > +.Pp
> > > +.It Xo
> > > +.Ic ovs
> > > +.Pq Ic valid | not-found | invalid
> > > +.Xc
> > > +This rule applies only to
> > > +.Em UPDATES
> > > +where the Origin Validation Status (OVS) matches.
> > > .Pp
> > > .It Ic prefix Ar address Ns Li / Ns Ar len
> > > .It Ic prefix Ar address Ns Li / Ns Ar len Ic prefixlen Ar range
> > >
> >
>
Re: Update bgpd.conf man to reflect ROA changes
On Wed, Oct 03, 2018 at 08:19:26AM +0200, Denis Fondras wrote:
> On Tue, Oct 02, 2018 at 09:13:47PM +0100, Jason McIntyre wrote:
> > On Tue, Oct 02, 2018 at 08:26:02PM +0200, Denis Fondras wrote:
> > > Reorder text and be more precise.
> > >
> > > Index: bgpd.conf.5
> > > ===
> > > RCS file: /cvs/src/usr.sbin/bgpd/bgpd.conf.5,v
> > > retrieving revision 1.178
> > > diff -u -p -r1.178 bgpd.conf.5
> > > --- bgpd.conf.5 9 Sep 2018 17:11:26 - 1.178
> > > +++ bgpd.conf.5 2 Oct 2018 18:25:17 -
> > > @@ -445,6 +445,21 @@ The default is
> > > .Ic ignore .
> > > .Pp
> > > .It Xo
> > > +.Ic roa-set
> > > +.Ic { Ar address Ns Li / Ns Ar len Ic maxlen Ar len Ic source-as Ar asn
> > > ... Ic }
> > > +.Xc
> > > +A
> > > +.Ic roa-set
> > > +holds a collection of Validated ROA Payload (VRP).
> >
> > hi.
> >
> > i'm unsure about the terminology exactly. but can you have a "collection
> > of payload"? doesn;t it have to be "payload data" or something?
> >
> > i think at least it needs to be plural (payloads). like, you wouldn;t
> > have a collection of bent umbrella. er, that's as an example..
> >
> > or you could remove "collection of".
> >
>
> Reading RFC6811 (page 4&5), I understand that Validated ROA Payload is one
> prefix in the list. Am I wrong ?
> Ok to make it plural though.
>
it reads fine as plural.
jmc
> > jmc
> >
> > > +Each received prefix is checked against the
> > > +.Ic roa-set
> > > +and the Origin Validation Status (OVS) is set.
> > > +.Bd -literal -offset indent
> > > +roa-set { 192.0.2.0/24 maxlen 24 source-as 64511
> > > + 203.0.113.0/24 source-as 64496 }
> > > +.Ed
> > > +.Pp
> > > +.It Xo
> > > .Ic route-collector
> > > .Pq Ic yes Ns | Ns Ic no
> > > .Xc
> > > @@ -1386,6 +1401,14 @@ can be set to
> > > in which case the nexthop is compared against the address of the
> > > neighbor.
> > > Nexthop filtering is not supported on locally announced networks and one
> > > must
> > > take into consideration previous rules overwriting nexthops.
> > > +.Pp
> > > +.It Xo
> > > +.Ic ovs
> > > +.Pq Ic valid | not-found | invalid
> > > +.Xc
> > > +This rule applies only to
> > > +.Em UPDATES
> > > +where the Origin Validation Status (OVS) matches.
> > > .Pp
> > > .It Ic prefix Ar address Ns Li / Ns Ar len
> > > .It Ic prefix Ar address Ns Li / Ns Ar len Ic prefixlen Ar range
> > >
> >
>
Re: Qcow2: External snapshots
On Tue, Oct 02, 2018 at 11:13:35PM -0700, Ori Bernstein wrote: > > Updated version. Changes from the last diff: > > - Merge in syntax changes. > - Don't over-read when getting the base images. > - Fix relative paths in base images. > - Allow multiple derived images to use a single base image, and allow a user > with only read permisssions to base their images on top of it. > - Probe the base image size, use/validate it when craeting disk images. > - Fix style a bit (long lines, changing from sizeof foo to sizeof(foo). > - Move a define out of vmmvar.h > - And update the manpage with these changes. > - Improve error checking around creating/resolving base disk paths. > morning. you should start new sentences on new lines - it forces a double spacing between sentences that all man pages have. if you run your proposed changes to man pages through "mandoc -Tlint", it will pick up on silly things like that. note there is also a double space in "Op Fl b" jmc > > diff --git usr.sbin/vmctl/vmctl.8 usr.sbin/vmctl/vmctl.8 > index f7890ac99f8..7a02452789c 100644 > --- usr.sbin/vmctl/vmctl.8 > +++ usr.sbin/vmctl/vmctl.8 > @@ -50,7 +50,7 @@ Using > .Xr cu 1 > connect to the console of the VM with the specified > .Ar id . > -.It Cm create Ar path Fl s Ar size > +.It Cm create Ar path Fl s Op Ar size Op Fl b Ar base > Creates a VM disk image file with the specified > .Ar path > and > @@ -65,7 +65,14 @@ or > in order to specify the disk format. > If left unspecified, the format defaults to > .Pa raw > -if it cannot be derived automatically. > +if it cannot be derived automatically. For qcow2, a > +.Ar base > +image may be specified. The base image is not modified. The derived image > +contains only the changes written by the VM. When creating a derived image, > +the > +.Ar size > +may be omitted, and probed from the base image. If it is provided, it must > +match the base image size. > .It Cm load Ar filename > Load additional configuration from the specified file. > .It Cm log brief
Re: Update bgpd.conf man to reflect ROA changes
On Tue, Oct 02, 2018 at 09:13:47PM +0100, Jason McIntyre wrote:
> On Tue, Oct 02, 2018 at 08:26:02PM +0200, Denis Fondras wrote:
> > Reorder text and be more precise.
> >
> > Index: bgpd.conf.5
> > ===
> > RCS file: /cvs/src/usr.sbin/bgpd/bgpd.conf.5,v
> > retrieving revision 1.178
> > diff -u -p -r1.178 bgpd.conf.5
> > --- bgpd.conf.5 9 Sep 2018 17:11:26 - 1.178
> > +++ bgpd.conf.5 2 Oct 2018 18:25:17 -
> > @@ -445,6 +445,21 @@ The default is
> > .Ic ignore .
> > .Pp
> > .It Xo
> > +.Ic roa-set
> > +.Ic { Ar address Ns Li / Ns Ar len Ic maxlen Ar len Ic source-as Ar asn
> > ... Ic }
> > +.Xc
> > +A
> > +.Ic roa-set
> > +holds a collection of Validated ROA Payload (VRP).
>
> hi.
>
> i'm unsure about the terminology exactly. but can you have a "collection
> of payload"? doesn;t it have to be "payload data" or something?
>
> i think at least it needs to be plural (payloads). like, you wouldn;t
> have a collection of bent umbrella. er, that's as an example..
>
> or you could remove "collection of".
>
Reading RFC6811 (page 4&5), I understand that Validated ROA Payload is one
prefix in the list. Am I wrong ?
Ok to make it plural though.
> jmc
>
> > +Each received prefix is checked against the
> > +.Ic roa-set
> > +and the Origin Validation Status (OVS) is set.
> > +.Bd -literal -offset indent
> > +roa-set { 192.0.2.0/24 maxlen 24 source-as 64511
> > + 203.0.113.0/24 source-as 64496 }
> > +.Ed
> > +.Pp
> > +.It Xo
> > .Ic route-collector
> > .Pq Ic yes Ns | Ns Ic no
> > .Xc
> > @@ -1386,6 +1401,14 @@ can be set to
> > in which case the nexthop is compared against the address of the neighbor.
> > Nexthop filtering is not supported on locally announced networks and one
> > must
> > take into consideration previous rules overwriting nexthops.
> > +.Pp
> > +.It Xo
> > +.Ic ovs
> > +.Pq Ic valid | not-found | invalid
> > +.Xc
> > +This rule applies only to
> > +.Em UPDATES
> > +where the Origin Validation Status (OVS) matches.
> > .Pp
> > .It Ic prefix Ar address Ns Li / Ns Ar len
> > .It Ic prefix Ar address Ns Li / Ns Ar len Ic prefixlen Ar range
> >
>
Re: Qcow2: External snapshots
On Mon, 1 Oct 2018 11:24:01 -0700, Ori Bernstein wrote:
> On Mon, 1 Oct 2018 12:55:12 +0200
> Reyk Floeter wrote:
>
> > Hi Ori,
> >
> > On Sun, Sep 30, 2018 at 12:27:00PM -0700, Ori Bernstein wrote:
> > > I've added support to vmd for external snapshots. That is,
> > > snapshots that are derived from a base image. Data lookups
> > > start in the derived image, and if the derived image does not
> > > contain some data, the search proceeds ot the base image.
> > > Multiple derived images may exist off of a single base image.
> > >
> >
> > Nice work! This will be quite useful, thanks.
> >
> > I think I broke your diff as my last commit to derive the raw/qcow2
> > format introduced some conflicts. I had posted it on hackers@ and
> > forgot that your aren't on the internal list yet - sorry for that.
Updated version. Changes from the last diff:
- Merge in syntax changes.
- Don't over-read when getting the base images.
- Fix relative paths in base images.
- Allow multiple derived images to use a single base image, and allow a user
with only read permisssions to base their images on top of it.
- Probe the base image size, use/validate it when craeting disk images.
- Fix style a bit (long lines, changing from sizeof foo to sizeof(foo).
- Move a define out of vmmvar.h
- And update the manpage with these changes.
- Improve error checking around creating/resolving base disk paths.
diff --git regress/usr.sbin/vmd/diskfmt/Makefile
regress/usr.sbin/vmd/diskfmt/Makefile
index c2a5f42d5f6..1f8673e0e26 100644
--- regress/usr.sbin/vmd/diskfmt/Makefile
+++ regress/usr.sbin/vmd/diskfmt/Makefile
@@ -11,7 +11,7 @@
VMD_DIR=$(BSDSRCDIR)/usr.sbin/vmd/
PROG=vioscribble
-SRCS=vioscribble.c $(VMD_DIR)/vioqcow2.c $(VMD_DIR)/vioraw.c
+SRCS=vioscribble.c vioqcow2.c vioraw.c
CFLAGS+=-I$(VMD_DIR) -pthread
LDFLAGS+=-pthread
@@ -26,3 +26,6 @@ scribble-images:
.PHONY: ${REGRESS_TARGETS} scribble-images
.include
+
+vioqcow2.c vioraw.c: $(VMD_DIR)/vioqcow2.c $(VMD_DIR)/vioraw.c
+ cp $(VMD_DIR)/vioqcow2.c $(VMD_DIR)/vioraw.c .
diff --git regress/usr.sbin/vmd/diskfmt/vioscribble.c
regress/usr.sbin/vmd/diskfmt/vioscribble.c
index 14d720db652..1da8efedac7 100644
--- regress/usr.sbin/vmd/diskfmt/vioscribble.c
+++ regress/usr.sbin/vmd/diskfmt/vioscribble.c
@@ -122,16 +122,18 @@ main(int argc, char **argv)
verbose = !!getenv("VERBOSE");
qcfd = open("scribble.qc2", O_RDWR);
rawfd = open("scribble.raw", O_RDWR);
- if (qcfd == -1 || virtio_init_qcow2(&qcowfile, &qcsz, qcfd) == -1)
+ if (qcfd == -1)
err(1, "unable to open qcow");
- if (rawfd == -1 || virtio_init_raw(&rawfile, &rawsz, rawfd) == -1)
+ if (virtio_init_qcow2(&qcowfile, &qcsz, &qcfd, 1) == -1)
+ err(1, "unable to init qcow");
+ if (rawfd == -1 || virtio_init_raw(&rawfile, &rawsz, &rawfd, 1) == -1)
err(1, "unable to open raw");
srandom_deterministic(123);
/* scribble to both disks */
printf("scribbling...\n");
- for (i = 0; i < 16; i++) {
+ for (i = 0; i < 1024*16; i++) {
off = (random() % DISKSZ);
len = random() % sizeof buf + 1;
fill(off, buf, sizeof buf);
diff --git usr.sbin/vmctl/main.c usr.sbin/vmctl/main.c
index 8748ecfdedc..4637256452b 100644
--- usr.sbin/vmctl/main.c
+++ usr.sbin/vmctl/main.c
@@ -67,7 +67,8 @@ intctl_receive(struct parse_result *, int, char
*[]);
struct ctl_command ctl_commands[] = {
{ "console",CMD_CONSOLE,ctl_console,"id" },
- { "create", CMD_CREATE, ctl_create, "\"path\" -s size", 1 },
+ { "create", CMD_CREATE, ctl_create,
+ "\"path\" [-s size] [-b base]", 1 },
{ "load", CMD_LOAD, ctl_load, "\"path\"" },
{ "log",CMD_LOG,ctl_log,"[verbose|brief]" },
{ "reload", CMD_RELOAD, ctl_reload, "" },
@@ -538,47 +539,54 @@ int
ctl_create(struct parse_result *res, int argc, char *argv[])
{
int ch, ret, type;
- const char *paths[2], *disk, *format;
+ const char *disk, *format, *base;
if (argc < 2)
ctl_usage(res->ctl);
+ base = NULL;
type = parse_disktype(argv[1], &disk);
- paths[0] = disk;
- paths[1] = NULL;
-
- if (unveil(paths[0], "rwc") == -1)
+ if (unveil(disk, "rwc") == -1)
err(1, "unveil");
- if (pledge("stdio rpath wpath cpath", NULL) == -1)
- err(1, "pledge");
argc--;
argv++;
- while ((ch = getopt(argc, argv, "s:")) != -1) {
+ while ((ch = getopt(argc, argv, "s:b:")) != -1) {
switch (ch) {
case 's':
if (parse_size(res, optarg, 0) != 0)
errx(1, "invalid size: %s", optarg);
break;
+ case 'b
Re: Crash in vm_terminate > vm_teardown > uvm_map_deallocate > uvm_unmap_remove
On Tue, Oct 02, 2018 at 08:21:39PM -0700, Greg Steuck wrote: > > Oh, if this is the issue then it's not "spinning". > > This is a different issue. This is a host crash rather than VMs getting > lost. > I'll give an update when I catch the spin. In the meantime, did the logs > describe the GCP environment in sufficient detail? > > > And this bug is a known issue, I just haven't had a chance to fix it yet. > > Maybe this weekend. > > Excellent, happy to test it. Though I have no recipe to reproduce the issue. > > Thanks > Greg > -- > nest.cx is Gmail hosted, use PGP for anything private. Key: > http://goo.gl/6dMsr > Fingerprint: 5E2B 2D0E 1E03 2046 BEC3 4D50 0B15 42BD 8DF5 A1B0 I've been told it happens in scenarios like yours ; lots of creates and teardowns in rapid succession. -ml
Re: Crash in vm_terminate > vm_teardown > uvm_map_deallocate > uvm_unmap_remove
> Oh, if this is the issue then it's not "spinning". This is a different issue. This is a host crash rather than VMs getting lost. I'll give an update when I catch the spin. In the meantime, did the logs describe the GCP environment in sufficient detail? > And this bug is a known issue, I just haven't had a chance to fix it yet. > Maybe this weekend. Excellent, happy to test it. Though I have no recipe to reproduce the issue. Thanks Greg -- nest.cx is Gmail hosted, use PGP for anything private. Key: http://goo.gl/6dMsr Fingerprint: 5E2B 2D0E 1E03 2046 BEC3 4D50 0B15 42BD 8DF5 A1B0
Re: Crash in vm_terminate > vm_teardown > uvm_map_deallocate > uvm_unmap_remove
On Tue, Oct 02, 2018 at 07:35:29PM -0700, Greg Steuck wrote: > We got "lucky" in a different way after enabling VMM_DEBUG. I captured some > details of a > crash. The fault address seems to be vm_map(=0x80b44200) + 0x100. > > The kernel is built with this config: > ci-openbsd$ cat /syzkaller/src/sys/arch/amd64/conf/VMM_DEBUG > include "arch/amd64/conf/GENERIC.MP" > option VMM_DEBUG > Oh, if this is the issue then it's not "spinning". And this bug is a known issue, I just haven't had a chance to fix it yet. Maybe this weekend. -ml > Still this commit: > commit 44df374beffdeeab308e9c219092e1c860fc97a9 (HEAD) > > Author: kevlo > Date: Tue Oct 2 02:05:34 2018 + > > Add support for RT3290 chipset by James Hastings. > > > Tested by me and James Hastings. > > Logs: > > SeaBIOS (version 1.8.2-20171012_061934-google) > Total RAM Size = 0x0004 = 16384 MiB > CPUs found: 8 Max CPUs supported: 8 > found virtio-scsi at 0:3 > virtio-scsi vendor='Google' product='PersistentDisk' rev='1' type=0 > removable=0 > virtio-scsi blksize=512 sectors=20971520 = 10240 MiB > virtio-scsi vendor='Google' product='PersistentDisk' rev='1' type=0 > removable=0 > virtio-scsi blksize=512 sectors=2097152000 = 1024000 MiB > drive 0x000f2bc0: PCHS=0/0/0 translation=lba LCHS=1024/255/63 s=20971520 > drive 0x000f2b80: PCHS=0/0/0 translation=lba LCHS=1024/255/63 s=2097152000 > Booting from Hard Disk 0... > >> OpenBSD/amd64 BOOT 3.41 > boot> > [ using 2143328 bytes of bsd ELF symbol table ] > Copyright (c) 1982, 1986, 1989, 1991, 1993 > The Regents of the University of California. All rights reserved. > Copyright (c) 1995-2018 OpenBSD. All rights reserved. > https://www.OpenBSD.org > > OpenBSD 6.4 (VMM_DEBUG) #0: Tue Oct 2 10:37:13 PDT 2018 > syzkaller@ci-openbsd.syzkaller > :/syzkaller/src/sys/arch/amd64/compile/VMM_DEBUG > real mem = 17163079680 (16367MB) > avail mem = 16633610240 (15863MB) > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xbcf0 (20 entries) > bios0: vendor Google version "Google" date 01/01/2011 > bios0: Google Google Compute Engine > acpi0 at bios0: rev 0 > acpi0: sleep states S3 S4 S5 > acpi0: tables DSDT FACP SSDT APIC WAET SRAT > acpi0: wakeup devices > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Intel(R) Xeon(R) CPU @ 2.30GHz, 2300.55 MHz, 06-3f-00 > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,VMX,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,XSAVEOPT,MELTDOWN > cpu0: 256KB 64b/line 8-way L2 cache > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges > cpu0: apic clock running at 990MHz > cpu1 at mainbus0: apid 2 (application processor) > cpu1: Intel(R) Xeon(R) CPU @ 2.30GHz, 2276.88 MHz, 06-3f-00 > cpu1: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,VMX,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,XSAVEOPT,MELTDOWN > cpu1: 256KB 64b/line 8-way L2 cache > cpu1: smt 0, core 1, package 0 > cpu2 at mainbus0: apid 4 (application processor) > cpu2: Intel(R) Xeon(R) CPU @ 2.30GHz, 2276.87 MHz, 06-3f-00 > cpu2: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,VMX,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,XSAVEOPT,MELTDOWN > cpu2: 256KB 64b/line 8-way L2 cache > cpu2: smt 0, core 2, package 0 > cpu3 at mainbus0: apid 6 (application processor) > cpu3: Intel(R) Xeon(R) CPU @ 2.30GHz, 2276.89 MHz, 06-3f-00 > cpu3: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,VMX,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,XSAVEOPT,MELTDOWN > cpu3: 256KB 64b/line 8-way L2 cache > cpu3: smt 0, core 3, package 0 > cpu4 at mainbus0: apid 1 (application processor) > cpu4: Intel(R) Xeon(R) CPU @ 2.30GHz, 2276.88 MHz, 06-3f-00 > cpu4: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,VMX,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,XSAVEOPT,MELTDOWN > cpu4: 256KB 64b/line 8-way L2 cache > cpu4: smt 1, core 0, package 0 > cpu5 at mainbus0: apid 3 (applicat
Re: vmd losing VMs
On Tue, Oct 02, 2018 at 11:02:57AM -0700, Greg Steuck wrote: > Dmitry, is there an easy way get at the VMs output? > > Here's dmesg from VMM_DEBUG-enabled kernel (built at "Add support for > RT3290 chipset by James Hastings."). No lockup thus far. > Yeah the output below shows normal behaviour. Probably a similar issue to the one reported a while back, but for that case, vmd just went away (not spinning). -ml > OpenBSD 6.4 (VMM_DEBUG) #0: Tue Oct 2 10:37:13 PDT 2018 > syzkaller@ci-openbsd.syzkaller > :/syzkaller/src/sys/arch/amd64/compile/VMM_DEBUG > real mem = 17163079680 (16367MB) > avail mem = 16633610240 (15863MB) > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xbcf0 (20 entries) > bios0: vendor Google version "Google" date 01/01/2011 > bios0: Google Google Compute Engine > acpi0 at bios0: rev 0 > acpi0: sleep states S3 S4 S5 > acpi0: tables DSDT FACP SSDT APIC WAET SRAT > acpi0: wakeup devices > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Intel(R) Xeon(R) CPU @ 2.30GHz, 2300.55 MHz, 06-3f-00 > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,VMX,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,XSAVEOPT,MELTDOWN > cpu0: 256KB 64b/line 8-way L2 cache > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges > cpu0: apic clock running at 990MHz > cpu1 at mainbus0: apid 2 (application processor) > cpu1: Intel(R) Xeon(R) CPU @ 2.30GHz, 2276.88 MHz, 06-3f-00 > cpu1: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,VMX,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,XSAVEOPT,MELTDOWN > cpu1: 256KB 64b/line 8-way L2 cache > cpu1: smt 0, core 1, package 0 > cpu2 at mainbus0: apid 4 (application processor) > cpu2: Intel(R) Xeon(R) CPU @ 2.30GHz, 2276.87 MHz, 06-3f-00 > cpu2: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,VMX,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,XSAVEOPT,MELTDOWN > cpu2: 256KB 64b/line 8-way L2 cache > cpu2: smt 0, core 2, package 0 > cpu3 at mainbus0: apid 6 (application processor) > cpu3: Intel(R) Xeon(R) CPU @ 2.30GHz, 2276.89 MHz, 06-3f-00 > cpu3: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,VMX,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,XSAVEOPT,MELTDOWN > cpu3: 256KB 64b/line 8-way L2 cache > cpu3: smt 0, core 3, package 0 > cpu4 at mainbus0: apid 1 (application processor) > cpu4: Intel(R) Xeon(R) CPU @ 2.30GHz, 2276.88 MHz, 06-3f-00 > cpu4: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,VMX,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,XSAVEOPT,MELTDOWN > cpu4: 256KB 64b/line 8-way L2 cache > cpu4: smt 1, core 0, package 0 > cpu5 at mainbus0: apid 3 (application processor) > cpu5: Intel(R) Xeon(R) CPU @ 2.30GHz, 2276.88 MHz, 06-3f-00 > cpu5: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,VMX,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,XSAVEOPT,MELTDOWN > cpu5: 256KB 64b/line 8-way L2 cache > cpu5: smt 1, core 1, package 0 > cpu6 at mainbus0: apid 5 (application processor) > cpu6: Intel(R) Xeon(R) CPU @ 2.30GHz, 2276.94 MHz, 06-3f-00 > cpu6: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,VMX,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,XSAVEOPT,MELTDOWN > cpu6: 256KB 64b/line 8-way L2 cache > cpu6: smt 1, core 2, package 0 > cpu7 at mainbus0: apid 7 (application processor) > cpu7: Intel(R) Xeon(R) CPU @ 2.30GHz, 2276.91 MHz, 06-3f-00 > cpu7: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,VMX,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG
Crash in vm_terminate > vm_teardown > uvm_map_deallocate > uvm_unmap_remove
We got "lucky" in a different way after enabling VMM_DEBUG. I captured some details of a crash. The fault address seems to be vm_map(=0x80b44200) + 0x100. The kernel is built with this config: ci-openbsd$ cat /syzkaller/src/sys/arch/amd64/conf/VMM_DEBUG include "arch/amd64/conf/GENERIC.MP" option VMM_DEBUG Still this commit: commit 44df374beffdeeab308e9c219092e1c860fc97a9 (HEAD) Author: kevlo Date: Tue Oct 2 02:05:34 2018 + Add support for RT3290 chipset by James Hastings. Tested by me and James Hastings. Logs: SeaBIOS (version 1.8.2-20171012_061934-google) Total RAM Size = 0x0004 = 16384 MiB CPUs found: 8 Max CPUs supported: 8 found virtio-scsi at 0:3 virtio-scsi vendor='Google' product='PersistentDisk' rev='1' type=0 removable=0 virtio-scsi blksize=512 sectors=20971520 = 10240 MiB virtio-scsi vendor='Google' product='PersistentDisk' rev='1' type=0 removable=0 virtio-scsi blksize=512 sectors=2097152000 = 1024000 MiB drive 0x000f2bc0: PCHS=0/0/0 translation=lba LCHS=1024/255/63 s=20971520 drive 0x000f2b80: PCHS=0/0/0 translation=lba LCHS=1024/255/63 s=2097152000 Booting from Hard Disk 0... >> OpenBSD/amd64 BOOT 3.41 boot> [ using 2143328 bytes of bsd ELF symbol table ] Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2018 OpenBSD. All rights reserved. https://www.OpenBSD.org OpenBSD 6.4 (VMM_DEBUG) #0: Tue Oct 2 10:37:13 PDT 2018 syzkaller@ci-openbsd.syzkaller :/syzkaller/src/sys/arch/amd64/compile/VMM_DEBUG real mem = 17163079680 (16367MB) avail mem = 16633610240 (15863MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xbcf0 (20 entries) bios0: vendor Google version "Google" date 01/01/2011 bios0: Google Google Compute Engine acpi0 at bios0: rev 0 acpi0: sleep states S3 S4 S5 acpi0: tables DSDT FACP SSDT APIC WAET SRAT acpi0: wakeup devices acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) CPU @ 2.30GHz, 2300.55 MHz, 06-3f-00 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,VMX,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,XSAVEOPT,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 990MHz cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Xeon(R) CPU @ 2.30GHz, 2276.88 MHz, 06-3f-00 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,VMX,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,XSAVEOPT,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Xeon(R) CPU @ 2.30GHz, 2276.87 MHz, 06-3f-00 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,VMX,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,XSAVEOPT,MELTDOWN cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Xeon(R) CPU @ 2.30GHz, 2276.89 MHz, 06-3f-00 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,VMX,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,XSAVEOPT,MELTDOWN cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 0, core 3, package 0 cpu4 at mainbus0: apid 1 (application processor) cpu4: Intel(R) Xeon(R) CPU @ 2.30GHz, 2276.88 MHz, 06-3f-00 cpu4: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,VMX,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,XSAVEOPT,MELTDOWN cpu4: 256KB 64b/line 8-way L2 cache cpu4: smt 1, core 0, package 0 cpu5 at mainbus0: apid 3 (application processor) cpu5: Intel(R) Xeon(R) CPU @ 2.30GHz, 2276.88 MHz, 06-3f-00 cpu5: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,VMX,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,XSAVEOPT,MELTDOWN cpu5: 256KB 64b/l
Re: [patch] remove uuid implementation in ldapd
William Orr writes:
> Hey,
>
> In looking through uuid generation situations on various
> bsd's, I noticed that there's an additional implemetation
> of uuid generation in ldapd. This one appears to generate
> version 1 uuid's, which afaict from reading RFC 4530 isn't
> a requirement for a compliant ldap implementation.
>
> The following replaces it with the implementation in libc.
>
> I tested by loading up ldapd, adding entries, then querying
> for their `entryUUID` fields and verifying that they were
> version 4 uuids instead of version 1.
>
> Thanks!!
My bad, there was a missing `free(3)`. Correct patch follows.
Index: Makefile
===
RCS file: /cvs/src/usr.sbin/ldapd/Makefile,v
retrieving revision 1.15
diff -u -p -r1.15 Makefile
--- Makefile20 Jan 2017 11:55:08 - 1.15
+++ Makefile3 Oct 2018 01:42:25 -
@@ -6,7 +6,7 @@ SRCS= ber.c log.c logmsg.c control.c \
util.c ldapd.c ldape.c conn.c attributes.c namespace.c \
btree.c filter.c search.c parse.y \
auth.c modify.c index.c evbuffer_tls.c \
- validate.c uuid.c schema.c imsgev.c syntax.c matching.c
+ validate.c schema.c imsgev.c syntax.c matching.c
LDADD= -levent -ltls -lssl -lcrypto -lz -lutil
DPADD= ${LIBEVENT} ${LIBTLS} ${LIBSSL} ${LIBCRYPTO} ${LIBZ} ${LIBUTIL}
Index: modify.c
===
RCS file: /cvs/src/usr.sbin/ldapd/modify.c,v
retrieving revision 1.21
diff -u -p -r1.21 modify.c
--- modify.c14 May 2018 07:53:47 - 1.21
+++ modify.c3 Oct 2018 01:42:25 -
@@ -23,10 +23,10 @@
#include
#include
#include
+#include
#include "ldapd.h"
#include "log.h"
-#include "uuid.h"
int
ldap_delete(struct request *req)
@@ -123,8 +123,9 @@ done:
int
ldap_add(struct request *req)
{
- char uuid_str[64];
- struct uuid uuid;
+ char*uuid_str = NULL;
+ uuid_t uuid;
+ uint32_tuuid_status;
char*dn, *s;
struct attr_type*at;
struct ber_element *attrs, *attr, *elm, *set = NULL;
@@ -204,8 +205,12 @@ ldap_add(struct request *req)
if (ldap_add_attribute(attrs, "createTimestamp", set) == NULL)
goto fail;
- uuid_create(&uuid);
- uuid_to_string(&uuid, uuid_str, sizeof(uuid_str));
+ uuid_create(&uuid, &uuid_status);
+ if (uuid_status != uuid_s_ok)
+ goto fail;
+ uuid_to_string(&uuid, &uuid_str, &uuid_status);
+ if (uuid_status != uuid_s_ok)
+ goto fail;
if ((set = ber_add_set(NULL)) == NULL)
goto fail;
if (ber_add_string(set, uuid_str) == NULL)
@@ -223,9 +228,11 @@ ldap_add(struct request *req)
} else if (namespace_commit(ns) != 0)
rc = LDAP_OTHER;
+ free(uuid_str);
return ldap_respond(req, rc);
fail:
+ free(uuid_str);
if (set != NULL)
ber_free_elements(set);
namespace_abort(ns);
Index: syntax.c
===
RCS file: /cvs/src/usr.sbin/ldapd/syntax.c,v
retrieving revision 1.5
diff -u -p -r1.5 syntax.c
--- syntax.c28 May 2017 15:48:49 - 1.5
+++ syntax.c3 Oct 2018 01:42:25 -
@@ -26,7 +26,6 @@
#include
#include "schema.h"
-#include "uuid.h"
#define SYNTAX_DECL(TYPE) \
static int syntax_is_##TYPE(struct schema *schema, char *value, size_t
len)
Index: uuid.c
===
RCS file: uuid.c
diff -N uuid.c
--- uuid.c 26 Apr 2018 12:42:51 - 1.6
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,257 +0,0 @@
-/* $OpenBSD: uuid.c,v 1.6 2018/04/26 12:42:51 guenther Exp $ */
-/*
- * Copyright (c) 2002, Stockholms Universitet
- * (Stockholm University, Stockholm Sweden)
- * All rights reserved.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- *
- * 1. Redistributions of source code must retain the above copyright
- *notice, this list of conditions and the following disclaimer.
- *
- * 2. Redistributions in binary form must reproduce the above copyright
- *notice, this list of conditions and the following disclaimer in the
- *documentation and/or other materials provided with the distribution.
- *
- * 3. Neither the name of the university nor the names of its contributors
- *may be used to endorse or promote products derived from this software
- *without specific prior written permission.
- *
- * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
- * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- * IMPLIED WARRA
[patch] remove uuid implementation in ldapd
Hey,
In looking through uuid generation situations on various
bsd's, I noticed that there's an additional implemetation
of uuid generation in ldapd. This one appears to generate
version 1 uuid's, which afaict from reading RFC 4530 isn't
a requirement for a compliant ldap implementation.
The following replaces it with the implementation in libc.
I tested by loading up ldapd, adding entries, then querying
for their `entryUUID` fields and verifying that they were
version 4 uuids instead of version 1.
Thanks!!
Index: Makefile
===
RCS file: /cvs/src/usr.sbin/ldapd/Makefile,v
retrieving revision 1.15
diff -u -p -r1.15 Makefile
--- Makefile20 Jan 2017 11:55:08 - 1.15
+++ Makefile3 Oct 2018 01:02:03 -
@@ -6,7 +6,7 @@ SRCS= ber.c log.c logmsg.c control.c \
util.c ldapd.c ldape.c conn.c attributes.c namespace.c \
btree.c filter.c search.c parse.y \
auth.c modify.c index.c evbuffer_tls.c \
- validate.c uuid.c schema.c imsgev.c syntax.c matching.c
+ validate.c schema.c imsgev.c syntax.c matching.c
LDADD= -levent -ltls -lssl -lcrypto -lz -lutil
DPADD= ${LIBEVENT} ${LIBTLS} ${LIBSSL} ${LIBCRYPTO} ${LIBZ} ${LIBUTIL}
Index: modify.c
===
RCS file: /cvs/src/usr.sbin/ldapd/modify.c,v
retrieving revision 1.21
diff -u -p -r1.21 modify.c
--- modify.c14 May 2018 07:53:47 - 1.21
+++ modify.c3 Oct 2018 01:02:03 -
@@ -23,10 +23,10 @@
#include
#include
#include
+#include
#include "ldapd.h"
#include "log.h"
-#include "uuid.h"
int
ldap_delete(struct request *req)
@@ -123,8 +123,9 @@ done:
int
ldap_add(struct request *req)
{
- char uuid_str[64];
- struct uuid uuid;
+ char*uuid_str = NULL;
+ uuid_t uuid;
+ uint32_tuuid_status;
char*dn, *s;
struct attr_type*at;
struct ber_element *attrs, *attr, *elm, *set = NULL;
@@ -204,8 +205,12 @@ ldap_add(struct request *req)
if (ldap_add_attribute(attrs, "createTimestamp", set) == NULL)
goto fail;
- uuid_create(&uuid);
- uuid_to_string(&uuid, uuid_str, sizeof(uuid_str));
+ uuid_create(&uuid, &uuid_status);
+ if (uuid_status != uuid_s_ok)
+ goto fail;
+ uuid_to_string(&uuid, &uuid_str, &uuid_status);
+ if (uuid_status != uuid_s_ok)
+ goto fail;
if ((set = ber_add_set(NULL)) == NULL)
goto fail;
if (ber_add_string(set, uuid_str) == NULL)
@@ -226,6 +231,7 @@ ldap_add(struct request *req)
return ldap_respond(req, rc);
fail:
+ free(uuid_str);
if (set != NULL)
ber_free_elements(set);
namespace_abort(ns);
Index: syntax.c
===
RCS file: /cvs/src/usr.sbin/ldapd/syntax.c,v
retrieving revision 1.5
diff -u -p -r1.5 syntax.c
--- syntax.c28 May 2017 15:48:49 - 1.5
+++ syntax.c3 Oct 2018 01:02:03 -
@@ -26,7 +26,6 @@
#include
#include "schema.h"
-#include "uuid.h"
#define SYNTAX_DECL(TYPE) \
static int syntax_is_##TYPE(struct schema *schema, char *value, size_t
len)
Index: uuid.c
===
RCS file: uuid.c
diff -N uuid.c
--- uuid.c 26 Apr 2018 12:42:51 - 1.6
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,257 +0,0 @@
-/* $OpenBSD: uuid.c,v 1.6 2018/04/26 12:42:51 guenther Exp $ */
-/*
- * Copyright (c) 2002, Stockholms Universitet
- * (Stockholm University, Stockholm Sweden)
- * All rights reserved.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- *
- * 1. Redistributions of source code must retain the above copyright
- *notice, this list of conditions and the following disclaimer.
- *
- * 2. Redistributions in binary form must reproduce the above copyright
- *notice, this list of conditions and the following disclaimer in the
- *documentation and/or other materials provided with the distribution.
- *
- * 3. Neither the name of the university nor the names of its contributors
- *may be used to endorse or promote products derived from this software
- *without specific prior written permission.
- *
- * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
- * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
- * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
- * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
- * CO
Re: pfsync: avoid a recursion on PF_LOCK
On Tue, Oct 02, 2018 at 01:14:16AM +0200, Alexander Bluhm wrote:
> On Thu, Sep 27, 2018 at 06:34:45PM +0200, Alexandr Nedvedicky wrote:
> > OK to pfsync change?
>
> OK bluhm@, just two style nits
>
> > + if ((e = ip_output(m, NULL, NULL, IP_RAWOUTPUT, &sc->sc_imo,
> > + NULL, 0)) == 0)
>
> Usually we call the error variable "error".
>
> > + if (mq_enqueue(&pfsync_mq, m) != 0) {
> > + pfsyncstat_inc(pfsyncs_oerrors);
> > + DPFPRINTF(LOG_DEBUG, "mq_enqueue() @ %s failed, queue full\n",
> > + __func__);
> > + }
> > + else
>
> The } and else should be on the same line.
thanks for spotting those nits.
regards
sashan
Re: Update bgpd.conf man to reflect ROA changes
On Tue, Oct 02, 2018 at 08:26:02PM +0200, Denis Fondras wrote:
> Reorder text and be more precise.
>
> Index: bgpd.conf.5
> ===
> RCS file: /cvs/src/usr.sbin/bgpd/bgpd.conf.5,v
> retrieving revision 1.178
> diff -u -p -r1.178 bgpd.conf.5
> --- bgpd.conf.5 9 Sep 2018 17:11:26 - 1.178
> +++ bgpd.conf.5 2 Oct 2018 18:25:17 -
> @@ -445,6 +445,21 @@ The default is
> .Ic ignore .
> .Pp
> .It Xo
> +.Ic roa-set
> +.Ic { Ar address Ns Li / Ns Ar len Ic maxlen Ar len Ic source-as Ar asn ...
> Ic }
> +.Xc
> +A
> +.Ic roa-set
> +holds a collection of Validated ROA Payload (VRP).
hi.
i'm unsure about the terminology exactly. but can you have a "collection
of payload"? doesn;t it have to be "payload data" or something?
i think at least it needs to be plural (payloads). like, you wouldn;t
have a collection of bent umbrella. er, that's as an example..
or you could remove "collection of".
jmc
> +Each received prefix is checked against the
> +.Ic roa-set
> +and the Origin Validation Status (OVS) is set.
> +.Bd -literal -offset indent
> +roa-set { 192.0.2.0/24 maxlen 24 source-as 64511
> + 203.0.113.0/24 source-as 64496 }
> +.Ed
> +.Pp
> +.It Xo
> .Ic route-collector
> .Pq Ic yes Ns | Ns Ic no
> .Xc
> @@ -1386,6 +1401,14 @@ can be set to
> in which case the nexthop is compared against the address of the neighbor.
> Nexthop filtering is not supported on locally announced networks and one must
> take into consideration previous rules overwriting nexthops.
> +.Pp
> +.It Xo
> +.Ic ovs
> +.Pq Ic valid | not-found | invalid
> +.Xc
> +This rule applies only to
> +.Em UPDATES
> +where the Origin Validation Status (OVS) matches.
> .Pp
> .It Ic prefix Ar address Ns Li / Ns Ar len
> .It Ic prefix Ar address Ns Li / Ns Ar len Ic prefixlen Ar range
>
Re: Update bgpd.conf man to reflect ROA changes
Reorder text and be more precise.
Index: bgpd.conf.5
===
RCS file: /cvs/src/usr.sbin/bgpd/bgpd.conf.5,v
retrieving revision 1.178
diff -u -p -r1.178 bgpd.conf.5
--- bgpd.conf.5 9 Sep 2018 17:11:26 - 1.178
+++ bgpd.conf.5 2 Oct 2018 18:25:17 -
@@ -445,6 +445,21 @@ The default is
.Ic ignore .
.Pp
.It Xo
+.Ic roa-set
+.Ic { Ar address Ns Li / Ns Ar len Ic maxlen Ar len Ic source-as Ar asn ... Ic
}
+.Xc
+A
+.Ic roa-set
+holds a collection of Validated ROA Payload (VRP).
+Each received prefix is checked against the
+.Ic roa-set
+and the Origin Validation Status (OVS) is set.
+.Bd -literal -offset indent
+roa-set { 192.0.2.0/24 maxlen 24 source-as 64511
+ 203.0.113.0/24 source-as 64496 }
+.Ed
+.Pp
+.It Xo
.Ic route-collector
.Pq Ic yes Ns | Ns Ic no
.Xc
@@ -1386,6 +1401,14 @@ can be set to
in which case the nexthop is compared against the address of the neighbor.
Nexthop filtering is not supported on locally announced networks and one must
take into consideration previous rules overwriting nexthops.
+.Pp
+.It Xo
+.Ic ovs
+.Pq Ic valid | not-found | invalid
+.Xc
+This rule applies only to
+.Em UPDATES
+where the Origin Validation Status (OVS) matches.
.Pp
.It Ic prefix Ar address Ns Li / Ns Ar len
.It Ic prefix Ar address Ns Li / Ns Ar len Ic prefixlen Ar range
Update bgpd.conf man to reflect ROA changes
Sorry, I was not inspired to write a lengthy text.
Denis
Index: bgpd.conf.5
===
RCS file: /cvs/src/usr.sbin/bgpd/bgpd.conf.5,v
retrieving revision 1.178
diff -u -p -r1.178 bgpd.conf.5
--- bgpd.conf.5 9 Sep 2018 17:11:26 - 1.178
+++ bgpd.conf.5 2 Oct 2018 18:14:21 -
@@ -387,6 +387,21 @@ prefix-set as64496set { 192.0.2.0/24 pre
.Ed
.Pp
.It Xo
+.Ic roa-set
+.Ic { Ar address Ns Li / Ns Ar len Ic maxlen Ar len Ic source-as Ar asn ... Ic
}
+.Xc
+A
+.Ic roa-set
+holds a collection of Validated ROA Payload (VRP).
+Each prefix is checked against the
+.Ic roa-set
+and the Origin Validation Status (OVS) is set.
+.Bd -literal -offset indent
+roa-set { 192.0.2.0/24 maxlen 24 source-as 64511
+ 203.0.113.0/24 source-as 64496 }
+.Ed
+.Pp
+.It Xo
.Ic rde
.Ic med
.Ic compare
@@ -1386,6 +1401,14 @@ can be set to
in which case the nexthop is compared against the address of the neighbor.
Nexthop filtering is not supported on locally announced networks and one must
take into consideration previous rules overwriting nexthops.
+.Pp
+.It Xo
+.Ic ovs
+.Pq Ic valid | not-found | invalid
+.Xc
+This rule applies only to
+.Em UPDATES
+where the Origin Validation Status (OVS) matches.
.Pp
.It Ic prefix Ar address Ns Li / Ns Ar len
.It Ic prefix Ar address Ns Li / Ns Ar len Ic prefixlen Ar range
Re: vmd losing VMs
Dmitry, is there an easy way get at the VMs output? Here's dmesg from VMM_DEBUG-enabled kernel (built at "Add support for RT3290 chipset by James Hastings."). No lockup thus far. OpenBSD 6.4 (VMM_DEBUG) #0: Tue Oct 2 10:37:13 PDT 2018 syzkaller@ci-openbsd.syzkaller :/syzkaller/src/sys/arch/amd64/compile/VMM_DEBUG real mem = 17163079680 (16367MB) avail mem = 16633610240 (15863MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xbcf0 (20 entries) bios0: vendor Google version "Google" date 01/01/2011 bios0: Google Google Compute Engine acpi0 at bios0: rev 0 acpi0: sleep states S3 S4 S5 acpi0: tables DSDT FACP SSDT APIC WAET SRAT acpi0: wakeup devices acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) CPU @ 2.30GHz, 2300.55 MHz, 06-3f-00 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,VMX,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,XSAVEOPT,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 990MHz cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Xeon(R) CPU @ 2.30GHz, 2276.88 MHz, 06-3f-00 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,VMX,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,XSAVEOPT,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Xeon(R) CPU @ 2.30GHz, 2276.87 MHz, 06-3f-00 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,VMX,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,XSAVEOPT,MELTDOWN cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Xeon(R) CPU @ 2.30GHz, 2276.89 MHz, 06-3f-00 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,VMX,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,XSAVEOPT,MELTDOWN cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 0, core 3, package 0 cpu4 at mainbus0: apid 1 (application processor) cpu4: Intel(R) Xeon(R) CPU @ 2.30GHz, 2276.88 MHz, 06-3f-00 cpu4: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,VMX,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,XSAVEOPT,MELTDOWN cpu4: 256KB 64b/line 8-way L2 cache cpu4: smt 1, core 0, package 0 cpu5 at mainbus0: apid 3 (application processor) cpu5: Intel(R) Xeon(R) CPU @ 2.30GHz, 2276.88 MHz, 06-3f-00 cpu5: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,VMX,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,XSAVEOPT,MELTDOWN cpu5: 256KB 64b/line 8-way L2 cache cpu5: smt 1, core 1, package 0 cpu6 at mainbus0: apid 5 (application processor) cpu6: Intel(R) Xeon(R) CPU @ 2.30GHz, 2276.94 MHz, 06-3f-00 cpu6: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,VMX,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,XSAVEOPT,MELTDOWN cpu6: 256KB 64b/line 8-way L2 cache cpu6: smt 1, core 2, package 0 cpu7 at mainbus0: apid 7 (application processor) cpu7: Intel(R) Xeon(R) CPU @ 2.30GHz, 2276.91 MHz, 06-3f-00 cpu7: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,VMX,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,XSAVEOPT,MELTDOWN cpu7: 256KB 64b/line 8-way L2 cache cpu7: smt 1, core 3, package 0 ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins acpiprt0 at acpi0: bus 0 (PCI0) acpicpu0 at acpi0: C1(@1 halt!) acpicpu1 at acpi0: C1(@1 halt!) acpicpu2 at acpi0: C1(@1 halt!) acpicpu3 at acpi0: C1(@1 halt!) acp
Re: vmd losing VMs
Ok thanks. I wonder if there is a tool that can log everything from the VM's console ... It would be useful to see what happens to the VM before it goes into zombie mode. Reyk On Tue, Oct 02, 2018 at 10:33:11AM -0700, Greg Steuck wrote: > I believe I was unable to ssh into them or get cu to elicit any characters. > I'll verify next time it happens. > > On Tue, Oct 2, 2018 at 10:20 AM Reyk Floeter wrote: > > > On Tue, Oct 02, 2018 at 10:10:41AM -0700, Greg Steuck wrote: > > > Naturally, bugs don't solve themselves :) Here's a log, it's not very > > > useful due to the lack of debugging symbols. Notice, that runaway vmds > > > don't die on their own, they just spin out of control. I'll do VMM_DEBUG > > > next. > > > > > > > "they just spin out of control" - maybe I've missed the previous > > details, but do you know what happens to these VMs? Are they stuck in > > ddb or in a reboot loop? > > > > Reyk > > > > > ci-openbsd# sysctl kern.nosuidcoredump=3 && mkdir /var/crash/vmd > > > kern.nosuidcoredump: 1 -> 3 > > > ci-openbsd# sysctl kern.nosuidcoredump > > > kern.nosuidcoredump=3 > > > ci-openbsd# ps ax | grep vmd > > > 32653 ?? Isp 0:01.28 /usr/sbin/vmd > > > 89585 ?? Is 0:00.14 vmd: priv (vmd) > > > 50191 ?? Isp 0:01.88 vmd: control (vmd) > > > 33160 ?? Isp 0:08.55 vmd: vmm (vmd) > > > 52853 ?? Rp/1 280:12.56 vmd: ci-openbsd-main-1 (vmd) > > > 3238 ?? Rp/2 48:56.13 vmd: ci-openbsd-main-0 (vmd) > > > 44625 ?? Rp/02:54.05 vmd: ci-openbsd-main-2 (vmd) > > > 42187 p5 R+p/0 0:00.00 grep vmd (ksh) > > > ci-openbsd# vmctl status > > >ID PID VCPUS MAXMEM CURMEM TTYOWNER NAME > > > 239 44625 1512M181M ttyp2syzkaller ci-openbsd-main-2 > > > 1 - 1512M - -syzkaller syzkaller > > > ci-openbsd# kill 52853 > > > ci-openbsd# ps ax | grep vmd > > > 32653 ?? Ssp 0:01.28 /usr/sbin/vmd > > > 89585 ?? Is 0:00.14 vmd: priv (vmd) > > > 50191 ?? Ssp 0:01.88 vmd: control (vmd) > > > 33160 ?? Ssp 0:08.55 vmd: vmm (vmd) > > > 52853 ?? Rp/1 280:30.24 vmd: ci-openbsd-main-1 (vmd) > > > 3238 ?? Rp/2 49:14.27 vmd: ci-openbsd-main-0 (vmd) > > > 44625 ?? Rp/03:12.25 vmd: ci-openbsd-main-2 (vmd) > > > 27783 p5 R+p/1 0:00.00 grep vmd (ksh) > > > ci-openbsd# ps ax | grep syz > > > 50771 ?? Is 0:00.01 /sbin/mount_mfs -s 10G /dev/sd0b > > > /syzkaller/ramdisk > > > 70067 ?? Is 0:00.16 sshd: syzkaller [priv] (sshd) > > > 957 ?? S 0:01.09 sshd: syzkaller@ttyp3 (sshd) > > > 28743 ?? I 18:00.14 syzkaller/current/bin/syz-manager -config > > > /syzkaller/managers/main/current/manager.cfg > > > 5869 ?? Ip 0:00.07 ssh -p 22 -i > > /syzkaller/managers/main/current/key > > > -F /dev/null -o UserKnownHostsFile=/dev/null -o BatchMode=yes -o Identi > > > 57895 ?? Is 0:00.08 sshd: syzkaller [priv] (sshd) > > > 77889 ?? S 0:00.17 sshd: syzkaller@ttyp4 (sshd) > > > 39218 p5 R+/00:00.00 grep syz > > > 50644 00- D 4:09.87 ./syz-ci -config ./config-openbsd.ci > > > 60603 00- Ip 0:00.05 tee syz-ci.log > > > ci-openbsd# kill 50644 28743 > > > ci-openbsd# ps ax | grep syz > > > 50771 ?? Is 0:00.01 /sbin/mount_mfs -s 10G /dev/sd0b > > > /syzkaller/ramdisk > > > 70067 ?? Is 0:00.16 sshd: syzkaller [priv] (sshd) > > > 957 ?? I 0:01.09 sshd: syzkaller@ttyp3 (sshd) > > > 57895 ?? Is 0:00.08 sshd: syzkaller [priv] (sshd) > > > 77889 ?? S 0:00.18 sshd: syzkaller@ttyp4 (sshd) > > > 15816 p5 R+/10:00.00 grep syz > > > ci-openbsd# rcctl stop vmd > > > vmd(ok) > > > ci-openbsd# ps ax | grep vmd > > > 52853 ?? Rp/1 281:59.20 vmd: ci-openbsd-main-1 (vmd) > > > 3238 ?? Rp/2 50:42.87 vmd: ci-openbsd-main-0 (vmd) > > > 19166 p5 R+/00:00.00 grep vmd > > > ci-openbsd# kill -ABRT 52853 > > > ci-openbsd# ps ax | grep vmd > > > 3238 ?? Rp/2 52:06.55 vmd: ci-openbsd-main-0 (vmd) > > > 55423 p5 S+p 0:00.01 grep vmd > > > ci-openbsd# dmesg | tail > > > pms0 at pckbc0 (aux slot) > > > wsmouse0 at pms0 mux 0 > > > pcppi0 at isa0 port 0x61 > > > spkr0 at pcppi0 > > > vmm0 at mainbus0: VMX/EPT (using slow L1TF mitigation) > > > vscsi0 at root > > > scsibus2 at vscsi0: 256 targets > > > softraid0 at root > > > scsibus3 at softraid0: 256 targets > > > root on sd0a (dd61083aafe9fd0b.a) swap on sd0b dump on sd0b > > > ci-openbsd# ps ax | grep vmd > > > 3238 ?? Rp/2 52:06.88 vmd: ci-openbsd-main-0 (vmd) > > > 19175 p5 R+/00:00.00 grep vmd > > > ci-openbsd# kill 3238 > > > ci-openbsd# ps ax | grep vmd > > > 3238 ?? Rp/2 52:18.52 vmd: ci-openbsd-main-0 (vmd) > > > 27516 p5 R+/30:00.00 grep vmd > > > ci-openbsd# kill -ABRT 3238 > > > ci-openbsd# ps ax | grep vmd > > > 3238 ?? Rp/2 52:27.71 (vmd) > > > 93083 p5 R+/30:00.00 grep vmd > > > ci-openbsd# ps ax | grep vmd > > > 95984 p5 S+p 0:00.01 grep vmd > > > ci-openbsd# ls -l /var/crash/vmd > > > total 668864 > > > -rw--- 1 root wheel 200320568 Oc
Re: vmd losing VMs
I believe I was unable to ssh into them or get cu to elicit any characters. I'll verify next time it happens. On Tue, Oct 2, 2018 at 10:20 AM Reyk Floeter wrote: > On Tue, Oct 02, 2018 at 10:10:41AM -0700, Greg Steuck wrote: > > Naturally, bugs don't solve themselves :) Here's a log, it's not very > > useful due to the lack of debugging symbols. Notice, that runaway vmds > > don't die on their own, they just spin out of control. I'll do VMM_DEBUG > > next. > > > > "they just spin out of control" - maybe I've missed the previous > details, but do you know what happens to these VMs? Are they stuck in > ddb or in a reboot loop? > > Reyk > > > ci-openbsd# sysctl kern.nosuidcoredump=3 && mkdir /var/crash/vmd > > kern.nosuidcoredump: 1 -> 3 > > ci-openbsd# sysctl kern.nosuidcoredump > > kern.nosuidcoredump=3 > > ci-openbsd# ps ax | grep vmd > > 32653 ?? Isp 0:01.28 /usr/sbin/vmd > > 89585 ?? Is 0:00.14 vmd: priv (vmd) > > 50191 ?? Isp 0:01.88 vmd: control (vmd) > > 33160 ?? Isp 0:08.55 vmd: vmm (vmd) > > 52853 ?? Rp/1 280:12.56 vmd: ci-openbsd-main-1 (vmd) > > 3238 ?? Rp/2 48:56.13 vmd: ci-openbsd-main-0 (vmd) > > 44625 ?? Rp/02:54.05 vmd: ci-openbsd-main-2 (vmd) > > 42187 p5 R+p/0 0:00.00 grep vmd (ksh) > > ci-openbsd# vmctl status > >ID PID VCPUS MAXMEM CURMEM TTYOWNER NAME > > 239 44625 1512M181M ttyp2syzkaller ci-openbsd-main-2 > > 1 - 1512M - -syzkaller syzkaller > > ci-openbsd# kill 52853 > > ci-openbsd# ps ax | grep vmd > > 32653 ?? Ssp 0:01.28 /usr/sbin/vmd > > 89585 ?? Is 0:00.14 vmd: priv (vmd) > > 50191 ?? Ssp 0:01.88 vmd: control (vmd) > > 33160 ?? Ssp 0:08.55 vmd: vmm (vmd) > > 52853 ?? Rp/1 280:30.24 vmd: ci-openbsd-main-1 (vmd) > > 3238 ?? Rp/2 49:14.27 vmd: ci-openbsd-main-0 (vmd) > > 44625 ?? Rp/03:12.25 vmd: ci-openbsd-main-2 (vmd) > > 27783 p5 R+p/1 0:00.00 grep vmd (ksh) > > ci-openbsd# ps ax | grep syz > > 50771 ?? Is 0:00.01 /sbin/mount_mfs -s 10G /dev/sd0b > > /syzkaller/ramdisk > > 70067 ?? Is 0:00.16 sshd: syzkaller [priv] (sshd) > > 957 ?? S 0:01.09 sshd: syzkaller@ttyp3 (sshd) > > 28743 ?? I 18:00.14 syzkaller/current/bin/syz-manager -config > > /syzkaller/managers/main/current/manager.cfg > > 5869 ?? Ip 0:00.07 ssh -p 22 -i > /syzkaller/managers/main/current/key > > -F /dev/null -o UserKnownHostsFile=/dev/null -o BatchMode=yes -o Identi > > 57895 ?? Is 0:00.08 sshd: syzkaller [priv] (sshd) > > 77889 ?? S 0:00.17 sshd: syzkaller@ttyp4 (sshd) > > 39218 p5 R+/00:00.00 grep syz > > 50644 00- D 4:09.87 ./syz-ci -config ./config-openbsd.ci > > 60603 00- Ip 0:00.05 tee syz-ci.log > > ci-openbsd# kill 50644 28743 > > ci-openbsd# ps ax | grep syz > > 50771 ?? Is 0:00.01 /sbin/mount_mfs -s 10G /dev/sd0b > > /syzkaller/ramdisk > > 70067 ?? Is 0:00.16 sshd: syzkaller [priv] (sshd) > > 957 ?? I 0:01.09 sshd: syzkaller@ttyp3 (sshd) > > 57895 ?? Is 0:00.08 sshd: syzkaller [priv] (sshd) > > 77889 ?? S 0:00.18 sshd: syzkaller@ttyp4 (sshd) > > 15816 p5 R+/10:00.00 grep syz > > ci-openbsd# rcctl stop vmd > > vmd(ok) > > ci-openbsd# ps ax | grep vmd > > 52853 ?? Rp/1 281:59.20 vmd: ci-openbsd-main-1 (vmd) > > 3238 ?? Rp/2 50:42.87 vmd: ci-openbsd-main-0 (vmd) > > 19166 p5 R+/00:00.00 grep vmd > > ci-openbsd# kill -ABRT 52853 > > ci-openbsd# ps ax | grep vmd > > 3238 ?? Rp/2 52:06.55 vmd: ci-openbsd-main-0 (vmd) > > 55423 p5 S+p 0:00.01 grep vmd > > ci-openbsd# dmesg | tail > > pms0 at pckbc0 (aux slot) > > wsmouse0 at pms0 mux 0 > > pcppi0 at isa0 port 0x61 > > spkr0 at pcppi0 > > vmm0 at mainbus0: VMX/EPT (using slow L1TF mitigation) > > vscsi0 at root > > scsibus2 at vscsi0: 256 targets > > softraid0 at root > > scsibus3 at softraid0: 256 targets > > root on sd0a (dd61083aafe9fd0b.a) swap on sd0b dump on sd0b > > ci-openbsd# ps ax | grep vmd > > 3238 ?? Rp/2 52:06.88 vmd: ci-openbsd-main-0 (vmd) > > 19175 p5 R+/00:00.00 grep vmd > > ci-openbsd# kill 3238 > > ci-openbsd# ps ax | grep vmd > > 3238 ?? Rp/2 52:18.52 vmd: ci-openbsd-main-0 (vmd) > > 27516 p5 R+/30:00.00 grep vmd > > ci-openbsd# kill -ABRT 3238 > > ci-openbsd# ps ax | grep vmd > > 3238 ?? Rp/2 52:27.71 (vmd) > > 93083 p5 R+/30:00.00 grep vmd > > ci-openbsd# ps ax | grep vmd > > 95984 p5 S+p 0:00.01 grep vmd > > ci-openbsd# ls -l /var/crash/vmd > > total 668864 > > -rw--- 1 root wheel 200320568 Oct 2 09:47 3238.core > > -rw--- 1 root wheel 141988032 Oct 2 09:46 52853.core > > ci-openbsd# gdb /usr/sb > > ci-openbsd# file /var/crash/vmd/52853.core > > /var/crash/vmd/52853.core: ELF 64-bit LSB core file x86-64, version 1 > > ci-openbsd# gdb /usr/sbin/vmd /var/crash/vmd/52853.core > > GNU gdb 6.3 > > Copyright 2004 Free Software Foundation, Inc. > > GDB is free software, covered by the GNU General Public License, and you > are > > welc
Re: vmd losing VMs
On Tue, Oct 02, 2018 at 10:10:41AM -0700, Greg Steuck wrote: > Naturally, bugs don't solve themselves :) Here's a log, it's not very > useful due to the lack of debugging symbols. Notice, that runaway vmds > don't die on their own, they just spin out of control. I'll do VMM_DEBUG > next. > "they just spin out of control" - maybe I've missed the previous details, but do you know what happens to these VMs? Are they stuck in ddb or in a reboot loop? Reyk > ci-openbsd# sysctl kern.nosuidcoredump=3 && mkdir /var/crash/vmd > kern.nosuidcoredump: 1 -> 3 > ci-openbsd# sysctl kern.nosuidcoredump > kern.nosuidcoredump=3 > ci-openbsd# ps ax | grep vmd > 32653 ?? Isp 0:01.28 /usr/sbin/vmd > 89585 ?? Is 0:00.14 vmd: priv (vmd) > 50191 ?? Isp 0:01.88 vmd: control (vmd) > 33160 ?? Isp 0:08.55 vmd: vmm (vmd) > 52853 ?? Rp/1 280:12.56 vmd: ci-openbsd-main-1 (vmd) > 3238 ?? Rp/2 48:56.13 vmd: ci-openbsd-main-0 (vmd) > 44625 ?? Rp/02:54.05 vmd: ci-openbsd-main-2 (vmd) > 42187 p5 R+p/0 0:00.00 grep vmd (ksh) > ci-openbsd# vmctl status >ID PID VCPUS MAXMEM CURMEM TTYOWNER NAME > 239 44625 1512M181M ttyp2syzkaller ci-openbsd-main-2 > 1 - 1512M - -syzkaller syzkaller > ci-openbsd# kill 52853 > ci-openbsd# ps ax | grep vmd > 32653 ?? Ssp 0:01.28 /usr/sbin/vmd > 89585 ?? Is 0:00.14 vmd: priv (vmd) > 50191 ?? Ssp 0:01.88 vmd: control (vmd) > 33160 ?? Ssp 0:08.55 vmd: vmm (vmd) > 52853 ?? Rp/1 280:30.24 vmd: ci-openbsd-main-1 (vmd) > 3238 ?? Rp/2 49:14.27 vmd: ci-openbsd-main-0 (vmd) > 44625 ?? Rp/03:12.25 vmd: ci-openbsd-main-2 (vmd) > 27783 p5 R+p/1 0:00.00 grep vmd (ksh) > ci-openbsd# ps ax | grep syz > 50771 ?? Is 0:00.01 /sbin/mount_mfs -s 10G /dev/sd0b > /syzkaller/ramdisk > 70067 ?? Is 0:00.16 sshd: syzkaller [priv] (sshd) > 957 ?? S 0:01.09 sshd: syzkaller@ttyp3 (sshd) > 28743 ?? I 18:00.14 syzkaller/current/bin/syz-manager -config > /syzkaller/managers/main/current/manager.cfg > 5869 ?? Ip 0:00.07 ssh -p 22 -i /syzkaller/managers/main/current/key > -F /dev/null -o UserKnownHostsFile=/dev/null -o BatchMode=yes -o Identi > 57895 ?? Is 0:00.08 sshd: syzkaller [priv] (sshd) > 77889 ?? S 0:00.17 sshd: syzkaller@ttyp4 (sshd) > 39218 p5 R+/00:00.00 grep syz > 50644 00- D 4:09.87 ./syz-ci -config ./config-openbsd.ci > 60603 00- Ip 0:00.05 tee syz-ci.log > ci-openbsd# kill 50644 28743 > ci-openbsd# ps ax | grep syz > 50771 ?? Is 0:00.01 /sbin/mount_mfs -s 10G /dev/sd0b > /syzkaller/ramdisk > 70067 ?? Is 0:00.16 sshd: syzkaller [priv] (sshd) > 957 ?? I 0:01.09 sshd: syzkaller@ttyp3 (sshd) > 57895 ?? Is 0:00.08 sshd: syzkaller [priv] (sshd) > 77889 ?? S 0:00.18 sshd: syzkaller@ttyp4 (sshd) > 15816 p5 R+/10:00.00 grep syz > ci-openbsd# rcctl stop vmd > vmd(ok) > ci-openbsd# ps ax | grep vmd > 52853 ?? Rp/1 281:59.20 vmd: ci-openbsd-main-1 (vmd) > 3238 ?? Rp/2 50:42.87 vmd: ci-openbsd-main-0 (vmd) > 19166 p5 R+/00:00.00 grep vmd > ci-openbsd# kill -ABRT 52853 > ci-openbsd# ps ax | grep vmd > 3238 ?? Rp/2 52:06.55 vmd: ci-openbsd-main-0 (vmd) > 55423 p5 S+p 0:00.01 grep vmd > ci-openbsd# dmesg | tail > pms0 at pckbc0 (aux slot) > wsmouse0 at pms0 mux 0 > pcppi0 at isa0 port 0x61 > spkr0 at pcppi0 > vmm0 at mainbus0: VMX/EPT (using slow L1TF mitigation) > vscsi0 at root > scsibus2 at vscsi0: 256 targets > softraid0 at root > scsibus3 at softraid0: 256 targets > root on sd0a (dd61083aafe9fd0b.a) swap on sd0b dump on sd0b > ci-openbsd# ps ax | grep vmd > 3238 ?? Rp/2 52:06.88 vmd: ci-openbsd-main-0 (vmd) > 19175 p5 R+/00:00.00 grep vmd > ci-openbsd# kill 3238 > ci-openbsd# ps ax | grep vmd > 3238 ?? Rp/2 52:18.52 vmd: ci-openbsd-main-0 (vmd) > 27516 p5 R+/30:00.00 grep vmd > ci-openbsd# kill -ABRT 3238 > ci-openbsd# ps ax | grep vmd > 3238 ?? Rp/2 52:27.71 (vmd) > 93083 p5 R+/30:00.00 grep vmd > ci-openbsd# ps ax | grep vmd > 95984 p5 S+p 0:00.01 grep vmd > ci-openbsd# ls -l /var/crash/vmd > total 668864 > -rw--- 1 root wheel 200320568 Oct 2 09:47 3238.core > -rw--- 1 root wheel 141988032 Oct 2 09:46 52853.core > ci-openbsd# gdb /usr/sb > ci-openbsd# file /var/crash/vmd/52853.core > /var/crash/vmd/52853.core: ELF 64-bit LSB core file x86-64, version 1 > ci-openbsd# gdb /usr/sbin/vmd /var/crash/vmd/52853.core > GNU gdb 6.3 > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "amd64-unknown-openbsd6.4"...(no debugging > symbols found) > > Core was generated by `vmd'. > Program terminated with signal 6, Aborted. > Reading symbol
vmd losing VMs
Naturally, bugs don't solve themselves :) Here's a log, it's not very useful due to the lack of debugging symbols. Notice, that runaway vmds don't die on their own, they just spin out of control. I'll do VMM_DEBUG next. ci-openbsd# sysctl kern.nosuidcoredump=3 && mkdir /var/crash/vmd kern.nosuidcoredump: 1 -> 3 ci-openbsd# sysctl kern.nosuidcoredump kern.nosuidcoredump=3 ci-openbsd# ps ax | grep vmd 32653 ?? Isp 0:01.28 /usr/sbin/vmd 89585 ?? Is 0:00.14 vmd: priv (vmd) 50191 ?? Isp 0:01.88 vmd: control (vmd) 33160 ?? Isp 0:08.55 vmd: vmm (vmd) 52853 ?? Rp/1 280:12.56 vmd: ci-openbsd-main-1 (vmd) 3238 ?? Rp/2 48:56.13 vmd: ci-openbsd-main-0 (vmd) 44625 ?? Rp/02:54.05 vmd: ci-openbsd-main-2 (vmd) 42187 p5 R+p/0 0:00.00 grep vmd (ksh) ci-openbsd# vmctl status ID PID VCPUS MAXMEM CURMEM TTYOWNER NAME 239 44625 1512M181M ttyp2syzkaller ci-openbsd-main-2 1 - 1512M - -syzkaller syzkaller ci-openbsd# kill 52853 ci-openbsd# ps ax | grep vmd 32653 ?? Ssp 0:01.28 /usr/sbin/vmd 89585 ?? Is 0:00.14 vmd: priv (vmd) 50191 ?? Ssp 0:01.88 vmd: control (vmd) 33160 ?? Ssp 0:08.55 vmd: vmm (vmd) 52853 ?? Rp/1 280:30.24 vmd: ci-openbsd-main-1 (vmd) 3238 ?? Rp/2 49:14.27 vmd: ci-openbsd-main-0 (vmd) 44625 ?? Rp/03:12.25 vmd: ci-openbsd-main-2 (vmd) 27783 p5 R+p/1 0:00.00 grep vmd (ksh) ci-openbsd# ps ax | grep syz 50771 ?? Is 0:00.01 /sbin/mount_mfs -s 10G /dev/sd0b /syzkaller/ramdisk 70067 ?? Is 0:00.16 sshd: syzkaller [priv] (sshd) 957 ?? S 0:01.09 sshd: syzkaller@ttyp3 (sshd) 28743 ?? I 18:00.14 syzkaller/current/bin/syz-manager -config /syzkaller/managers/main/current/manager.cfg 5869 ?? Ip 0:00.07 ssh -p 22 -i /syzkaller/managers/main/current/key -F /dev/null -o UserKnownHostsFile=/dev/null -o BatchMode=yes -o Identi 57895 ?? Is 0:00.08 sshd: syzkaller [priv] (sshd) 77889 ?? S 0:00.17 sshd: syzkaller@ttyp4 (sshd) 39218 p5 R+/00:00.00 grep syz 50644 00- D 4:09.87 ./syz-ci -config ./config-openbsd.ci 60603 00- Ip 0:00.05 tee syz-ci.log ci-openbsd# kill 50644 28743 ci-openbsd# ps ax | grep syz 50771 ?? Is 0:00.01 /sbin/mount_mfs -s 10G /dev/sd0b /syzkaller/ramdisk 70067 ?? Is 0:00.16 sshd: syzkaller [priv] (sshd) 957 ?? I 0:01.09 sshd: syzkaller@ttyp3 (sshd) 57895 ?? Is 0:00.08 sshd: syzkaller [priv] (sshd) 77889 ?? S 0:00.18 sshd: syzkaller@ttyp4 (sshd) 15816 p5 R+/10:00.00 grep syz ci-openbsd# rcctl stop vmd vmd(ok) ci-openbsd# ps ax | grep vmd 52853 ?? Rp/1 281:59.20 vmd: ci-openbsd-main-1 (vmd) 3238 ?? Rp/2 50:42.87 vmd: ci-openbsd-main-0 (vmd) 19166 p5 R+/00:00.00 grep vmd ci-openbsd# kill -ABRT 52853 ci-openbsd# ps ax | grep vmd 3238 ?? Rp/2 52:06.55 vmd: ci-openbsd-main-0 (vmd) 55423 p5 S+p 0:00.01 grep vmd ci-openbsd# dmesg | tail pms0 at pckbc0 (aux slot) wsmouse0 at pms0 mux 0 pcppi0 at isa0 port 0x61 spkr0 at pcppi0 vmm0 at mainbus0: VMX/EPT (using slow L1TF mitigation) vscsi0 at root scsibus2 at vscsi0: 256 targets softraid0 at root scsibus3 at softraid0: 256 targets root on sd0a (dd61083aafe9fd0b.a) swap on sd0b dump on sd0b ci-openbsd# ps ax | grep vmd 3238 ?? Rp/2 52:06.88 vmd: ci-openbsd-main-0 (vmd) 19175 p5 R+/00:00.00 grep vmd ci-openbsd# kill 3238 ci-openbsd# ps ax | grep vmd 3238 ?? Rp/2 52:18.52 vmd: ci-openbsd-main-0 (vmd) 27516 p5 R+/30:00.00 grep vmd ci-openbsd# kill -ABRT 3238 ci-openbsd# ps ax | grep vmd 3238 ?? Rp/2 52:27.71 (vmd) 93083 p5 R+/30:00.00 grep vmd ci-openbsd# ps ax | grep vmd 95984 p5 S+p 0:00.01 grep vmd ci-openbsd# ls -l /var/crash/vmd total 668864 -rw--- 1 root wheel 200320568 Oct 2 09:47 3238.core -rw--- 1 root wheel 141988032 Oct 2 09:46 52853.core ci-openbsd# gdb /usr/sb ci-openbsd# file /var/crash/vmd/52853.core /var/crash/vmd/52853.core: ELF 64-bit LSB core file x86-64, version 1 ci-openbsd# gdb /usr/sbin/vmd /var/crash/vmd/52853.core GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-unknown-openbsd6.4"...(no debugging symbols found) Core was generated by `vmd'. Program terminated with signal 6, Aborted. Reading symbols from /usr/lib/libpthread.so.25.1...done. Loaded symbols for /usr/lib/libpthread.so.25.1 Loaded symbols for /usr/sbin/vmd Reading symbols from /usr/lib/libutil.so.13.0...done. Loaded symbols for /usr/lib/libutil.so.13.0 Symbols already loaded for /usr/lib/libpthread.so.25.1 Reading symbols from /usr/lib/libevent.so.4.1...done. Loaded symbols for /usr/lib/libevent.so.4.1 Reading symbols from /usr/lib/libc.so.92.5...done. Loaded symbols for /usr/l
Re: lldb: build and install
> Date: Tue, 2 Oct 2018 17:24:42 +0200
> From: Patrick Wildt
>
> Hi,
>
> we already do have the sources for LLDB, the only thing left to do is
> add the build infrastructure so that we actually compile all the
> independent pieces and link them together. Aparently LLDB also makes
> use of some of the clang libraries, so those are part of LLDB linking
> dependencies as well.
>
> Since we have no Python in base we have to explicitly disable Python,
> otherwise it will try to use Python headers and probably also link
> against it.
>
> According to kettenis@, debugging core files should work, actually
> running stuff probably won't. Still, having lldb is a first step.
>
> Compiled on amd64, tests on other clang architectures would be nice.
>
> Feedback? ok?
I would like to get this in. That said, I'm not sure lldb in its
current state is useful enough to ship in 6.4.
> diff --git a/gnu/usr.bin/clang/Makefile b/gnu/usr.bin/clang/Makefile
> index 250fb1d64f5..62490b00968 100644
> --- a/gnu/usr.bin/clang/Makefile
> +++ b/gnu/usr.bin/clang/Makefile
> @@ -43,6 +43,8 @@ SUBDIR+=libLLVMCoverage
> SUBDIR+=libLLVMDebugInfoCodeView
> SUBDIR+=libLLVMDebugInfoDWARF
> SUBDIR+=libLLVMDebugInfoMSF
> +SUBDIR+=libLLVMDebugInfoPDB
> +SUBDIR+=libLLVMExecutionEngine
> SUBDIR+=libLLVMGlobalISel
> SUBDIR+=libLLVMLTO
> SUBDIR+=libLLVMPasses
> @@ -86,5 +88,44 @@ SUBDIR+=liblldELF
>
> SUBDIR+=lld
>
> +SUBDIR+=liblldbABI
> +SUBDIR+=liblldbAPI
> +SUBDIR+=liblldbBreakpoint
> +SUBDIR+=liblldbCommands
> +SUBDIR+=liblldbCore
> +SUBDIR+=liblldbDataFormatters
> +SUBDIR+=liblldbExpression
> +SUBDIR+=liblldbHostCommon
> +SUBDIR+=liblldbHostOpenBSD
> +SUBDIR+=liblldbHostPOSIX
> +SUBDIR+=liblldbInitialization
> +SUBDIR+=liblldbInterpreter
> +SUBDIR+=liblldbPluginArchitecture
> +SUBDIR+=liblldbPluginDisassembler
> +SUBDIR+=liblldbPluginDynamicLoader
> +SUBDIR+=liblldbPluginExpressionParser
> +SUBDIR+=liblldbPluginInstruction
> +SUBDIR+=liblldbPluginInstrumentationRuntime
> +SUBDIR+=liblldbPluginJITLoader
> +SUBDIR+=liblldbPluginLanguage
> +SUBDIR+=liblldbPluginLanguageRuntime
> +SUBDIR+=liblldbPluginMemoryHistory
> +SUBDIR+=liblldbPluginObjectContainer
> +SUBDIR+=liblldbPluginObjectFile
> +SUBDIR+=liblldbPluginOperatingSystem
> +SUBDIR+=liblldbPluginPlatform
> +SUBDIR+=liblldbPluginProcess
> +SUBDIR+=liblldbPluginScriptInterpreter
> +SUBDIR+=liblldbPluginStructuredData
> +SUBDIR+=liblldbPluginSymbolFile
> +SUBDIR+=liblldbPluginSymbolVendor
> +SUBDIR+=liblldbPluginSystemRuntime
> +SUBDIR+=liblldbPluginUnwindAssembly
> +SUBDIR+=liblldbSymbol
> +SUBDIR+=liblldbTarget
> +SUBDIR+=liblldbUtility
> +
> +SUBDIR+=lldb
> +
> .include
> .include
> diff --git a/gnu/usr.bin/clang/Makefile.inc b/gnu/usr.bin/clang/Makefile.inc
> index 0b99edce43d..90fbe660c35 100644
> --- a/gnu/usr.bin/clang/Makefile.inc
> +++ b/gnu/usr.bin/clang/Makefile.inc
> @@ -17,6 +17,8 @@ DEBUG=
> NOPIE=
>
> CLANG_INCLUDES= -I${LLVM_SRCS}/tools/clang/include
> +LLDB_INCLUDES= -I${LLVM_SRCS}/tools/lldb/include \
> + -I${LLVM_SRCS}/tools/lldb/source
> CPPFLAGS+= -I${LLVM_SRCS}/include -I${.CURDIR}/../include -I${.OBJDIR} \
> -I${.OBJDIR}/../include
> CPPFLAGS+= -DNDEBUG
> @@ -42,6 +44,7 @@
> CPPFLAGS+=-DLLVM_NATIVE_DISASSEMBLER=LLVMInitialize${LLVM_ARCH}Disassembler
> CPPFLAGS+=-DLLVM_NATIVE_TARGET=LLVMInitialize${LLVM_ARCH}Target
> CPPFLAGS+=-DLLVM_NATIVE_TARGETINFO=LLVMInitialize${LLVM_ARCH}TargetInfo
> CPPFLAGS+=-DLLVM_NATIVE_TARGETMC=LLVMInitialize${LLVM_ARCH}TargetMC
> +CPPFLAGS+=-DLLDB_DISABLE_PYTHON
>
> # upstream defaults
> CFLAGS+= -ffunction-sections
> @@ -57,7 +60,9 @@ CXXFLAGS+= -Wall -W -Wno-unused-parameter -Wwrite-strings
> -Wcast-qual \
> -Wno-missing-field-initializers -pedantic -Wno-long-long \
> -Wdelete-non-virtual-dtor -Wno-comment
>
> +LDADD+=-Wl,--start-group
> .for lib in ${LLVM_LIBDEPS}
> DPADD+= ${.OBJDIR}/../lib${lib}/lib${lib}.a
> LDADD+= ${.OBJDIR}/../lib${lib}/lib${lib}.a
> .endfor
> +LDADD+=-Wl,--end-group
> diff --git a/gnu/usr.bin/clang/include/lldb/Host/Config.h
> b/gnu/usr.bin/clang/include/lldb/Host/Config.h
> new file mode 100644
> index 000..1fc5396e2bb
> --- /dev/null
> +++ b/gnu/usr.bin/clang/include/lldb/Host/Config.h
> @@ -0,0 +1,29 @@
> +//===-- Config.h ---*- C++
> -*-===//
> +//
> +// The LLVM Compiler Infrastructure
> +//
> +// This file is distributed under the University of Illinois Open Source
> +// License. See LICENSE.TXT for details.
> +//
> +//===--===//
> +
> +#ifndef LLDB_HOST_CONFIG_H
> +#define LLDB_HOST_CONFIG_H
> +
> +#define LLDB_CONFIG_TERMIOS_SUPPORTED
> +
> +/* #define LLDB_DISABLE_POSIX */
> +
> +#define HAVE_SYS_EVENT_H 1
> +
> +#define HAVE_PPOLL 1
> +
> +#define HAVE_SIGACTION 1
> +
> +#define HAVE_PROCESS_VM_READV 0
> +
> +#define HAVE_NR_PROCESS_VM_READ
Re: vmd losing VMs
On Mon, Oct 01, 2018 at 10:16:24PM -0700, Greg Steuck wrote: > Thanks Mike. > > I've upgraded from Sep 27th to Sep 29th snapshot and so far I haven't seen > the problem with: > > OpenBSD 6.4-beta (GENERIC.MP) #336: Sat Sep 29 08:13:15 MDT 2018 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > pd@ is saying he's not responsible for the fix, but maybe something by reyk@ > is? > > I will apply the debugging tools should the problem recur. > > BTW, the memory copy-pasto fix is working well. I was prevented from > running 4x2G VMs ;) > > Thanks > Greg > -- > nest.cx is Gmail hosted, use PGP for anything private. Key: > http://goo.gl/6dMsr > Fingerprint: 5E2B 2D0E 1E03 2046 BEC3 4D50 0B15 42BD 8DF5 A1B0 Thanks. Please let me know if you see any other problems. -ml
lldb: build and install
Hi,
we already do have the sources for LLDB, the only thing left to do is
add the build infrastructure so that we actually compile all the
independent pieces and link them together. Aparently LLDB also makes
use of some of the clang libraries, so those are part of LLDB linking
dependencies as well.
Since we have no Python in base we have to explicitly disable Python,
otherwise it will try to use Python headers and probably also link
against it.
According to kettenis@, debugging core files should work, actually
running stuff probably won't. Still, having lldb is a first step.
Compiled on amd64, tests on other clang architectures would be nice.
Feedback? ok?
Patrick
diff --git a/gnu/usr.bin/clang/Makefile b/gnu/usr.bin/clang/Makefile
index 250fb1d64f5..62490b00968 100644
--- a/gnu/usr.bin/clang/Makefile
+++ b/gnu/usr.bin/clang/Makefile
@@ -43,6 +43,8 @@ SUBDIR+=libLLVMCoverage
SUBDIR+=libLLVMDebugInfoCodeView
SUBDIR+=libLLVMDebugInfoDWARF
SUBDIR+=libLLVMDebugInfoMSF
+SUBDIR+=libLLVMDebugInfoPDB
+SUBDIR+=libLLVMExecutionEngine
SUBDIR+=libLLVMGlobalISel
SUBDIR+=libLLVMLTO
SUBDIR+=libLLVMPasses
@@ -86,5 +88,44 @@ SUBDIR+=liblldELF
SUBDIR+=lld
+SUBDIR+=liblldbABI
+SUBDIR+=liblldbAPI
+SUBDIR+=liblldbBreakpoint
+SUBDIR+=liblldbCommands
+SUBDIR+=liblldbCore
+SUBDIR+=liblldbDataFormatters
+SUBDIR+=liblldbExpression
+SUBDIR+=liblldbHostCommon
+SUBDIR+=liblldbHostOpenBSD
+SUBDIR+=liblldbHostPOSIX
+SUBDIR+=liblldbInitialization
+SUBDIR+=liblldbInterpreter
+SUBDIR+=liblldbPluginArchitecture
+SUBDIR+=liblldbPluginDisassembler
+SUBDIR+=liblldbPluginDynamicLoader
+SUBDIR+=liblldbPluginExpressionParser
+SUBDIR+=liblldbPluginInstruction
+SUBDIR+=liblldbPluginInstrumentationRuntime
+SUBDIR+=liblldbPluginJITLoader
+SUBDIR+=liblldbPluginLanguage
+SUBDIR+=liblldbPluginLanguageRuntime
+SUBDIR+=liblldbPluginMemoryHistory
+SUBDIR+=liblldbPluginObjectContainer
+SUBDIR+=liblldbPluginObjectFile
+SUBDIR+=liblldbPluginOperatingSystem
+SUBDIR+=liblldbPluginPlatform
+SUBDIR+=liblldbPluginProcess
+SUBDIR+=liblldbPluginScriptInterpreter
+SUBDIR+=liblldbPluginStructuredData
+SUBDIR+=liblldbPluginSymbolFile
+SUBDIR+=liblldbPluginSymbolVendor
+SUBDIR+=liblldbPluginSystemRuntime
+SUBDIR+=liblldbPluginUnwindAssembly
+SUBDIR+=liblldbSymbol
+SUBDIR+=liblldbTarget
+SUBDIR+=liblldbUtility
+
+SUBDIR+=lldb
+
.include
.include
diff --git a/gnu/usr.bin/clang/Makefile.inc b/gnu/usr.bin/clang/Makefile.inc
index 0b99edce43d..90fbe660c35 100644
--- a/gnu/usr.bin/clang/Makefile.inc
+++ b/gnu/usr.bin/clang/Makefile.inc
@@ -17,6 +17,8 @@ DEBUG=
NOPIE=
CLANG_INCLUDES=-I${LLVM_SRCS}/tools/clang/include
+LLDB_INCLUDES= -I${LLVM_SRCS}/tools/lldb/include \
+ -I${LLVM_SRCS}/tools/lldb/source
CPPFLAGS+= -I${LLVM_SRCS}/include -I${.CURDIR}/../include -I${.OBJDIR} \
-I${.OBJDIR}/../include
CPPFLAGS+= -DNDEBUG
@@ -42,6 +44,7 @@
CPPFLAGS+=-DLLVM_NATIVE_DISASSEMBLER=LLVMInitialize${LLVM_ARCH}Disassembler
CPPFLAGS+=-DLLVM_NATIVE_TARGET=LLVMInitialize${LLVM_ARCH}Target
CPPFLAGS+=-DLLVM_NATIVE_TARGETINFO=LLVMInitialize${LLVM_ARCH}TargetInfo
CPPFLAGS+=-DLLVM_NATIVE_TARGETMC=LLVMInitialize${LLVM_ARCH}TargetMC
+CPPFLAGS+=-DLLDB_DISABLE_PYTHON
# upstream defaults
CFLAGS+= -ffunction-sections
@@ -57,7 +60,9 @@ CXXFLAGS+=-Wall -W -Wno-unused-parameter -Wwrite-strings
-Wcast-qual \
-Wno-missing-field-initializers -pedantic -Wno-long-long \
-Wdelete-non-virtual-dtor -Wno-comment
+LDADD+=-Wl,--start-group
.for lib in ${LLVM_LIBDEPS}
DPADD+=${.OBJDIR}/../lib${lib}/lib${lib}.a
LDADD+=${.OBJDIR}/../lib${lib}/lib${lib}.a
.endfor
+LDADD+=-Wl,--end-group
diff --git a/gnu/usr.bin/clang/include/lldb/Host/Config.h
b/gnu/usr.bin/clang/include/lldb/Host/Config.h
new file mode 100644
index 000..1fc5396e2bb
--- /dev/null
+++ b/gnu/usr.bin/clang/include/lldb/Host/Config.h
@@ -0,0 +1,29 @@
+//===-- Config.h ---*- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#ifndef LLDB_HOST_CONFIG_H
+#define LLDB_HOST_CONFIG_H
+
+#define LLDB_CONFIG_TERMIOS_SUPPORTED
+
+/* #define LLDB_DISABLE_POSIX */
+
+#define HAVE_SYS_EVENT_H 1
+
+#define HAVE_PPOLL 1
+
+#define HAVE_SIGACTION 1
+
+#define HAVE_PROCESS_VM_READV 0
+
+#define HAVE_NR_PROCESS_VM_READV 0
+
+/* #define HAVE_LIBCOMPRESSION */
+
+#endif // #ifndef LLDB_HOST_CONFIG_H
diff --git a/gnu/usr.bin/clang/libLLVMDebugInfoCodeView/Makefile
b/gnu/usr.bin/clang/libLLVMDebugInfoCodeView/Makefile
index fbd9cd29083..f4d185d89f6 100644
--- a/gnu/usr.bin/clang/libLLVMDebugInfoCodeView/Makefile
+++ b/gnu/usr.bin/clang/libLLVMDebugInfoCodeView/Makefile
@@ -7,22 +7,41 @@ NOPROFILE=
CPPFLAGS+= -I${LLVM_SRCS}/include/llvm/DebugInfo/C
Re: [patch] Fix resource leak in netcat
On Tue, Oct 02, 2018 at 02:38:03AM +0200, Alexander Bluhm wrote: > On Sun, Sep 30, 2018 at 11:55:58AM +0800, Nan Xiao wrote: > > The following patch fixed the resource leak when netcat works as a TLS > > server. Sorry if I am wrong, thanks! > > There is another tls leak on the client side after > if (s == -1) > continue; > > To fix both I would do the tls_free() after close() consistently. ok
Re: [patch] Fix resource leak in netcat
Hi bluhm,
Thanks very much for your reply!
Yes, your patch covers all the corner cases, thanks!
On 10/2/2018 8:38 AM, Alexander Bluhm wrote:
> On Sun, Sep 30, 2018 at 11:55:58AM +0800, Nan Xiao wrote:
>> The following patch fixed the resource leak when netcat works as a TLS
>> server. Sorry if I am wrong, thanks!
>
> There is another tls leak on the client side after
> if (s == -1)
> continue;
>
> To fix both I would do the tls_free() after close() consistently.
>
> bluhm
>
> Index: usr.bin/nc/netcat.c
> ===
> RCS file: /data/mirror/openbsd/cvs/src/usr.bin/nc/netcat.c,v
> retrieving revision 1.194
> diff -u -p -r1.194 netcat.c
> --- usr.bin/nc/netcat.c 7 Sep 2018 09:55:29 - 1.194
> +++ usr.bin/nc/netcat.c 2 Oct 2018 00:35:03 -
> @@ -543,8 +543,6 @@ main(int argc, char *argv[])
> err(1, "pledge");
> }
> if (lflag) {
> - struct tls *tls_cctx = NULL;
> - int connfd;
> ret = 0;
>
> if (family == AF_UNIX) {
> @@ -603,6 +601,9 @@ main(int argc, char *argv[])
>
> readwrite(s, NULL);
> } else {
> + struct tls *tls_cctx = NULL;
> + int connfd;
> +
> len = sizeof(cliaddr);
> connfd = accept4(s, (struct sockaddr *)&cliaddr,
> &len, SOCK_NONBLOCK);
> @@ -618,12 +619,10 @@ main(int argc, char *argv[])
> readwrite(connfd, tls_cctx);
> if (!usetls)
> readwrite(connfd, NULL);
> - if (tls_cctx) {
> + if (tls_cctx)
> timeout_tls(s, tls_cctx, tls_close);
> - tls_free(tls_cctx);
> - tls_cctx = NULL;
> - }
> close(connfd);
> + tls_free(tls_cctx);
> }
> if (family == AF_UNIX && uflag) {
> if (connect(s, NULL, 0) < 0)
> @@ -657,6 +656,8 @@ main(int argc, char *argv[])
> for (s = -1, i = 0; portlist[i] != NULL; i++) {
> if (s != -1)
> close(s);
> + tls_free(tls_ctx);
> + tls_ctx = NULL;
>
> if (usetls) {
> if ((tls_ctx = tls_client()) == NULL)
> @@ -707,18 +708,15 @@ main(int argc, char *argv[])
> tls_setup_client(tls_ctx, s, host);
> if (!zflag)
> readwrite(s, tls_ctx);
> - if (tls_ctx) {
> + if (tls_ctx)
> timeout_tls(s, tls_ctx, tls_close);
> - tls_free(tls_ctx);
> - tls_ctx = NULL;
> - }
> }
> }
> }
>
> if (s != -1)
> close(s);
> -
> + tls_free(tls_ctx);
> tls_config_free(tls_cfg);
>
> return ret;
>
--
Best Regards
Nan Xiao(肖楠)
Re: [PATCH] Documentation clarification for uuid_create(3)
On Tue, Oct 02, 2018 at 10:52:53AM +0200, Theo Buehler wrote: > In-Reply-To: <20181002063056.GA30912@harkle> > > morning. hopefully someone can ok the content, but i'd be tempted to > > trim the text slightly: > > > > .Fn uuid_create > > generates version 4 UUIDs, > > specified by section 4.4 of RFC 4122. > > this is correct, ok for your trimmed version. > thanks for checking. will commit now.. jmc
[vi] moving by sentences is inconsistent
Hi, there is a flaw in base vi when moving by sentences, going forward is not equal to going backward. Here's what man vi says: [count] ( [count] ) Move count sentences backward or forward, respectively. A sentence is an area of text that begins with the first nonblank character following the previous sentence, paragraph, or section boundary and continues until the next period, exclamation mark, or question mark character, followed by any number of closing parentheses, brackets, double or single quote characters, followed by either an end-of-line or two whitespace characters. ^^ Groups of empty lines (or lines containing only whitespace characters) are treated as a single sentence. Going forward a sentence follows this rule, but going backwards stops at a single space before a punctuation mark. Here's an example: A sentence. A sentence containing !, ? and . A third sentence! )) ) (( ( ( When the double spaces are condensed to one, the whole line is regarded as one large sentence going forward, but the same pattern as above is shown when going backwards. With skippable characters, it is even more different: A sentence. A sentence containing [!'], '?' and . A third sentence! )) ) (( ( ( ( Again, with single spaces, the whole line is regarded as one going forwards, and the same behavior as above is shown when going backwards. Now, before doing any work, is there even any interest in fixing this, i.e. that moving for- and backwards produce the same results? If so, which behavior is desired? -- Nils
Re: [PATCH] Documentation clarification for uuid_create(3)
In-Reply-To: <20181002063056.GA30912@harkle> > morning. hopefully someone can ok the content, but i'd be tempted to > trim the text slightly: > > .Fn uuid_create > generates version 4 UUIDs, > specified by section 4.4 of RFC 4122. this is correct, ok for your trimmed version.
