Re: vmd: interface rdomains

[Mike Larkin]

On Wed, May 03, 2017 at 12:06:01PM +0200, Reyk Floeter wrote:
> Hi,
> 
> the attached diff adds support for rdomains in vmd.
> 
> In vm.conf, add an interface to a specified rdomain.  local interfaces
> work as expected, but the host-side routing and PF has to be done in
> the non-default rdomain as well.
> 
> vm "foo" {
>   local interface rdomain 1
>   interface {
>   rdomain 2
>   }
>   ...
> }
> 
> Or add all VM interfaces on a switch to a specified rdomain:
> 
> switch "bar" {
>   rdomain 1
>   ...
> }
> 
> OK?
> 

no objections, ok mlarkin if you didn't already get to this

> Reyk
> 
> Index: usr.sbin/vmd/config.c
> ===
> RCS file: /cvs/src/usr.sbin/vmd/config.c,v
> retrieving revision 1.30
> diff -u -p -u -p -r1.30 config.c
> --- usr.sbin/vmd/config.c 21 Apr 2017 07:03:26 -  1.30
> +++ usr.sbin/vmd/config.c 3 May 2017 10:02:58 -
> @@ -282,6 +282,9 @@ config_setvm(struct privsep *ps, struct 
>   }
>   }
>  
> + /* non-default rdomain (requires VMIFF_RDOMAIN below) */
> + vif->vif_rdomain = vmc->vmc_ifrdomain[i];
> +
>   /* Set the interface status */
>   vif->vif_flags =
>   vmc->vmc_ifflags[i] & (VMIFF_UP|VMIFF_OPTMASK);
> Index: usr.sbin/vmd/parse.y
> ===
> RCS file: /cvs/src/usr.sbin/vmd/parse.y,v
> retrieving revision 1.28
> diff -u -p -u -p -r1.28 parse.y
> --- usr.sbin/vmd/parse.y  3 May 2017 08:21:57 -   1.28
> +++ usr.sbin/vmd/parse.y  3 May 2017 10:02:59 -
> @@ -116,7 +116,7 @@ typedef struct {
>  
>  %token   INCLUDE ERROR
>  %token   ADD BOOT DISABLE DISK DOWN ENABLE GROUP INTERFACE LLADDR LOCAL 
> LOCKED
> -%token   MEMORY NIFS OWNER PATH PREFIX SIZE SWITCH UP VM VMID
> +%token   MEMORY NIFS OWNER PATH PREFIX RDOMAIN SIZE SWITCH UP VM VMID
>  %token NUMBER
>  %token STRING
>  %type  lladdr
> @@ -263,6 +263,14 @@ switch_opts  : disable   {
>   | LOCKED LLADDR {
>   vsw->sw_flags |= VMIFF_LOCKED;
>   }
> + | RDOMAIN NUMBER{
> + if ($2 < 0 || $2 > RT_TABLEID_MAX) {
> + yyerror("invalid rdomain: %lld", $2);
> + YYERROR;
> + }
> + vsw->sw_flags |= VMIFF_RDOMAIN;
> + vsw->sw_rdomain = $2;
> + }
>   | updown{
>   if ($1)
>   vsw->sw_flags |= VMIFF_UP;
> @@ -532,6 +540,14 @@ iface_opts   : SWITCH string {
>   vmc.vmc_ifflags[vcp_nnics] |= VMIFF_LOCKED;
>   memcpy(vcp->vcp_macs[vcp_nnics], $3, ETHER_ADDR_LEN);
>   }
> + | RDOMAIN NUMBER{
> + if ($2 < 0 || $2 > RT_TABLEID_MAX) {
> + yyerror("invalid rdomain: %lld", $2);
> + YYERROR;
> + }
> + vmc.vmc_ifflags[vcp_nnics] |= VMIFF_RDOMAIN;
> + vmc.vmc_ifrdomain[vcp_nnics] = $2;
> + }
>   | updown{
>   if ($1)
>   vmc.vmc_ifflags[vcp_nnics] |= VMIFF_UP;
> @@ -645,6 +661,7 @@ lookup(char *s)
>   { "memory", MEMORY },
>   { "owner",  OWNER },
>   { "prefix", PREFIX },
> + { "rdomain",RDOMAIN },
>   { "size",   SIZE },
>   { "switch", SWITCH },
>   { "up", UP },
> Index: usr.sbin/vmd/priv.c
> ===
> RCS file: /cvs/src/usr.sbin/vmd/priv.c,v
> retrieving revision 1.8
> diff -u -p -u -p -r1.8 priv.c
> --- usr.sbin/vmd/priv.c   21 Apr 2017 07:03:26 -  1.8
> +++ usr.sbin/vmd/priv.c   3 May 2017 10:02:59 -
> @@ -88,6 +88,7 @@ priv_dispatch_parent(int fd, struct priv
>   switch (imsg->hdr.type) {
>   case IMSG_VMDOP_PRIV_IFDESCR:
>   case IMSG_VMDOP_PRIV_IFCREATE:
> + case IMSG_VMDOP_PRIV_IFRDOMAIN:
>   case IMSG_VMDOP_PRIV_IFADD:
>   case IMSG_VMDOP_PRIV_IFUP:
>   case IMSG_VMDOP_PRIV_IFDOWN:
> @@ -124,6 +125,12 @@ priv_dispatch_parent(int fd, struct priv
>   errno != EEXIST)
>   log_warn("SIOCIFCREATE");
>   break;
> + case IMSG_VMDOP_PRIV_IFRDOMAIN:
> + strlcpy(ifr.ifr_name, vfr.vfr_name, sizeof(ifr.ifr_name));
> + ifr.ifr_rdomainid = vfr.vfr_id;
> + if (ioctl(env->vmd_fd, 

Re: arm64 lock: no userland progress, several procs in wchan "vp"

[Mark Kettenis]

> Date: Wed, 3 May 2017 21:05:24 +0100
> From: Stuart Henderson 
> 
> On 2017/05/03 15:12, Mark Kettenis wrote:
> > > Date: Wed, 3 May 2017 13:51:22 +0100
> > > From: Stuart Henderson 
> > > 
> > > On 2017/05/01 22:18, Mark Kettenis wrote:
> > > > > Date: Mon, 1 May 2017 20:58:29 +0100
> > > > > From: Stuart Henderson 
> > > > > 
> > > > > Userland is non-responsive, machine is pingable, tcp connections open
> > > > > but no banner from ssh. No failed pool requests. This kernel is from
> > > > > today's snapshot but I saw the same with one from a couple of days
> > > > > ago.  Is there anything else I can get that might be useful?
> > > > > 
> > > ..
> > > > >  71034  186155  65198  0  30x11  vpperl
> > > ..
> > > > 
> > > > The diff below might fix thise.  Or it might actually turn this into a
> > > > hard hang...
> > > > 
> > > > Nevertheless, could you try running with it?
> > > 
> > > I haven't seen this happen again with your diff, and haven't seen any
> > > hangs. Probably still too early to say for sure that it fixes things,
> > > but it looks promising so far.
> > 
> > Thanks.  Since Dale ok'ed it and I had been running with it for a
> > while already, I committed it last night.
> > 
> 
> Ha. As is traditional, not long after sending that message I've hit
> a hard lock - no DDB.

I'm sure it wouldn't have happened if I hand't committed it ;).

Could you change the PR_NOWAIT back into P_WAITOK and see if you can
reproduce the hang and break into ddb?  Meanwhile I'll think about
what information to print once you've hit it ;).

Re: Official OpenBSD 6.1 CD !

[Sterling Archer]

On Wed, May 3, 2017 at 10:33 PM, Bob Beck  wrote:

> So.  There *Is* an official OpenBSD 6.1 CD
>
> Just One.
>
> If you are interested, please bid on ebay :
>
> http://www.ebay.com/itm/The-only-Official-OpenBSD-6-1-CD-
> set-to-be-made-For-auction-for-the-project-/252910718452?
> hash=item3ae2a74df4:g:SJQAAOSwrhBZBqkd
>
> (It's a pretty cool little CD set!)
>

Fantastic idea, I hope you raise a lot of money selling it.

Official OpenBSD 6.1 CD !

[Bob Beck]

So.  There *Is* an official OpenBSD 6.1 CD

Just One.

If you are interested, please bid on ebay :

http://www.ebay.com/itm/The-only-Official-OpenBSD-6-1-CD-set-to-be-made-For-auction-for-the-project-/252910718452?hash=item3ae2a74df4:g:SJQAAOSwrhBZBqkd

(It's a pretty cool little CD set!)

Re: OpenBSD Errata: May 2nd, 2017

[Antoine Jacoutot]

On Tue, May 02, 2017 at 10:26:02PM -0400, T.J. Townsend wrote:
> Errata patches for dhcpd, vmm, LibreSSL and softraid have been released
> for OpenBSD 6.1 today.
> 
> Details can be found on this page: https://www.openbsd.org/errata61.html
> 
> Binary updates for the amd64 and i386 platforms are also available via
> the syspatch utility. Note that syspatch uses the mirror configured in
> /etc/installurl, so all mirrors may not have the files yet.

Hi folks.

Due to a mistake in creating the syspatch archives, a multi-processor machine
would not default to the MP kernel. New syspatches have been re-rolled and
you're advised to revert and re-apply them (even on non-MP machines). Make sure
your mirror (/etc/installurl) has the new syspatches first (dated May 3rd).

As root:
while true; do syspatch -r || break; done
syspatch

If you're running on a multi-processor machine, you may also remove the extra
/bsd.mp kernel. Sorry about that and thank you all for your report and feedback.

-- 
Antoine

Re: arm64 lock: no userland progress, several procs in wchan "vp"

[Stuart Henderson]

On 2017/05/03 15:12, Mark Kettenis wrote:
> > Date: Wed, 3 May 2017 13:51:22 +0100
> > From: Stuart Henderson 
> > 
> > On 2017/05/01 22:18, Mark Kettenis wrote:
> > > > Date: Mon, 1 May 2017 20:58:29 +0100
> > > > From: Stuart Henderson 
> > > > 
> > > > Userland is non-responsive, machine is pingable, tcp connections open
> > > > but no banner from ssh. No failed pool requests. This kernel is from
> > > > today's snapshot but I saw the same with one from a couple of days
> > > > ago.  Is there anything else I can get that might be useful?
> > > > 
> > ..
> > > >  71034  186155  65198  0  30x11  vpperl
> > ..
> > > 
> > > The diff below might fix thise.  Or it might actually turn this into a
> > > hard hang...
> > > 
> > > Nevertheless, could you try running with it?
> > 
> > I haven't seen this happen again with your diff, and haven't seen any
> > hangs. Probably still too early to say for sure that it fixes things,
> > but it looks promising so far.
> 
> Thanks.  Since Dale ok'ed it and I had been running with it for a
> while already, I committed it last night.
> 

Ha. As is traditional, not long after sending that message I've hit
a hard lock - no DDB.

Re: arm64 lock: no userland progress, several procs in wchan "vp"

[Mark Kettenis]

> Date: Wed, 3 May 2017 13:51:22 +0100
> From: Stuart Henderson 
> 
> On 2017/05/01 22:18, Mark Kettenis wrote:
> > > Date: Mon, 1 May 2017 20:58:29 +0100
> > > From: Stuart Henderson 
> > > 
> > > Userland is non-responsive, machine is pingable, tcp connections open
> > > but no banner from ssh. No failed pool requests. This kernel is from
> > > today's snapshot but I saw the same with one from a couple of days
> > > ago.  Is there anything else I can get that might be useful?
> > > 
> ..
> > >  71034  186155  65198  0  30x11  vpperl
> ..
> > 
> > The diff below might fix thise.  Or it might actually turn this into a
> > hard hang...
> > 
> > Nevertheless, could you try running with it?
> 
> I haven't seen this happen again with your diff, and haven't seen any
> hangs. Probably still too early to say for sure that it fixes things,
> but it looks promising so far.

Thanks.  Since Dale ok'ed it and I had been running with it for a
while already, I committed it last night.

Re: arm64 lock: no userland progress, several procs in wchan "vp"

[Stuart Henderson]

On 2017/05/01 22:18, Mark Kettenis wrote:
> > Date: Mon, 1 May 2017 20:58:29 +0100
> > From: Stuart Henderson 
> > 
> > Userland is non-responsive, machine is pingable, tcp connections open
> > but no banner from ssh. No failed pool requests. This kernel is from
> > today's snapshot but I saw the same with one from a couple of days
> > ago.  Is there anything else I can get that might be useful?
> > 
..
> >  71034  186155  65198  0  30x11  vpperl
..
> 
> The diff below might fix thise.  Or it might actually turn this into a
> hard hang...
> 
> Nevertheless, could you try running with it?

I haven't seen this happen again with your diff, and haven't seen any
hangs. Probably still too early to say for sure that it fixes things,
but it looks promising so far.

Re: less(1): plug memory leak

[Todd C. Miller]

On Wed, 03 May 2017 08:03:06 +0200, Anton Lindqvist wrote:

> On Mon, May 01, 2017 at 01:36:51PM +0100, Nicholas Marriott wrote:
> > 
> > looks good, ok nicm
> 
> Anyone willing to commit?

Committed.

 - todd

rdate(8): correctly specify supported NTP versions

[Ivan Markin]

Hello tech@,

On receiving a packet with unsupported versions rdate(8) says
that "Received NTP version %u, need 4 or lower". This is not quite
true. Supported versions are 1, 2, 3, 4 and not 0.

Index: ntp.c
===
RCS file: /cvs/src/usr.sbin/rdate/ntp.c,v
retrieving revision 1.33
diff -u -p -r1.33 ntp.c
--- ntp.c   16 Jan 2015 06:40:20 -  1.33
+++ ntp.c   3 May 2017 10:26:10 -
@@ -347,8 +347,8 @@ retry:

if (data->version < NTP_VERSION_MIN ||
data->version > NTP_VERSION_MAX) {
-   warnx("Received NTP version %u, need %u or lower",
-   data->version, NTP_VERSION);
+   warnx("Received NTP version %u, need at least %u or at most %u",
+   data->version, NTP_VERSION_MIN, NTP_VERSION_MAX);
return (1);
}

vmd: interface rdomains

[Reyk Floeter]

Hi,

the attached diff adds support for rdomains in vmd.

In vm.conf, add an interface to a specified rdomain.  local interfaces
work as expected, but the host-side routing and PF has to be done in
the non-default rdomain as well.

vm "foo" {
local interface rdomain 1
interface {
rdomain 2
}
...
}

Or add all VM interfaces on a switch to a specified rdomain:

switch "bar" {
rdomain 1
...
}

OK?

Reyk

Index: usr.sbin/vmd/config.c
===
RCS file: /cvs/src/usr.sbin/vmd/config.c,v
retrieving revision 1.30
diff -u -p -u -p -r1.30 config.c
--- usr.sbin/vmd/config.c   21 Apr 2017 07:03:26 -  1.30
+++ usr.sbin/vmd/config.c   3 May 2017 10:02:58 -
@@ -282,6 +282,9 @@ config_setvm(struct privsep *ps, struct 
}
}
 
+   /* non-default rdomain (requires VMIFF_RDOMAIN below) */
+   vif->vif_rdomain = vmc->vmc_ifrdomain[i];
+
/* Set the interface status */
vif->vif_flags =
vmc->vmc_ifflags[i] & (VMIFF_UP|VMIFF_OPTMASK);
Index: usr.sbin/vmd/parse.y
===
RCS file: /cvs/src/usr.sbin/vmd/parse.y,v
retrieving revision 1.28
diff -u -p -u -p -r1.28 parse.y
--- usr.sbin/vmd/parse.y3 May 2017 08:21:57 -   1.28
+++ usr.sbin/vmd/parse.y3 May 2017 10:02:59 -
@@ -116,7 +116,7 @@ typedef struct {
 
 %token INCLUDE ERROR
 %token ADD BOOT DISABLE DISK DOWN ENABLE GROUP INTERFACE LLADDR LOCAL LOCKED
-%token MEMORY NIFS OWNER PATH PREFIX SIZE SWITCH UP VM VMID
+%token MEMORY NIFS OWNER PATH PREFIX RDOMAIN SIZE SWITCH UP VM VMID
 %token   NUMBER
 %token   STRING
 %typelladdr
@@ -263,6 +263,14 @@ switch_opts: disable   {
| LOCKED LLADDR {
vsw->sw_flags |= VMIFF_LOCKED;
}
+   | RDOMAIN NUMBER{
+   if ($2 < 0 || $2 > RT_TABLEID_MAX) {
+   yyerror("invalid rdomain: %lld", $2);
+   YYERROR;
+   }
+   vsw->sw_flags |= VMIFF_RDOMAIN;
+   vsw->sw_rdomain = $2;
+   }
| updown{
if ($1)
vsw->sw_flags |= VMIFF_UP;
@@ -532,6 +540,14 @@ iface_opts : SWITCH string {
vmc.vmc_ifflags[vcp_nnics] |= VMIFF_LOCKED;
memcpy(vcp->vcp_macs[vcp_nnics], $3, ETHER_ADDR_LEN);
}
+   | RDOMAIN NUMBER{
+   if ($2 < 0 || $2 > RT_TABLEID_MAX) {
+   yyerror("invalid rdomain: %lld", $2);
+   YYERROR;
+   }
+   vmc.vmc_ifflags[vcp_nnics] |= VMIFF_RDOMAIN;
+   vmc.vmc_ifrdomain[vcp_nnics] = $2;
+   }
| updown{
if ($1)
vmc.vmc_ifflags[vcp_nnics] |= VMIFF_UP;
@@ -645,6 +661,7 @@ lookup(char *s)
{ "memory", MEMORY },
{ "owner",  OWNER },
{ "prefix", PREFIX },
+   { "rdomain",RDOMAIN },
{ "size",   SIZE },
{ "switch", SWITCH },
{ "up", UP },
Index: usr.sbin/vmd/priv.c
===
RCS file: /cvs/src/usr.sbin/vmd/priv.c,v
retrieving revision 1.8
diff -u -p -u -p -r1.8 priv.c
--- usr.sbin/vmd/priv.c 21 Apr 2017 07:03:26 -  1.8
+++ usr.sbin/vmd/priv.c 3 May 2017 10:02:59 -
@@ -88,6 +88,7 @@ priv_dispatch_parent(int fd, struct priv
switch (imsg->hdr.type) {
case IMSG_VMDOP_PRIV_IFDESCR:
case IMSG_VMDOP_PRIV_IFCREATE:
+   case IMSG_VMDOP_PRIV_IFRDOMAIN:
case IMSG_VMDOP_PRIV_IFADD:
case IMSG_VMDOP_PRIV_IFUP:
case IMSG_VMDOP_PRIV_IFDOWN:
@@ -124,6 +125,12 @@ priv_dispatch_parent(int fd, struct priv
errno != EEXIST)
log_warn("SIOCIFCREATE");
break;
+   case IMSG_VMDOP_PRIV_IFRDOMAIN:
+   strlcpy(ifr.ifr_name, vfr.vfr_name, sizeof(ifr.ifr_name));
+   ifr.ifr_rdomainid = vfr.vfr_id;
+   if (ioctl(env->vmd_fd, SIOCSIFRDOMAIN, ) < 0)
+   log_warn("SIOCSIFRDOMAIN");
+   break;
case IMSG_VMDOP_PRIV_IFADD:
if (priv_getiftype(vfr.vfr_value, type, NULL) == -1)
fatalx("%s: rejected to add interface: %s",
@@ -272,6 +279,17 @@ 

what does "internet stream tcp 0x0 *:0" mean?

[Stuart Henderson]

I've got an amd64 web app server running 6.0/tomcat 7.0/jdk 1.8.
Occasionally I get a lot of FDs building up, looking like this in
fstat:

$ fstat | grep internet.stream.tcp | head -1500 |tail -5  
_tomcat  java   88950 1585* internet stream tcp 0x0 *:0
_tomcat  java   88950 1586* internet stream tcp 0x0 *:0
_tomcat  java   88950 1587* internet stream tcp 0x0 *:0
_tomcat  java   88950 1588* internet stream tcp 0x0 *:0
_tomcat  java   88950 1589* internet stream tcp 0x0 *:0

While I'm trying to figure out from the other side what's triggering
them, does anyone have an idea what these "*:0" entries are? They
don't show up in netstat.

If I capture earlier fstat output and match up the FD numbers they're
just outgoing connections from the web app (e.g. HTTP API fetches etc)
and at some point "something" happens and they change to the "*:0"
entries.

$ fstat | fgrep -c "internet stream tcp 0x0 *:0"
4678

$ fstat | grep -c internet.*tcp
5031

$ netstat -anfinet | grep -c tcp
570

$ netstat -anfinet | grep tcp | cut -c70- | sort | uniq -c
 166 CLOSE_WAIT
 126 ESTABLISHED
   4 FIN_WAIT_2
  23 LISTEN
 251 TIME_WAIT

Any clues greatly appreciated!

OpenBSD 6.0 (GENERIC.MP) #2: Mon Oct 17 10:22:47 CEST 2016

r...@stable-60-amd64.mtier.org:/binpatchng/work-binpatch60-amd64/src/sys/arch/amd64/compile/GENERIC.MP
RTC BIOS diagnostic error 80
real mem = 8562929664 (8166MB)
avail mem = 8298942464 (7914MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe6720 (57 entries)
bios0: vendor Dell Inc. version "1.2.3" date 07/21/2011
bios0: Dell Inc. PowerEdge R210 II
acpi0 at bios0: rev 2
acpi0: sleep states S0 S4 S5
acpi0: tables DSDT FACP SPMI ASF! HPET APIC MCFG BOOT SSDT ASPT SSDT SSDT SPCR 
HEST ERST BERT EINJ
acpi0: wakeup devices P0P1(S4) GLAN(S0) EHC1(S4) EHC2(S4) PXSX(S4) RP01(S5) 
PXSX(S4) RP02(S5) PXSX(S4) RP03(S5) PXSX(S4) RP04(S5) PXSX(S4) RP05(S5) 
PXSX(S4) RP06(S5) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i3-2100 CPU @ 3.10GHz, 3100.51 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 100MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM) i3-2100 CPU @ 3.10GHz, 3100.02 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 1, core 0, package 0
cpu2 at mainbus0: apid 2 (application processor)
cpu2: Intel(R) Core(TM) i3-2100 CPU @ 3.10GHz, 3100.02 MHz
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 1, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM) i3-2100 CPU @ 3.10GHz, 3100.02 MHz
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 1, core 1, package 0
ioapic0 at mainbus0: apid 0 pa 0xfec0, version 20, 24 pins
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 3 (P0P1)
acpiprt2 at acpi0: bus 2 (RP01)
acpiprt3 at acpi0: bus -1 (RP02)
acpiprt4 at acpi0: bus -1 (RP03)
acpiprt5 at acpi0: bus -1 (RP04)
acpiprt6 at acpi0: bus -1 (RP05)
acpiprt7 at acpi0: bus -1 (RP06)
acpiprt8 at acpi0: bus -1 (RP07)
acpiprt9 at acpi0: bus -1 (RP08)
acpiprt10 at acpi0: bus 1 (PEG0)
acpiprt11 at acpi0: bus -1 (PEG1)
acpiprt12 at acpi0: bus -1 (PEG2)
acpiprt13 at acpi0: bus -1 (PEG3)
acpicpu0 at acpi0: C3(350@104 mwait.1@0x20), C2(500@80 mwait.1@0x10), C1(1000@1 
mwait.1), PSS
acpicpu1 at acpi0: C3(350@104 mwait.1@0x20), C2(500@80 mwait.1@0x10), C1(1000@1 
mwait.1), PSS
acpicpu2 at acpi0: C3(350@104 mwait.1@0x20), C2(500@80 mwait.1@0x10), C1(1000@1 
mwait.1), PSS
acpicpu3 at acpi0: C3(350@104 mwait.1@0x20), C2(500@80 mwait.1@0x10), C1(1000@1 
mwait.1), PSS
acpipwrres0 at 

Re: Fix umb(4) on big-endian machines

[Stefan Sperling]

On Wed, May 03, 2017 at 10:12:04AM +0200, Gerhard Roth wrote:
> Hi,
> 
> all MBIM values are in litte-endian encoding but somewhere in the fine
> print it reads that "the addresses will be in network byte order".
> 
> So applying letoh32() on addresses is just plain wrong. On little-endian
> machines, we didn't notice since letoh32() is a no-op there. But one
> big-endian ones, the driver used IP addresses in the wrong byte order.
> 
> Cheers,
> 
> Gerhard
> 

ok

I don't have a big-endian machine with umb(4) to test with, though.

> 
> 
> Index: sys/dev/usb/if_umb.c
> ===
> RCS file: /cvs/src/sys/dev/usb/if_umb.c,v
> retrieving revision 1.11
> diff -u -p -u -p -r1.11 if_umb.c
> --- sys/dev/usb/if_umb.c  18 Apr 2017 13:27:55 -  1.11
> +++ sys/dev/usb/if_umb.c  2 May 2017 14:41:32 -
> @@ -1646,7 +1646,6 @@ umb_decode_ip_configuration(struct umb_s
>  
>   /* Only pick the first one */
>   memcpy(, data + off, sizeof (ipv4elem));
> - ipv4elem.addr = letoh32(ipv4elem.addr);
>   ipv4elem.prefixlen = letoh32(ipv4elem.prefixlen);
>  
>   memset(, 0, sizeof (ifra));
> @@ -1660,8 +1659,7 @@ umb_decode_ip_configuration(struct umb_s
>   sin->sin_len = sizeof (ifra.ifra_dstaddr);
>   if (avail & MBIM_IPCONF_HAS_GWINFO) {
>   off = letoh32(ic->ipv4_gwoffs);
> - sin->sin_addr.s_addr =
> - letoh32(*((uint32_t *)(data + off)));
> + sin->sin_addr.s_addr = *((uint32_t *)(data + off));
>   }
>  
>   sin = (struct sockaddr_in *)_mask;
> @@ -1690,7 +1688,7 @@ umb_decode_ip_configuration(struct umb_s
>   while (n-- > 0) {
>   if (off + sizeof (uint32_t) > len)
>   break;
> - val = letoh32(*((uint32_t *)(data + off)));
> + val = *((uint32_t *)(data + off));
>   if (i < UMB_MAX_DNSSRV)
>   sc->sc_info.ipv4dns[i++] = val;
>   off += sizeof (uint32_t);
> 

Fix umb(4) on big-endian machines

[Gerhard Roth]

Hi,

all MBIM values are in litte-endian encoding but somewhere in the fine
print it reads that "the addresses will be in network byte order".

So applying letoh32() on addresses is just plain wrong. On little-endian
machines, we didn't notice since letoh32() is a no-op there. But one
big-endian ones, the driver used IP addresses in the wrong byte order.

Cheers,

Gerhard



Index: sys/dev/usb/if_umb.c
===
RCS file: /cvs/src/sys/dev/usb/if_umb.c,v
retrieving revision 1.11
diff -u -p -u -p -r1.11 if_umb.c
--- sys/dev/usb/if_umb.c18 Apr 2017 13:27:55 -  1.11
+++ sys/dev/usb/if_umb.c2 May 2017 14:41:32 -
@@ -1646,7 +1646,6 @@ umb_decode_ip_configuration(struct umb_s
 
/* Only pick the first one */
memcpy(, data + off, sizeof (ipv4elem));
-   ipv4elem.addr = letoh32(ipv4elem.addr);
ipv4elem.prefixlen = letoh32(ipv4elem.prefixlen);
 
memset(, 0, sizeof (ifra));
@@ -1660,8 +1659,7 @@ umb_decode_ip_configuration(struct umb_s
sin->sin_len = sizeof (ifra.ifra_dstaddr);
if (avail & MBIM_IPCONF_HAS_GWINFO) {
off = letoh32(ic->ipv4_gwoffs);
-   sin->sin_addr.s_addr =
-   letoh32(*((uint32_t *)(data + off)));
+   sin->sin_addr.s_addr = *((uint32_t *)(data + off));
}
 
sin = (struct sockaddr_in *)_mask;
@@ -1690,7 +1688,7 @@ umb_decode_ip_configuration(struct umb_s
while (n-- > 0) {
if (off + sizeof (uint32_t) > len)
break;
-   val = letoh32(*((uint32_t *)(data + off)));
+   val = *((uint32_t *)(data + off));
if (i < UMB_MAX_DNSSRV)
sc->sc_info.ipv4dns[i++] = val;
off += sizeof (uint32_t);

Re: less(1): plug memory leak

[Anton Lindqvist]

On Mon, May 01, 2017 at 01:36:51PM +0100, Nicholas Marriott wrote:
> 
> looks good, ok nicm

Anyone willing to commit?

> On Mon, May 01, 2017 at 10:35:59AM +0200, Tobias Stoeckmann wrote:
> > Hi,
> > 
> > On Mon, May 01, 2017 at 09:15:45AM +0200, Anton Lindqvist wrote:
> > > While freeing tag entries, make sure to free the copied strings.
> > 
> > this patch looks good to me.
> > 
> > Have you reported this to the upstream less maintainers, as well?
> > The original less and the forked one from Garrett D'Amore, which we
> > use as foundation, have the same issue in them.
> > 
> > 
> > Tobias
> > 
> > > Index: tags.c
> > > ===
> > > RCS file: /cvs/src/usr.bin/less/tags.c,v
> > > retrieving revision 1.18
> > > diff -u -p -r1.18 tags.c
> > > --- tags.c17 Sep 2016 15:06:41 -  1.18
> > > +++ tags.c30 Apr 2017 18:13:24 -
> > > @@ -77,6 +77,8 @@ cleantags(void)
> > >*/
> > >   while ((tp = taglist.tl_first) != TAG_END) {
> > >   TAG_RM(tp);
> > > + free(tp->tag_file);
> > > + free(tp->tag_pattern);
> > >   free(tp);
> > >   }
> > >   curtag = NULL;
> > > 
> > 
>