Re: vmm/i386 VMM_DEBUG

[Michael W. Bombardieri]

Works for me here.

On Tue, Apr 11, 2017 at 09:35:13PM -0700, Philip Guenther wrote:
> On Wed, 12 Apr 2017, Michael W. Bombardieri wrote:
> > Building with VMM_DEBUG enabled failed because a printf() warning was 
> > treated as an error.
> ...
> > DPRINTF("%s: function 0x07 (SEFF) unsupported subleaf "
> > -   "0x%llx not supported\n", __func__, *ecx);
> > +   "0x%lx not supported\n", __func__,
> > +   (unsigned long)*ecx);
> 
> Hmm, uint32_t is expected to be unsigned int in other printf formats in 
> the file (and elsewhere in the kernel), so I think the cast is unnecessary 
> here and we can just go with:
> 
> --- vmm.c 25 Mar 2017 22:24:01 -  1.26
> +++ vmm.c 12 Apr 2017 04:33:04 -
> @@ -4353,7 +4353,7 @@ vmm_handle_cpuid(struct vcpu *vcpu)
>   } else {
>   /* Unsupported subleaf */
>   DPRINTF("%s: function 0x07 (SEFF) unsupported subleaf "
> - "0x%llx not supported\n", __func__, *ecx);
> + "0x%x not supported\n", __func__, *ecx);
>   *eax = 0;
>   *ebx = 0;
>   *ecx = 0;
> 

Re: vmm/i386 VMM_DEBUG

[Mike Larkin]

On Tue, Apr 11, 2017 at 09:35:13PM -0700, Philip Guenther wrote:
> On Wed, 12 Apr 2017, Michael W. Bombardieri wrote:
> > Building with VMM_DEBUG enabled failed because a printf() warning was 
> > treated as an error.
> ...
> > DPRINTF("%s: function 0x07 (SEFF) unsupported subleaf "
> > -   "0x%llx not supported\n", __func__, *ecx);
> > +   "0x%lx not supported\n", __func__,
> > +   (unsigned long)*ecx);
> 
> Hmm, uint32_t is expected to be unsigned int in other printf formats in 
> the file (and elsewhere in the kernel), so I think the cast is unnecessary 
> here and we can just go with:
> 
> --- vmm.c 25 Mar 2017 22:24:01 -  1.26
> +++ vmm.c 12 Apr 2017 04:33:04 -
> @@ -4353,7 +4353,7 @@ vmm_handle_cpuid(struct vcpu *vcpu)
>   } else {
>   /* Unsupported subleaf */
>   DPRINTF("%s: function 0x07 (SEFF) unsupported subleaf "
> - "0x%llx not supported\n", __func__, *ecx);
> + "0x%x not supported\n", __func__, *ecx);
>   *eax = 0;
>   *ebx = 0;
>   *ecx = 0;
>

ok mlarkin 

Re: vmm/i386 VMM_DEBUG

[Philip Guenther]

On Wed, 12 Apr 2017, Michael W. Bombardieri wrote:
> Building with VMM_DEBUG enabled failed because a printf() warning was 
> treated as an error.
...
>   DPRINTF("%s: function 0x07 (SEFF) unsupported subleaf "
> - "0x%llx not supported\n", __func__, *ecx);
> + "0x%lx not supported\n", __func__,
> + (unsigned long)*ecx);

Hmm, uint32_t is expected to be unsigned int in other printf formats in 
the file (and elsewhere in the kernel), so I think the cast is unnecessary 
here and we can just go with:

--- vmm.c   25 Mar 2017 22:24:01 -  1.26
+++ vmm.c   12 Apr 2017 04:33:04 -
@@ -4353,7 +4353,7 @@ vmm_handle_cpuid(struct vcpu *vcpu)
} else {
/* Unsupported subleaf */
DPRINTF("%s: function 0x07 (SEFF) unsupported subleaf "
-   "0x%llx not supported\n", __func__, *ecx);
+   "0x%x not supported\n", __func__, *ecx);
*eax = 0;
*ebx = 0;
*ecx = 0;

vmm/i386 VMM_DEBUG

[Michael W. Bombardieri]

Hi,

Building with VMM_DEBUG enabled failed because a printf() warning
was treated as an error.

- Michael


cc1: warnings being treated as errors
/usr/src/src/sys/arch/i386/i386/vmm.c: In function 'vmm_handle_cpuid':
/usr/src/src/sys/arch/i386/i386/vmm.c:4355: warning: format '%llx' expects type 
'long long unsigned int', but argument 3 has type 'uint32_t'
*** Error 1 in /usr/src/src/sys/arch/i386/compile/GENERIC (Makefile:1021 
'vmm.o')

Index: vmm.c
===
RCS file: /cvs/src/sys/arch/i386/i386/vmm.c,v
retrieving revision 1.26
diff -u -p -u -r1.26 vmm.c
--- vmm.c   25 Mar 2017 22:24:01 -  1.26
+++ vmm.c   12 Apr 2017 05:00:03 -
@@ -4353,7 +4353,8 @@ vmm_handle_cpuid(struct vcpu *vcpu)
} else {
/* Unsupported subleaf */
DPRINTF("%s: function 0x07 (SEFF) unsupported subleaf "
-   "0x%llx not supported\n", __func__, *ecx);
+   "0x%lx not supported\n", __func__,
+   (unsigned long)*ecx);
*eax = 0;
*ebx = 0;
*ecx = 0;

Re: patch: mv(1): Add -p flag to preserve time stamps for moved directories

[bytevolcano]

On Tue, 11 Apr 2017 19:39:28 -0700
Philip Guenther  wrote:

> The 'issue' is that he's changing the parent of a directory and that
> means it has to update the ".." link inside the directory, so it
> alters the directory contents and the mtime is thus updated.

That explains a lot. I thought the ".." link was a dynamic OS-created
entity, rather than something that's actually in the FS.

Though this is inconsistent with preserving the mtime when moving the
directory across filesystems, which also changes the parent.

> 
> 
> If I hit this, I would have to reconsider why I'm using the mtime of
> the directory for whatever alternate purpose makes me want to preserve
> the timestamp here.  If changing that use case is too much effort,
> then I would just script the preservation and use "touch -r" to copy
> the timestamps to a placeholder file, do the move, then "touch -r"
> again to restore them.  Introducing a non-standard option for this
> particular case pushes the cost the wrong direction, IMO.

I agree with that logic to a large extent.

I was initially thinking a similar thing, but then I got the idea that,
since cp(1) has such an option to preserve the time stamps, it seems
logical for mv(1) to have a similar option as well, and it is such a
trivial thing to add.

Re: patch: mv(1): Add -p flag to preserve time stamps for moved directories

[Philip Guenther]

On Tue, Apr 11, 2017 at 6:53 PM, Bob Beck  wrote:
>
>> Note that I have noatime on this FS.
>
> then turn that off, or understand that things will not behave as you expect 
> them to with it on.

Nah, the noatime is a red herring, nicely smeared across the evidence
trail here.

The 'issue' is that he's changing the parent of a directory and that
means it has to update the ".." link inside the directory, so it
alters the directory contents and the mtime is thus updated.


If I hit this, I would have to reconsider why I'm using the mtime of
the directory for whatever alternate purpose makes me want to preserve
the timestamp here.  If changing that use case is too much effort,
then I would just script the preservation and use "touch -r" to copy
the timestamps to a placeholder file, do the move, then "touch -r"
again to restore them.  Introducing a non-standard option for this
particular case pushes the cost the wrong direction, IMO.


Philip Guenther

Re: patch: mv(1): Add -p flag to preserve time stamps for moved directories

[Bob Beck]

> Note that I have noatime on this FS.

then turn that off, or understand that things will not behave as you expect 
them to with it on. 

Re: patch: mv(1): Add -p flag to preserve time stamps for moved directories

[bytevolcano]

Sorry I was copying this out from a VM, so I ended up typing it up
wrong here:

$ mkdir Foo
$ touch -t 2101 Foo
$ ls -dlT Foo
drwxr-xr-x  2 bob  bob  512 Jan  1 00:00:00 2000 Foo
$ ls -dluT Foo
drwxr-xr-x  2 bob  bob  512 Jan  1 00:00:00 2000 Foo
$ mkdir Bar
$ mv Foo Bar/
$ ls -dlT Bar/Foo
drwxr-xr-x  2 bob  bob  512 Apr 12 07:55:30 2017 Bar/Foo
$ ls -dluT Bar/Foo
drwxr-xr-x  2 bob  bob  512 Jan  1 00:00:00 2000 Bar/Foo

Running openbsd -current (Feb 26)

On Wed, 12 Apr 2017 08:37:37 +1000
 wrote:

> On Tue, 11 Apr 2017 16:54:29 +0200
> Ingo Schwarze  wrote:
> 
> > Hi,
> > 
> > bytevolc...@safe-mail.net wrote on Fri, Apr 07, 2017 at 12:25:10PM
> > +1000:
> >   
> > > Although mv(1) will preserve atime and mtime for moved directories
> > > if moved to a different file system, it doesn't preserve them when
> > > moved in the same file system.
> > 
> > Cannot reproduce.
> > 
> >$ mkdir Foo
> >$ touch -t 2101 Foo 
> >$ ls -dl Foo
> >   drwxr-xr-x  2 schwarze  schwarze  512 Jan  1  2000 Foo
> >$ ls -dlu Foo
> >   drwxr-xr-x  2 schwarze  schwarze  512 Jan  1  2000 Foo
> >$ mv Foo Bar
> >$ ls -dl Bar  
> >   drwxr-xr-x  2 schwarze  schwarze  512 Jan  1  2000 Bar
> >$ ls -dlu Bar
> >   drwxr-xr-x  2 schwarze  schwarze  512 Jan  1  2000 Bar  
> 
> I can:
> 
> $ mkdir Foo
> $ touch -t 2101 Foo
> $ ls -dlT Foo
> drwxr-xr-x  2 bob  bob  512 Jan  1 00:00:00 2000 Foo
> $ ls -dluT Foo
> drwxr-xr-x  2 bob  bob  512 Jan  1 00:00:00 2000 Foo
> $ mkdir Bar
> $ mv Foo Bar/
> $ ls -dlT Bar/Foo
> drwxr-xr-x  2 bob  bob  512 Apr 12 07:55:30 2017 Foo/Bar
> $ ls -dluT Bar/Foo
> drwxr-xr-x  2 bob  bob  512 Jan  1 00:00:00 2000 Foo/Bar
> 
> Note that I have noatime on this FS.
> 
> > Sounds like a bad idea.  Do not add non-standard options to standard
> > utilities unless they are useful to a very unusual degree.  Even if
> > there is some corner case that you failed to describe, this seems
> > by far not important enough for adding an option.  
> 
> The problem I am solving here is that, when moving folders into other
> folders (often to clean up its parent a little and organise the FS),
> mv(1) does not preserve the time stamps of moved directories.
> 
> If I move the directory into another FS, this information is
> preserved.
> 
> > Besides, neither FreeBSD nor NetBSD have -p, so it would be an
> > egregious example of introducing gratuitious incompatibility.  
> 
> I don't see any gratuitious incompatibility here. The utility behaves
> exactly as before without the -p option, and will therefore be
> compatible with existing scripts.
> 
> It may help to modify the behaviour of rename(2), since there is
> nothing I see in the POSIX standard
> (http://pubs.opengroup.org/onlinepubs/9699919799/functions/rename.html)
> about requiring the change in time stamps. The advantage is consistent
> behaviour across all applications rather than just mv(1).
> 

Re: patch: mv(1): Add -p flag to preserve time stamps for moved directories

[Theo de Raadt]

> Note that I have noatime on this FS.

Maybe we should remove this broken feature.

rc(8): Fix motd update

[Anthony Coulter]

The man page for motd(5) says that all lines up to (but not including)
the first line of /etc/motd are replaced by the kernel version at
startup.

But if the first line is blank the rc script ignores it and instead
deletes everything between the first blank line and the second. This
diff fixes that behavior.


Index: etc/rc
===
RCS file: /cvs/src/etc/rc,v
retrieving revision 1.493
diff -u -p -r1.493 rc
--- etc/rc  26 Feb 2017 16:51:18 -  1.493
+++ etc/rc  11 Apr 2017 20:51:24 -
@@ -505,7 +505,7 @@ fi
 if T=$(mktemp /tmp/_motd.XX); then
sysctl -n kern.version | sed 1q >$T
echo "" >>$T
-   sed '1,/^$/d' >$T
+   sed '0,/^$/d' >$T
cmp -s $T /etc/motd || cp $T /etc/motd
rm -f $T
 fi

Re: patch: mv(1): Add -p flag to preserve time stamps for moved directories

[bytevolcano]

On Tue, 11 Apr 2017 16:54:29 +0200
Ingo Schwarze  wrote:

> Hi,
> 
> bytevolc...@safe-mail.net wrote on Fri, Apr 07, 2017 at 12:25:10PM
> +1000:
> 
> > Although mv(1) will preserve atime and mtime for moved directories
> > if moved to a different file system, it doesn't preserve them when
> > moved in the same file system.  
> 
> Cannot reproduce.
> 
>$ mkdir Foo
>$ touch -t 2101 Foo 
>$ ls -dl Foo
>   drwxr-xr-x  2 schwarze  schwarze  512 Jan  1  2000 Foo
>$ ls -dlu Foo
>   drwxr-xr-x  2 schwarze  schwarze  512 Jan  1  2000 Foo
>$ mv Foo Bar
>$ ls -dl Bar  
>   drwxr-xr-x  2 schwarze  schwarze  512 Jan  1  2000 Bar
>$ ls -dlu Bar
>   drwxr-xr-x  2 schwarze  schwarze  512 Jan  1  2000 Bar

I can:

$ mkdir Foo
$ touch -t 2101 Foo
$ ls -dlT Foo
drwxr-xr-x  2 bob  bob  512 Jan  1 00:00:00 2000 Foo
$ ls -dluT Foo
drwxr-xr-x  2 bob  bob  512 Jan  1 00:00:00 2000 Foo
$ mkdir Bar
$ mv Foo Bar/
$ ls -dlT Bar/Foo
drwxr-xr-x  2 bob  bob  512 Apr 12 07:55:30 2017 Foo/Bar
$ ls -dluT Bar/Foo
drwxr-xr-x  2 bob  bob  512 Jan  1 00:00:00 2000 Foo/Bar

Note that I have noatime on this FS.

> Sounds like a bad idea.  Do not add non-standard options to standard
> utilities unless they are useful to a very unusual degree.  Even if
> there is some corner case that you failed to describe, this seems
> by far not important enough for adding an option.

The problem I am solving here is that, when moving folders into other
folders (often to clean up its parent a little and organise the FS),
mv(1) does not preserve the time stamps of moved directories.

If I move the directory into another FS, this information is preserved.

> Besides, neither FreeBSD nor NetBSD have -p, so it would be an
> egregious example of introducing gratuitious incompatibility.

I don't see any gratuitious incompatibility here. The utility behaves
exactly as before without the -p option, and will therefore be
compatible with existing scripts.

It may help to modify the behaviour of rename(2), since there is
nothing I see in the POSIX standard
(http://pubs.opengroup.org/onlinepubs/9699919799/functions/rename.html)
about requiring the change in time stamps. The advantage is consistent
behaviour across all applications rather than just mv(1).

PATCH: change tiling behaviour in cwm(1)

[Gerrit Meyerheim]

Hi @tech,

The way cwm(1) currently implements tiling (off by default) is
corresponding to this for vtile,

-
|   |   |
|   |   1   |
|   |   |
|   M   -
|   |   |
|   |   2   |
|   |   |
-

 <->
w

where 'w' is the original horizontal size of the master client when
vtile was invoked. The analogous is true for htile and vertical height.

While this approach gives the greatest flexibility (as one can define
the size of the master area for each invocation of vtile) I most often
find myself wanting the following behaviour when using tiling,

-
|   |   |
|   |   1   |
|   |   |
|   M   -
|   |   |
|   |   2   |
|   |   |
-

 <->
w

where 'w' is "0.5 x horizontal widht of the screen" for vtile and the
analogous for htile and height.

The attached patch tries to implement this (replacing the current
approach). Of course, there would also be the possibility of having an
additional function (e.g. client_htile_half etc.).

Thoughts?

Best

Gerrit


Index: client.c
===
RCS file: /cvs/xenocara/app/cwm/client.c,v
retrieving revision 1.234
diff -u -p -r1.234 client.c
--- client.c6 Feb 2017 18:10:28 -   1.234
+++ client.c10 Apr 2017 12:23:48 -
@@ -982,6 +982,7 @@ client_htile(struct client_ctx *cc)
cc->flags &= ~CLIENT_HMAXIMIZED;
cc->geom.x = area.x;
cc->geom.y = area.y;
+   cc->geom.h = (area.h - (cc->bwidth * 2)) / 2;
cc->geom.w = area.w - (cc->bwidth * 2);
client_resize(cc, 1);
client_ptrwarp(cc);
@@ -1042,6 +1043,7 @@ client_vtile(struct client_ctx *cc)
cc->geom.x = area.x;
cc->geom.y = area.y;
cc->geom.h = area.h - (cc->bwidth * 2);
+   cc->geom.w = (area.w - (cc->bwidth * 2)) / 2;
client_resize(cc, 1);
client_ptrwarp(cc);
 
Index: cwmrc.5
===
RCS file: /cvs/xenocara/app/cwm/cwmrc.5,v
retrieving revision 1.66
diff -u -p -r1.66 cwmrc.5
--- cwmrc.5 15 Jan 2017 21:07:44 -  1.66
+++ cwmrc.5 10 Apr 2017 12:23:48 -
@@ -324,11 +324,13 @@ Vertically maximize current window (gap 
 .It window-hmaximize
 Horizontally maximize current window (gap + border honored).
 .It window-htile
-Current window is placed at the top of the screen and maximized
-horizontally, other windows in its group share remaining screen space.
+Current window is placed at the top of the screen, maximized
+horizontally and resized to half of the vertical screen space. Other
+windows in its group share remaining screen space.
 .It window-vtile
-Current window is placed on the left of the screen and maximized
-vertically, other windows in its group share remaining screen space.
+Current window is placed on the left of the screen, maximized vertically
+and resized to half of the horizontal screen space. Other windows in its
+group share remaining screen space.
 .It window-move
 Move current window.
 .It window-resize

Re: Break pluart(4)

[Visa Hankala]

On Tue, Apr 11, 2017 at 04:55:45PM +0200, Mark Kettenis wrote:
> Se here is an updated diff; thanks for catching this.
> 
> ok?

OK visa@

> Index: arch/arm64/dev/pluart.c
> ===
> RCS file: /cvs/src/sys/arch/arm64/dev/pluart.c,v
> retrieving revision 1.2
> diff -u -p -r1.2 pluart.c
> --- arch/arm64/dev/pluart.c   20 Jan 2017 08:03:21 -  1.2
> +++ arch/arm64/dev/pluart.c   11 Apr 2017 14:54:22 -
> @@ -256,6 +256,7 @@ pluartattach(struct device *parent, stru
>   cn_tab->cn_dev = makedev(maj, sc->sc_dev.dv_unit);
>  
>   printf(": console");
> + SET(sc->sc_hwflags, COM_HW_CONSOLE);
>   }
>  
>   timeout_set(>sc_diag_tmo, pluart_diag, sc);
> @@ -304,8 +305,18 @@ pluart_intr(void *arg)
>  
>   p = sc->sc_ibufp;
>  
> - while(ISSET(bus_space_read_4(iot, ioh, UART_FR), UART_FR_RXFF)) {
> - c = bus_space_read_1(iot, ioh, UART_DR);
> + while (ISSET(bus_space_read_4(iot, ioh, UART_FR), UART_FR_RXFF)) {
> + c = bus_space_read_2(iot, ioh, UART_DR);
> + if (c & UART_DR_BE) {
> +#ifdef DDB
> + if (ISSET(sc->sc_hwflags, COM_HW_CONSOLE)) {
> + if (db_console)
> + Debugger();
> + continue;
> + }
> +#endif
> + c = 0;
> + }
>   if (p >= sc->sc_ibufend) {
>   sc->sc_floods++;
>   if (sc->sc_errors++ == 0)
> Index: arch/armv7/dev/pluart.c
> ===
> RCS file: /cvs/src/sys/arch/armv7/dev/pluart.c,v
> retrieving revision 1.1
> diff -u -p -r1.1 pluart.c
> --- arch/armv7/dev/pluart.c   31 Aug 2016 16:19:40 -  1.1
> +++ arch/armv7/dev/pluart.c   11 Apr 2017 14:54:22 -
> @@ -260,6 +260,7 @@ pluartattach(struct device *parent, stru
>   cn_tab->cn_dev = makedev(maj, sc->sc_dev.dv_unit);
>  
>   printf(": console");
> + SET(sc->sc_hwflags, COM_HW_CONSOLE);
>   }
>  
>   timeout_set(>sc_diag_tmo, pluart_diag, sc);
> @@ -308,8 +309,18 @@ pluart_intr(void *arg)
>  
>   p = sc->sc_ibufp;
>  
> - while(ISSET(bus_space_read_4(iot, ioh, UART_FR), UART_FR_RXFF)) {
> - c = bus_space_read_1(iot, ioh, UART_DR);
> + while (ISSET(bus_space_read_4(iot, ioh, UART_FR), UART_FR_RXFF)) {
> + c = bus_space_read_2(iot, ioh, UART_DR);
> + if (c & UART_DR_BE) {
> +#ifdef DDB
> + if (ISSET(sc->sc_hwflags, COM_HW_CONSOLE)) {
> + if (db_console)
> + Debugger();
> + continue;
> + }
> +#endif
> + c = 0;
> + }
>   if (p >= sc->sc_ibufend) {
>   sc->sc_floods++;
>   if (sc->sc_errors++ == 0)
> 

Re: Break pluart(4)

[Mark Kettenis]

> Date: Tue, 11 Apr 2017 16:25:57 +0200 (CEST)
> From: Mark Kettenis 
> 
> > Date: Tue, 11 Apr 2017 14:12:38 +
> > From: Visa Hankala 
> > 
> > On Tue, Apr 11, 2017 at 03:51:51PM +0200, Mark Kettenis wrote:
> > > + if (ISSET(sc->sc_hwflags, COM_HW_CONSOLE)) {
> > > + if (db_console)
> > > + Debugger();
> > > + continue;
> > > + }
> > 
> > Should these be inside #ifdef DDB like in com(4)?
> 
> Yes

Se here is an updated diff; thanks for catching this.

ok?


Index: arch/arm64/dev/pluart.c
===
RCS file: /cvs/src/sys/arch/arm64/dev/pluart.c,v
retrieving revision 1.2
diff -u -p -r1.2 pluart.c
--- arch/arm64/dev/pluart.c 20 Jan 2017 08:03:21 -  1.2
+++ arch/arm64/dev/pluart.c 11 Apr 2017 14:54:22 -
@@ -256,6 +256,7 @@ pluartattach(struct device *parent, stru
cn_tab->cn_dev = makedev(maj, sc->sc_dev.dv_unit);
 
printf(": console");
+   SET(sc->sc_hwflags, COM_HW_CONSOLE);
}
 
timeout_set(>sc_diag_tmo, pluart_diag, sc);
@@ -304,8 +305,18 @@ pluart_intr(void *arg)
 
p = sc->sc_ibufp;
 
-   while(ISSET(bus_space_read_4(iot, ioh, UART_FR), UART_FR_RXFF)) {
-   c = bus_space_read_1(iot, ioh, UART_DR);
+   while (ISSET(bus_space_read_4(iot, ioh, UART_FR), UART_FR_RXFF)) {
+   c = bus_space_read_2(iot, ioh, UART_DR);
+   if (c & UART_DR_BE) {
+#ifdef DDB
+   if (ISSET(sc->sc_hwflags, COM_HW_CONSOLE)) {
+   if (db_console)
+   Debugger();
+   continue;
+   }
+#endif
+   c = 0;
+   }
if (p >= sc->sc_ibufend) {
sc->sc_floods++;
if (sc->sc_errors++ == 0)
Index: arch/armv7/dev/pluart.c
===
RCS file: /cvs/src/sys/arch/armv7/dev/pluart.c,v
retrieving revision 1.1
diff -u -p -r1.1 pluart.c
--- arch/armv7/dev/pluart.c 31 Aug 2016 16:19:40 -  1.1
+++ arch/armv7/dev/pluart.c 11 Apr 2017 14:54:22 -
@@ -260,6 +260,7 @@ pluartattach(struct device *parent, stru
cn_tab->cn_dev = makedev(maj, sc->sc_dev.dv_unit);
 
printf(": console");
+   SET(sc->sc_hwflags, COM_HW_CONSOLE);
}
 
timeout_set(>sc_diag_tmo, pluart_diag, sc);
@@ -308,8 +309,18 @@ pluart_intr(void *arg)
 
p = sc->sc_ibufp;
 
-   while(ISSET(bus_space_read_4(iot, ioh, UART_FR), UART_FR_RXFF)) {
-   c = bus_space_read_1(iot, ioh, UART_DR);
+   while (ISSET(bus_space_read_4(iot, ioh, UART_FR), UART_FR_RXFF)) {
+   c = bus_space_read_2(iot, ioh, UART_DR);
+   if (c & UART_DR_BE) {
+#ifdef DDB
+   if (ISSET(sc->sc_hwflags, COM_HW_CONSOLE)) {
+   if (db_console)
+   Debugger();
+   continue;
+   }
+#endif
+   c = 0;
+   }
if (p >= sc->sc_ibufend) {
sc->sc_floods++;
if (sc->sc_errors++ == 0)

Re: patch: mv(1): Add -p flag to preserve time stamps for moved directories

[Ingo Schwarze]

Hi,

bytevolc...@safe-mail.net wrote on Fri, Apr 07, 2017 at 12:25:10PM +1000:

> Although mv(1) will preserve atime and mtime for moved directories if
> moved to a different file system, it doesn't preserve them when moved
> in the same file system.

Cannot reproduce.

   $ mkdir Foo
   $ touch -t 2101 Foo 
   $ ls -dl Foo
  drwxr-xr-x  2 schwarze  schwarze  512 Jan  1  2000 Foo
   $ ls -dlu Foo
  drwxr-xr-x  2 schwarze  schwarze  512 Jan  1  2000 Foo
   $ mv Foo Bar
   $ ls -dl Bar  
  drwxr-xr-x  2 schwarze  schwarze  512 Jan  1  2000 Bar
   $ ls -dlu Bar
  drwxr-xr-x  2 schwarze  schwarze  512 Jan  1  2000 Bar

> This patch adds a "-p" flag as an extension to allow preserving the
> time stamps, whilst allowing mv(1) to retain POSIX behaviour without
> the flag.

Sounds like a bad idea.  Do not add non-standard options to standard
utilities unless they are useful to a very unusual degree.  Even if
there is some corner case that you failed to describe, this seems
by far not important enough for adding an option.

Besides, neither FreeBSD nor NetBSD have -p, so it would be an
egregious example of introducing gratuitious incompatibility.

Yours,
  Ingo

Re: openssl(1) not error exiting on full file system

[Ingo Schwarze]

Hi Theo,

Theo de Raadt wrote on Tue, Apr 11, 2017 at 08:13:24AM -0600:

> Sure.. or, make some comments about it being highly non-portable.
> It isn't even really a BSD'ism.  The idea is a flop.  I wonder if
> it was an attempt to pull a VMS idea.

Here is a stronger version.
I like that even better than the first one.
It also gets rid of the filler words noticed by Franco.

OK?
  Ingo


Index: sysexits.3
===
RCS file: /cvs/src/share/man/man3/sysexits.3,v
retrieving revision 1.12
diff -u -r1.12 sysexits.3
--- sysexits.3  30 Dec 2015 16:41:52 -  1.12
+++ sysexits.3  11 Apr 2017 14:26:56 -
@@ -37,10 +37,10 @@
 .Sh SYNOPSIS
 .In sysexits.h
 .Sh DESCRIPTION
-Some programs use defined error codes to distinguish between possible errors.
-However, most programs in
-.Ox
-do not.
+A few programs exit with the following obsolete, non-portable error
+codes that were invented for legacy
+.Sy sendmail .
+Do not use them.
 .Pp
 The successful exit is always indicated by a status of 0, or
 .Dv EX_OK .

Re: Break pluart(4)

[Mark Kettenis]

> Date: Tue, 11 Apr 2017 14:12:38 +
> From: Visa Hankala 
> 
> On Tue, Apr 11, 2017 at 03:51:51PM +0200, Mark Kettenis wrote:
> > +   if (ISSET(sc->sc_hwflags, COM_HW_CONSOLE)) {
> > +   if (db_console)
> > +   Debugger();
> > +   continue;
> > +   }
> 
> Should these be inside #ifdef DDB like in com(4)?

Yes

Re: openssl(1) not error exiting on full file system

[Franco Fichtner]

> On 11. Apr 2017, at 4:09 PM, Ingo Schwarze  wrote:
> 
> Index: sysexits.3
> ===
> RCS file: /cvs/src/share/man/man3/sysexits.3,v
> retrieving revision 1.12
> diff -u -r1.12 sysexits.3
> --- sysexits.330 Dec 2015 16:41:52 -  1.12
> +++ sysexits.311 Apr 2017 14:06:19 -
> @@ -40,7 +40,7 @@
> Some programs use defined error codes to distinguish between possible errors.
> However, most programs in
> .Ox
> -do not.
> +do not, and using these codes in additional programs is not recommended.
> .Pp
> The successful exit is always indicated by a status of 0, or
> .Dv EX_OK .

Why not drop trivia from the file instead?  "Some programs", "however",
"most programs", ".Ox", "additional programs".  ;)

Re: openssl(1) not error exiting on full file system

[Theo de Raadt]

Sure.. or, make some comments about it being highly non-portable.

It isn't even really a BSD'ism.  The idea is a flop.  I wonder if
it was an attempt to pull a VMS idea.

> I'd like to make that plainer.  It isn't the first time people
> waste time reading sysexits(3) and arguing about it.
> 
> OK?
>   Ingo
> 
> 
> Index: sysexits.3
> ===
> RCS file: /cvs/src/share/man/man3/sysexits.3,v
> retrieving revision 1.12
> diff -u -r1.12 sysexits.3
> --- sysexits.330 Dec 2015 16:41:52 -  1.12
> +++ sysexits.311 Apr 2017 14:06:19 -
> @@ -40,7 +40,7 @@
>  Some programs use defined error codes to distinguish between possible errors.
>  However, most programs in
>  .Ox
> -do not.
> +do not, and using these codes in additional programs is not recommended.
>  .Pp
>  The successful exit is always indicated by a status of 0, or
>  .Dv EX_OK .

1

Re: Break pluart(4)

[Visa Hankala]

On Tue, Apr 11, 2017 at 03:51:51PM +0200, Mark Kettenis wrote:
> + if (ISSET(sc->sc_hwflags, COM_HW_CONSOLE)) {
> + if (db_console)
> + Debugger();
> + continue;
> + }

Should these be inside #ifdef DDB like in com(4)?

Re: openssl(1) not error exiting on full file system

[Ingo Schwarze]

Hi,

Theo de Raadt wrote on Tue, Apr 11, 2017 at 07:08:30AM -0600:

> sysexits.h is a thing that came from sendmail, and only a few things
> use it.  Further use isn't encouraged.

I'd like to make that plainer.  It isn't the first time people
waste time reading sysexits(3) and arguing about it.

OK?
  Ingo


Index: sysexits.3
===
RCS file: /cvs/src/share/man/man3/sysexits.3,v
retrieving revision 1.12
diff -u -r1.12 sysexits.3
--- sysexits.3  30 Dec 2015 16:41:52 -  1.12
+++ sysexits.3  11 Apr 2017 14:06:19 -
@@ -40,7 +40,7 @@
 Some programs use defined error codes to distinguish between possible errors.
 However, most programs in
 .Ox
-do not.
+do not, and using these codes in additional programs is not recommended.
 .Pp
 The successful exit is always indicated by a status of 0, or
 .Dv EX_OK .

Break pluart(4)

[Mark Kettenis]

Diff below adds code to recognize a break and invoke ddb on pluart(4).

ok?


Index: arch/arm64/dev/pluart.c
===
RCS file: /cvs/src/sys/arch/arm64/dev/pluart.c,v
retrieving revision 1.2
diff -u -p -r1.2 pluart.c
--- arch/arm64/dev/pluart.c 20 Jan 2017 08:03:21 -  1.2
+++ arch/arm64/dev/pluart.c 11 Apr 2017 13:50:17 -
@@ -256,6 +256,7 @@ pluartattach(struct device *parent, stru
cn_tab->cn_dev = makedev(maj, sc->sc_dev.dv_unit);
 
printf(": console");
+   SET(sc->sc_hwflags, COM_HW_CONSOLE);
}
 
timeout_set(>sc_diag_tmo, pluart_diag, sc);
@@ -304,8 +305,15 @@ pluart_intr(void *arg)
 
p = sc->sc_ibufp;
 
-   while(ISSET(bus_space_read_4(iot, ioh, UART_FR), UART_FR_RXFF)) {
-   c = bus_space_read_1(iot, ioh, UART_DR);
+   while (ISSET(bus_space_read_4(iot, ioh, UART_FR), UART_FR_RXFF)) {
+   c = bus_space_read_2(iot, ioh, UART_DR);
+   if (c & UART_DR_BE) {
+   if (ISSET(sc->sc_hwflags, COM_HW_CONSOLE)) {
+   if (db_console)
+   Debugger();
+   continue;
+   }
+   }
if (p >= sc->sc_ibufend) {
sc->sc_floods++;
if (sc->sc_errors++ == 0)
Index: arch/armv7/dev/pluart.c
===
RCS file: /cvs/src/sys/arch/armv7/dev/pluart.c,v
retrieving revision 1.1
diff -u -p -r1.1 pluart.c
--- arch/armv7/dev/pluart.c 31 Aug 2016 16:19:40 -  1.1
+++ arch/armv7/dev/pluart.c 11 Apr 2017 13:50:17 -
@@ -260,6 +260,7 @@ pluartattach(struct device *parent, stru
cn_tab->cn_dev = makedev(maj, sc->sc_dev.dv_unit);
 
printf(": console");
+   SET(sc->sc_hwflags, COM_HW_CONSOLE);
}
 
timeout_set(>sc_diag_tmo, pluart_diag, sc);
@@ -308,8 +309,15 @@ pluart_intr(void *arg)
 
p = sc->sc_ibufp;
 
-   while(ISSET(bus_space_read_4(iot, ioh, UART_FR), UART_FR_RXFF)) {
-   c = bus_space_read_1(iot, ioh, UART_DR);
+   while (ISSET(bus_space_read_4(iot, ioh, UART_FR), UART_FR_RXFF)) {
+   c = bus_space_read_2(iot, ioh, UART_DR);
+   if (c & UART_DR_BE) {
+   if (ISSET(sc->sc_hwflags, COM_HW_CONSOLE)) {
+   if (db_console)
+   Debugger();
+   continue;
+   }
+   }
if (p >= sc->sc_ibufend) {
sc->sc_floods++;
if (sc->sc_errors++ == 0)

OpenBSD 6.1 released - Apr 11, 2017

[Theo de Raadt]

- OpenBSD 6.1 RELEASED -

April 11, 2017.

We are pleased to announce the official release of OpenBSD 6.1.
This is our 42nd release.  We remain proud of OpenBSD's record of more
than twenty years with only two remote holes in the default install.

As in our previous releases, 6.1 provides significant improvements,
including new features, in nearly all areas of the system:

 - New/extended platforms:
o New arm64 platform, using clang(1) as the base system compiler.
o The loongson platform now supports systems with Loongson 3A CPU
  and RS780E chipset.
o The following platforms were retired: armish, sparc, zaurus.

 - Improved hardware support, including:
o New acpials(4) driver for ACPI ambient light sensor devices.
o New acpihve(4) driver for feeding Hyper-V entropy into the kernel
  pool.
o New acpisbs(4) driver for ACPI Smart Battery devices.
o New dwge(4) driver for Designware GMAC 10/100/Gigabit Ethernet
  devices.
o New htb(4) driver for Loongson 3A PCI host bridges.
o New hvn(4) driver for Hyper-V networking interfaces.
o New hyperv(4) driver for the Hyper-V guest nexus device.
o New iatp(4) driver for the Atmel maXTouch touchpad and
  touchscreen.
o New imxtemp(4) driver for Freescale i.MX6 temperature sensors.
o New leioc(4) driver for the Loongson 3A low-end IO controller.
o New octmmc(4) driver for the OCTEON MMC host controller.
o New ompinmux(4) driver for OMAP pin multiplexing.
o New omwugen(4) driver for OMAP wake-up generators.
o New psci(4) driver for the ARM Power State Coordination Interface.
o New simplefb(4) driver for the simple frame buffer on systems
  using a device tree.
o New sximmc(4) driver for Allwinner A1X/A20 MMC/SD/SDIO
  controllers.
o New tpm(4) driver for Trusted Platform Module devices.
o New uwacom(4) driver for Wacom USB tablets.
o New vmmci(4) VMM control interface.
o New xbf(4) driver for Xen Blkfront virtual disks.
o New xp(4) driver for the LUNA-88K HD647180X I/O processor.
o Support for Kaby Lake and Lewisburg PCH Ethernet MACs with I219
  PHYs has been added to the em(4) driver.
o Support for RTL8153 USB 3.0 Gigabit Ethernet based devices has
  been added to the ure(4) driver.
o Improved ACPI support for modern Apple hardware, including S3
  suspend and resume.
o Support for X550 family of 10 Gigabit Ethernet based devices has
  been added to the ix(4) driver.

 - New vmm(4)/ vmd(8):
o Support was partially integrated in 6.0, but disabled.
o Support for amd64 and i386 hosts.
o BIOS payload provided via vmm-firmware, delivered via
  fw_update(1).
o Support for Linux guest VMs.
o Better interrupt handling and legacy device emulation.
o vmm(4) no longer requires VMX unrestricted guest capability
  (Nehalem and later CPUs are sufficient).
o Removed bounce buffers previously used by vmd(8) for vio(4) and
  vioblk(4) devices.
o Support VMs with > 2GB RAM.
o vmd(8) uses pledge(2) and the fork+exec model.
o vm.conf(5) expanded to include VM ownership rules (uid/gid).
o vmd(8)/ vm.conf(5) supports automatic bridge(4) and switch(4)
  configuration for VM network interfaces.
o vmctl(8) supports graceful VM shutdown via vmmci(4).

 - IEEE 802.11 wireless stack improvements:
o The ral(4) driver now supports Ralink RT3900E (RT5390, RT3292)
  devices.
o The iwm(4) and iwn(4) drivers now support the short guard interval
  (SGI) in 11n mode.
o Added a new implementation of MiRa, a rate adapation algorithm
  designed for 802.11n.
o The iwm(4) driver now supports 802.11n MIMO (MCS 0-15).
o The athn(4) driver now supports 802.11n, featuring MIMO (MCS 0-15)
  and hostap mode.
o The iwn(4) driver now receives MIMO frames in monitor mode.
o The rtwn(4) and urtwn(4) drivers now use AMRR rate adaptation
  (8188EU and 8188CE devices only).
o TKIP/WPA1 was disabled by default because of inherent weaknesses
  in this protocol.

 - Generic network stack improvements:
o New switch(4) pseudo-device together with new switchd(8) and
  switchctl(8) programs.
o New mobileip(4) operation mode for the gre(4) pseudo-device.
o Multipoint-to-multipoint mode in vxlan(4).
o route(8) and netstat -r display all routing flags correctly and
  they are completely documented in the netstat(1) man page.
o When sending TCP streams they are locally stored in large mbuf
  clusters to improve memory management. The maximum TCP send and
  receive buffer size has been increased from 256KB to 2MB. Note
  that this results in a different pf(4) OS fingerprint for OpenBSD.
  The default limit for mbuf clusters has been increased. You can
  check the values with netstat(1) -m and adjust 

Re: /usr/lib/clang build:wheel 770

[Theo de Raadt]

Sure.

> > $ tar tvzf comp61.tgz |grep ^d.*lib.clang
> > drwxrwx---  2 buildwheel0 Apr 10 13:01 ./usr/lib/clang
> > drwxrwx---  2 buildwheel0 Apr 10 13:01 ./usr/lib/clang/4.0.0
> > drwxr-xr-x  2 root bin  0 Apr 10 13:01 
> > ./usr/lib/clang/4.0.0/include
> > 
> > Is this the way to fix it, or do we need something different as it's only
> > on some arch?
> 
> The equivalent for gcc /usr/lib/gcc-lib/amd64-unknown-openbsd6.1/4.2.1/
> isn't in mtree.  Here is a way to handle it like the gcc4 build
> 
> Index: Makefile
> ===
> RCS file: /cvs/src/gnu/usr.bin/clang/include/clang/intrin/Makefile,v
> retrieving revision 1.7
> diff -u -p -r1.7 Makefile
> --- Makefile  10 Apr 2017 13:36:04 -  1.7
> +++ Makefile  11 Apr 2017 10:56:59 -
> @@ -86,8 +86,10 @@ clean cleandir:
>   rm -f ${GEN}
>  
>  install includes: ${HEADERS}
> - ${INSTALL} -d -o ${SHAREOWN} -g ${SHAREGRP} -m ${DIRMODE} \
> - ${DESTDIR}${CLANG_INTR_INCDIR}
> +.for dir in /usr/lib/clang /usr/lib/clang/${LLVM_V} ${CLANG_INTR_INCDIR}
> + ${INSTALL} -d -o ${BINOWN} -g ${BINGRP} -m ${DIRMODE} \
> + ${DESTDIR}${dir}
> +.endfor
>   ${INSTALL} ${INSTALL_COPY} -m 444 ${.ALLSRC} \
>   ${DESTDIR}${CLANG_INTR_INCDIR}
>  
> 

Re: openssl(1) not error exiting on full file system

[Theo de Raadt]

> On 2017-04-10 Mon 14:31 PM |, Craig Skinner wrote:
> > On Mon, 10 Apr 2017 12:46:03 +0100 Craig Skinner wrote:
> > > $ openssl enc -bf -salt \
> > >   -pass file:/etc/myname -in /bsd \
> > >   -out /altroot/tmp/bsd.crypto
> > > 
> > > /altroot: write failed, file system is full
> > > $ print $?
> > > 0
> > 
> 
> openssl error exits for other output file creation problems:
> 
> $ openssl bf -pass file:/etc/myname -in /bsd -out 
> /var/empty/bsd.crypto
> /var/empty/bsd.crypto: Permission denied
> 2133286928:error:0200100D:system library:fopen:Permission 
> denied:/usr/src/lib/libcrypto/crypto/../../libssl/src/crypto/bio/bss_file.c:255:fopen('/var/empty/bsd.crypto',
>  'w')
> 2133286928:error:20074002:BIO routines:FILE_CTRL:system 
> lib:/usr/src/lib/libcrypto/crypto/../../libssl/src/crypto/bio/bss_file.c:257:
> $ print $?
> 1
> $ openssl bf -pass file:/etc/myname -in /bsd -out 
> /no/where/bsd.crypto
> /no/where/bsd.crypto: No such file or directory
> 2216844688:error:02001002:system library:fopen:No such file or 
> directory:/usr/src/lib/libcrypto/crypto/../../libssl/src/crypto/bio/bss_file.c:255:fopen('/no/where/bsd.crypto',
>  'w')
> 2216844688:error:20074002:BIO routines:FILE_CTRL:system 
> lib:/usr/src/lib/libcrypto/crypto/../../libssl/src/crypto/bio/bss_file.c:257:
> $ print $?
> 1
> 
> > 
> > Would 74 from sysexits.h be the code to return?:
> > EX_IOERR -- An error occurred while doing I/O on some file.
> > 
> 
> Perhaps this is more relevant:
> 
> EX_CANTCREAT -- A (user specified) output file cannot be created.

sysexits.h is a thing that came from sendmail, and only a few things
use it.  Further use isn't encouraged.

Most tools exit upon error without providing a refined error code.

Re: /usr/lib/clang build:wheel 770

[Theo Buehler]

On Tue, Apr 11, 2017 at 11:03:33AM +0100, Stuart Henderson wrote:
> > > > On Mon, Apr 10, 2017 at 01:35:57PM +0200, Mark Kettenis wrote:
> > > > > Looking into arm_neon.h.  This header file is supposed to be generated
> > > > > using the clang_tablegen tool, which is why we missed it.
> 
> $ tar tvzf comp61.tgz |grep ^d.*lib.clang
> drwxrwx---  2 buildwheel0 Apr 10 13:01 ./usr/lib/clang
> drwxrwx---  2 buildwheel0 Apr 10 13:01 ./usr/lib/clang/4.0.0
> drwxr-xr-x  2 root bin  0 Apr 10 13:01 
> ./usr/lib/clang/4.0.0/include
> 
> Is this the way to fix it, or do we need something different as it's only
> on some arch?

Isn't this the usual annoyance that install -d creates intermediate
directories without explicitly setting owner and permissions?

In gnu/usr.bin/cc/cc/Makefile natano worked around this problem by
incrementally creating the path with an ugly .for loop like this:

(untested)

Index: gnu/usr.bin/clang/include/clang/intrin/Makefile
===
RCS file: /var/cvs/src/gnu/usr.bin/clang/include/clang/intrin/Makefile,v
retrieving revision 1.7
diff -u -p -r1.7 Makefile
--- gnu/usr.bin/clang/include/clang/intrin/Makefile 10 Apr 2017 13:36:04 
-  1.7
+++ gnu/usr.bin/clang/include/clang/intrin/Makefile 11 Apr 2017 10:32:42 
-
@@ -86,8 +86,10 @@ clean cleandir:
rm -f ${GEN}
 
 install includes: ${HEADERS}
+.for dir in /usr/lib/clang /usr/lib/clang/${LLVM_V} 
/usr/lib/clang/${LLVM_V}/include
${INSTALL} -d -o ${SHAREOWN} -g ${SHAREGRP} -m ${DIRMODE} \
-   ${DESTDIR}${CLANG_INTR_INCDIR}
+   ${DESTDIR}${dir}
+.endfor
${INSTALL} ${INSTALL_COPY} -m 444 ${.ALLSRC} \
${DESTDIR}${CLANG_INTR_INCDIR}
 

Re: openssl(1) not error exiting on full file system

[Craig Skinner]

Hi again,

On 2017-04-10 Mon 14:31 PM |, Craig Skinner wrote:
> On Mon, 10 Apr 2017 12:46:03 +0100 Craig Skinner wrote:
> > $ openssl enc -bf -salt \
> > -pass file:/etc/myname -in /bsd \
> > -out /altroot/tmp/bsd.crypto
> > 
> > /altroot: write failed, file system is full
> > $ print $?
> > 0
> 

openssl error exits for other output file creation problems:

$ openssl bf -pass file:/etc/myname -in /bsd -out 
/var/empty/bsd.crypto
/var/empty/bsd.crypto: Permission denied
2133286928:error:0200100D:system library:fopen:Permission 
denied:/usr/src/lib/libcrypto/crypto/../../libssl/src/crypto/bio/bss_file.c:255:fopen('/var/empty/bsd.crypto',
 'w')
2133286928:error:20074002:BIO routines:FILE_CTRL:system 
lib:/usr/src/lib/libcrypto/crypto/../../libssl/src/crypto/bio/bss_file.c:257:
$ print $?
1
$ openssl bf -pass file:/etc/myname -in /bsd -out 
/no/where/bsd.crypto
/no/where/bsd.crypto: No such file or directory
2216844688:error:02001002:system library:fopen:No such file or 
directory:/usr/src/lib/libcrypto/crypto/../../libssl/src/crypto/bio/bss_file.c:255:fopen('/no/where/bsd.crypto',
 'w')
2216844688:error:20074002:BIO routines:FILE_CTRL:system 
lib:/usr/src/lib/libcrypto/crypto/../../libssl/src/crypto/bio/bss_file.c:257:
$ print $?
1

> 
> Would 74 from sysexits.h be the code to return?:
> EX_IOERR -- An error occurred while doing I/O on some file.
> 

Perhaps this is more relevant:

EX_CANTCREAT -- A (user specified) output file cannot be created.

Cheers,
-- 
Craig Skinner | http://linkd.in/yGqkv7

Re: relayd(8): convert explicit_bzero() + free() to freezero()

[Reyk Floeter]

On Tue, Apr 11, 2017 at 12:12:20PM +0200, Frederic Cambus wrote:
> On Mon, Apr 10, 2017 at 05:43:33PM +0200, Claudio Jeker wrote:
> 
> > > --- usr.sbin/relayd/relayd.c  24 Jan 2017 10:49:14 -  1.165
> > > +++ usr.sbin/relayd/relayd.c  10 Apr 2017 15:06:38 -
> > > @@ -550,8 +550,7 @@ purge_key(char **ptr, off_t len)
> > >   if (key == NULL || len == 0)
> > >   return;
> > 
> > I think this can also be dropped because freezero(NULL, 0) is save.
> 
> Indeed, saw the thread regarding imsg, that makes sense.
> 
> Revised diff below.
> 
> OK?
> 

OK

> Index: usr.sbin/relayd/relayd.c
> ===
> RCS file: /cvs/src/usr.sbin/relayd/relayd.c,v
> retrieving revision 1.165
> diff -u -p -r1.165 relayd.c
> --- usr.sbin/relayd/relayd.c  24 Jan 2017 10:49:14 -  1.165
> +++ usr.sbin/relayd/relayd.c  11 Apr 2017 06:57:26 -
> @@ -547,11 +547,7 @@ purge_key(char **ptr, off_t len)
>  {
>   char*key = *ptr;
>  
> - if (key == NULL || len == 0)
> - return;
> -
> - explicit_bzero(key, len);
> - free(key);
> + freezero(key, len);
>  
>   *ptr = NULL;
>  }
> 

-- 

Re: relayd(8): convert explicit_bzero() + free() to freezero()

[Frederic Cambus]

On Mon, Apr 10, 2017 at 05:43:33PM +0200, Claudio Jeker wrote:

> > --- usr.sbin/relayd/relayd.c24 Jan 2017 10:49:14 -  1.165
> > +++ usr.sbin/relayd/relayd.c10 Apr 2017 15:06:38 -
> > @@ -550,8 +550,7 @@ purge_key(char **ptr, off_t len)
> > if (key == NULL || len == 0)
> > return;
> 
> I think this can also be dropped because freezero(NULL, 0) is save.

Indeed, saw the thread regarding imsg, that makes sense.

Revised diff below.

OK?

Index: usr.sbin/relayd/relayd.c
===
RCS file: /cvs/src/usr.sbin/relayd/relayd.c,v
retrieving revision 1.165
diff -u -p -r1.165 relayd.c
--- usr.sbin/relayd/relayd.c24 Jan 2017 10:49:14 -  1.165
+++ usr.sbin/relayd/relayd.c11 Apr 2017 06:57:26 -
@@ -547,11 +547,7 @@ purge_key(char **ptr, off_t len)
 {
char*key = *ptr;
 
-   if (key == NULL || len == 0)
-   return;
-
-   explicit_bzero(key, len);
-   free(key);
+   freezero(key, len);
 
*ptr = NULL;
 }

/usr/lib/clang build:wheel 770

[Stuart Henderson]

> > > On Mon, Apr 10, 2017 at 01:35:57PM +0200, Mark Kettenis wrote:
> > > > Looking into arm_neon.h.  This header file is supposed to be generated
> > > > using the clang_tablegen tool, which is why we missed it.

$ tar tvzf comp61.tgz |grep ^d.*lib.clang
drwxrwx---  2 buildwheel0 Apr 10 13:01 ./usr/lib/clang
drwxrwx---  2 buildwheel0 Apr 10 13:01 ./usr/lib/clang/4.0.0
drwxr-xr-x  2 root bin  0 Apr 10 13:01 
./usr/lib/clang/4.0.0/include

Is this the way to fix it, or do we need something different as it's only
on some arch?

Index: etc/mtree/4.4BSD.dist
===
RCS file: /cvs/src/etc/mtree/4.4BSD.dist,v
retrieving revision 1.294
diff -u -p -r1.294 4.4BSD.dist
--- etc/mtree/4.4BSD.dist   12 Feb 2017 08:56:17 -  1.294
+++ etc/mtree/4.4BSD.dist   11 Apr 2017 09:59:46 -
@@ -157,6 +157,10 @@ usr
 
 # ./usr/lib
 lib
+clang  gname=bin uname=root mode=0755
+4.0.0  gname=bin uname=root mode=0755
+..
+..
 debug  gname=bin uname=root mode=0755
 ..
 locate gname=bin uname=root mode=0755

Re: arm64 fpu fixes

[Mark Kettenis]

> Date: Mon, 10 Apr 2017 18:10:28 -0700
> From: Philip Guenther 
> 
> On Mon, 10 Apr 2017, Mark Kettenis wrote:
> > Diff below revises the struct fpreg definition and enables the dumping 
> > of fpu registers in core dumps.  That pointed out that we need to reset 
> > the FPU state upon exec.
> > 
> > ok?
> 
> ok guenther@
> 
> Hmm, the consequences of __uint128_t are non-trivial.  Are {,u}intmax_t 
> 128bit types on arm64?

No, they're still 64-bit:

$ clang -dM -E - < /dev/null | grep __INTMAX_TYPE
#define __INTMAX_TYPE__ long long int

Note that clang provides 128-bit integer types on more (all?)
platforms.  The situation on amd64 is exactly the same.  Newer
versions of gcc also provide a 128-bit integer type.  Perhaps the C
standard will catch up at some point.  On the other hand, changing the
intmax_t type will be an ABI break so you can count on the Linux folks
bending backwards to avoid changing it.

We should probably just go with the flow.  The 128-bit types are only
used in specific non-standard contexts right now, so there is no
immediate problem.