Re: [patch(es)] fix a few typos in /src
On Thu, Dec 22, 2022 at 10:49:06PM -0500, Paul Tagliamonte wrote: > > Updated patch attached with your feedback, thank you Crystal > hi. i'm rejecting these parts of this diff: Index: lib/libcurses/term.5 Index: lib/libcurses/tinfo/comp_hash.c Index: lib/libcurses/tty/hashmap.c Index: lib/libedit/el.h Index: lib/libedit/filecomplete.c Index: lib/libedit/readline.c Index: lib/libedit/refresh.c Index: lib/libedit/search.c Index: lib/libevent/buffer.c Index: lib/libevent/event.c Index: lib/libevent/kqueue.c Index: lib/libexpat/Changes Index: lib/libform/fld_info.c Index: lib/libform/fld_user.c Index: lib/libform/frm_post.c Index: lib/libform/frm_user.c for changes to curses/form i suggest you check out the latest curses changes and mail them any relevant fixes. for changes to libedit/libevent/libexpat i am not convinced that i should just commit to these willy nilly. if any devs in the relevant areas want to contact me to go ahead, fine. jmc
Re: [patch(es)] fix a few typos in /src
On Thu, Dec 22, 2022 at 10:49:06PM -0500, Paul Tagliamonte wrote: hi. i've committed the parts of this diff relating to libssl. jmc > Index: lib/libssl/d1_both.c > === > Index: lib/libssl/ssl.h > === > Index: lib/libssl/ssl_clnt.c > === > Index: lib/libssl/ssl_local.h > === > Index: lib/libssl/ssl_srvr.c > === > Index: lib/libssl/doc/openssl.cnf > === > Index: lib/libssl/doc/standards.txt > === > Index: lib/libssl/test/CAss.cnf > === > Index: lib/libssl/test/CAtsa.cnf > === > Index: lib/libssl/test/pkits-test.pl > ===
Re: [patch(es)] fix a few typos in /src
On Thu, Dec 22, 2022 at 10:49:06PM -0500, Paul Tagliamonte wrote: > > Updated patch attached with your feedback, thank you Crystal > hi. i know by now you have the message that diffs need to be manageable ;) i'll try and work through your changes as best i can. so this is a heads up that i committed all parts of this diff from lib/libcrypto. the libcrypto/libssl parts are a large subset, so i think changes to these can be kept separate. within the libcrypto parts, i did not take your arithmetics->arithmetic changes. they did not seem to me to be clearly correct/preferrable. i'll get to the rest as time permits. jmc
Re: Machine after unhibernate *sometimes* won't suspend/hibernate again or dim screen
On Mon, Dec 26, 2022 at 12:08 AM Mike Larkin wrote: > On Sun, Dec 25, 2022 at 11:39:29PM -0600, Abel Abraham Camarillo Ojeda > wrote: > > On Sun, Dec 25, 2022 at 9:46 PM Mike Larkin wrote: > > > > > On Fri, Dec 23, 2022 at 03:13:53PM -0600, Abel Abraham Camarillo Ojeda > > > wrote: > > > > On Fri, Dec 23, 2022 at 2:46 PM Abel Abraham Camarillo Ojeda < > > > > acam...@verlet.org> wrote: > > > > > > > > > Forgot to mention I don't think this is a regression, just started > to > > > use > > > > > hibernate/unhibernate more often lately. > > > > > But I think I can reproduce this at least since 6.8 (the first > that I > > > > > installed to this machine) > > > > > > > > > >> > > > > >> > > > > >> But still this apply https://www.openbsd.org/report.html (point > 2) > > > > >> > > > > > > > > > > By doesn't work I mean: > > > > > > > > > > $ zzz > > > > > Suspending system... > > > > > $ (nothing happened) > > > > > > > > > > > real mem = 17021566976 (16233MB) > > > > >> > avail mem = 16488275968 (15724MB) > > > > >> > random: good seed from bootblocks > > > > >> > mpath0 at root > > > > >> > scsibus0 at mpath0: 256 targets > > > > >> > mainbus0 at root > > > > >> > bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xb9908000 (58 entries) > > > > >> > bios0: vendor LENOVO version "R0GET56W (1.56 )" date 08/31/2017 > > > > >> > > > > >> You should try > > > > >> > > > > https://pcsupport.lenovo.com/us/en/products/laptops-and-netbooks/thinkpad-l-series-laptops/thinkpad-l470/downloads/ds120327 > > > > >> and see if problem is still present (of course good to have backup > > > :-)) > > > > >> > > > > > > > > > > yes, forgot about that. Will update bios and retry > > > > > > > > > > > > > machine now with bios updated, can reproduce issue after 1 > unhibernate, > > > > dmesg right now at "zzz does nothing stage": > > > > > > > > > > 1. acpi thread might be stuck as kettenis points out. to verify this, > > > try a suspend (lowercase zzz) instead of a hibernate (capital ZZZ) when > > > it gets stuck. If you can zzz but not ZZZ, then it's not the acpi > > > thread. > > > > > > Both zzz and ZZZ wont work, they only say 'Suspending/Hibernating...' > and > > nothing happens (don't have the exact message right now) > > > > any way to confirm the acpi thread is stuck? > > > > 2. more likely, IMO, is not being able to find a consecutive region in > > > free memory to store the hibernate data structures. If memory gets > > > fragmented, ZZZ will fail. It should print something to dmesg though, > > > so check that. This matches your symptoms of "always works the first > > > time but sometimes not on subsequent tries". > > > > > > > notice also screen dimming via F5/F6 won't work (pressing F5 or F6 and > > nothing happens) > > probably something like kettenis suggested then. make sure the bios is > updated. > Bios is at last version bios0: vendor LENOVO version "R0GET79W (1.79 )" date 07/28/2022 (issue was present also with the previous 2019-ish one) Any idea what else to try to gather more info? This is pretty reproducible
Re: Machine after unhibernate *sometimes* won't suspend/hibernate again or dim screen
On Sun, Dec 25, 2022 at 11:39:29PM -0600, Abel Abraham Camarillo Ojeda wrote: > On Sun, Dec 25, 2022 at 9:46 PM Mike Larkin wrote: > > > On Fri, Dec 23, 2022 at 03:13:53PM -0600, Abel Abraham Camarillo Ojeda > > wrote: > > > On Fri, Dec 23, 2022 at 2:46 PM Abel Abraham Camarillo Ojeda < > > > acam...@verlet.org> wrote: > > > > > > > Forgot to mention I don't think this is a regression, just started to > > use > > > > hibernate/unhibernate more often lately. > > > > But I think I can reproduce this at least since 6.8 (the first that I > > > > installed to this machine) > > > > > > > >> > > > >> > > > >> But still this apply https://www.openbsd.org/report.html (point 2) > > > >> > > > > > > > > By doesn't work I mean: > > > > > > > > $ zzz > > > > Suspending system... > > > > $ (nothing happened) > > > > > > > > > real mem = 17021566976 (16233MB) > > > >> > avail mem = 16488275968 (15724MB) > > > >> > random: good seed from bootblocks > > > >> > mpath0 at root > > > >> > scsibus0 at mpath0: 256 targets > > > >> > mainbus0 at root > > > >> > bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xb9908000 (58 entries) > > > >> > bios0: vendor LENOVO version "R0GET56W (1.56 )" date 08/31/2017 > > > >> > > > >> You should try > > > >> > > https://pcsupport.lenovo.com/us/en/products/laptops-and-netbooks/thinkpad-l-series-laptops/thinkpad-l470/downloads/ds120327 > > > >> and see if problem is still present (of course good to have backup > > :-)) > > > >> > > > > > > > > yes, forgot about that. Will update bios and retry > > > > > > > > > > machine now with bios updated, can reproduce issue after 1 unhibernate, > > > dmesg right now at "zzz does nothing stage": > > > > > > > 1. acpi thread might be stuck as kettenis points out. to verify this, > > try a suspend (lowercase zzz) instead of a hibernate (capital ZZZ) when > > it gets stuck. If you can zzz but not ZZZ, then it's not the acpi > > thread. > > > > Both zzz and ZZZ wont work, they only say 'Suspending/Hibernating...' and > nothing happens (don't have the exact message right now) > > any way to confirm the acpi thread is stuck? > > 2. more likely, IMO, is not being able to find a consecutive region in > > free memory to store the hibernate data structures. If memory gets > > fragmented, ZZZ will fail. It should print something to dmesg though, > > so check that. This matches your symptoms of "always works the first > > time but sometimes not on subsequent tries". > > > > notice also screen dimming via F5/F6 won't work (pressing F5 or F6 and > nothing happens) probably something like kettenis suggested then. make sure the bios is updated.
Re: Machine after unhibernate *sometimes* won't suspend/hibernate again or dim screen
# apmd -d battery status: high. external power status: not connected. estimated battery life 97% (223 minutes life time estimate) can't disable driver messages, error: Inappropriate ioctl for device apmevent index 0 (press zzz in another xterm) system suspending battery status: high. external power status: not connected. estimated battery life 97% (223 minutes life time estimate) do_etc_file(): cannot access file /etc/apm/suspend (press ZZZ in another xterm) system hibernating battery status: high. external power status: not connected. estimated battery life 97% (223 minutes life time estimate) do_etc_file(): cannot access file /etc/apm/hibernate = Notice also that battery life gets stuck and never updates again (not even notices when I plug/unplug from charger) >
Re: Machine after unhibernate *sometimes* won't suspend/hibernate again or dim screen
On Sun, Dec 25, 2022 at 9:46 PM Mike Larkin wrote: > On Fri, Dec 23, 2022 at 03:13:53PM -0600, Abel Abraham Camarillo Ojeda > wrote: > > On Fri, Dec 23, 2022 at 2:46 PM Abel Abraham Camarillo Ojeda < > > acam...@verlet.org> wrote: > > > > > Forgot to mention I don't think this is a regression, just started to > use > > > hibernate/unhibernate more often lately. > > > But I think I can reproduce this at least since 6.8 (the first that I > > > installed to this machine) > > > > > >> > > >> > > >> But still this apply https://www.openbsd.org/report.html (point 2) > > >> > > > > > > By doesn't work I mean: > > > > > > $ zzz > > > Suspending system... > > > $ (nothing happened) > > > > > > > real mem = 17021566976 (16233MB) > > >> > avail mem = 16488275968 (15724MB) > > >> > random: good seed from bootblocks > > >> > mpath0 at root > > >> > scsibus0 at mpath0: 256 targets > > >> > mainbus0 at root > > >> > bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xb9908000 (58 entries) > > >> > bios0: vendor LENOVO version "R0GET56W (1.56 )" date 08/31/2017 > > >> > > >> You should try > > >> > https://pcsupport.lenovo.com/us/en/products/laptops-and-netbooks/thinkpad-l-series-laptops/thinkpad-l470/downloads/ds120327 > > >> and see if problem is still present (of course good to have backup > :-)) > > >> > > > > > > yes, forgot about that. Will update bios and retry > > > > > > > machine now with bios updated, can reproduce issue after 1 unhibernate, > > dmesg right now at "zzz does nothing stage": > > > > 1. acpi thread might be stuck as kettenis points out. to verify this, > try a suspend (lowercase zzz) instead of a hibernate (capital ZZZ) when > it gets stuck. If you can zzz but not ZZZ, then it's not the acpi > thread. > > Both zzz and ZZZ wont work, they only say 'Suspending/Hibernating...' and nothing happens (don't have the exact message right now) any way to confirm the acpi thread is stuck? 2. more likely, IMO, is not being able to find a consecutive region in > free memory to store the hibernate data structures. If memory gets > fragmented, ZZZ will fail. It should print something to dmesg though, > so check that. This matches your symptoms of "always works the first > time but sometimes not on subsequent tries". > notice also screen dimming via F5/F6 won't work (pressing F5 or F6 and nothing happens)
Re: hostctl: Change from fixed length to variable length
I was rewrited the patch for hostctl command and sys/dev/pvbus.
From: "Theo de Raadt"
Date: Tue, 11 Oct 2022 19:09:42 -0600
> An example of this mechanism is SIOCGIFCONF. The ioctl passes a pointer
> to a struct containing length & pointer to data. See net/if.c ifconf()
> There are other similar schemes, but they all come down to asking the
> kernel for the size and then doing a 2nd ioctl.
>
> Or a 3rd or more calls, in case the value has changed in the meantime and
> grown even further, but userland can realloc() the storage until it wins.
>
My new patch is not returned value length from ioctl() system call
when read the KEY's value.
The hostctl command allocate 4k bytes memory for store the value. Then
read the value by ioctl() system call. If ioctl() returned -1 end
errno is ERANGE, then hostctl comannd reallocate twice as much space.
The upper limit is PVBUS_KVOP_MAXSIZE (64k bytes).
Check the patch, please.
comment, ok?
--
ASOU Masato
diff --git a/share/man/man4/pvbus.4 b/share/man/man4/pvbus.4
index 8d67809e9c0..3c6681decf0 100644
--- a/share/man/man4/pvbus.4
+++ b/share/man/man4/pvbus.4
@@ -125,6 +125,13 @@ Read the value from
.Fa pvr_key
and return it in
.Fa pvr_value .
+If
+.Fa pvr_valuelen
+is not enough for the value,
+the command will fail and
+.Xr errno 2
+is set to
+.Er ERANGE .
.It Dv PVBUSIOC_KVTYPE
Return the type of the attached hypervisor interface as a string in
.Fa pvr_key ;
diff --git a/sys/dev/pv/hypervic.c b/sys/dev/pv/hypervic.c
index 9c7f70dd96f..a7455d03e5b 100644
--- a/sys/dev/pv/hypervic.c
+++ b/sys/dev/pv/hypervic.c
@@ -1151,11 +1151,12 @@ hv_kvop(void *arg, int op, char *key, char *val, size_t
vallen)
kvpl = >kvp_pool[pool];
if (strlen(key) == 0) {
for (next = 0; next < MAXPOOLENTS; next++) {
- if ((val + vallen < vp + HV_KVP_MAX_KEY_SIZE / 2) ||
- kvp_pool_keys(kvpl, next, vp, ))
+ if (val + vallen < vp + HV_KVP_MAX_KEY_SIZE / 2)
+ return (ERANGE);
+ if (kvp_pool_keys(kvpl, next, vp, ))
goto out;
if (strlcat(val, "\n", vallen) >= vallen)
- goto out;
+ return (ERANGE);
vp += keylen;
}
out:
diff --git a/sys/dev/pv/pvbus.c b/sys/dev/pv/pvbus.c
index 5f7c4b57fe0..c76a9e81444 100644
--- a/sys/dev/pv/pvbus.c
+++ b/sys/dev/pv/pvbus.c
@@ -400,12 +400,12 @@ pvbusgetstr(size_t srclen, const char *src, char **dstp)
/*
* Reject size that is too short or obviously too long:
* - at least one byte for the nul terminator.
-* - PAGE_SIZE is an arbitrary value, but known pv backends seem
-* to have a hard (PAGE_SIZE - x) limit in their messaging.
+* - PVBUS_KVOP_MAXSIZE is an arbitrary value, but known pv backends
+* seem to have a hard (PAGE_SIZE - x) limit in their messaging.
*/
if (srclen < 1)
return (EINVAL);
- else if (srclen > PAGE_SIZE)
+ else if (srclen > PVBUS_KVOP_MAXSIZE)
return (ENAMETOOLONG);
*dstp = dst = malloc(srclen + 1, M_TEMP, M_WAITOK | M_ZERO);
diff --git a/sys/dev/pv/pvvar.h b/sys/dev/pv/pvvar.h
index 4e23ae52bd5..333d4fddf9c 100644
--- a/sys/dev/pv/pvvar.h
+++ b/sys/dev/pv/pvvar.h
@@ -30,6 +30,8 @@ struct pvbus_req {
#define PVBUSIOC_KVWRITE _IOWR('V', 2, struct pvbus_req)
#define PVBUSIOC_TYPE _IOWR('V', 3, struct pvbus_req)
+#definePVBUS_KVOP_MAXSIZE (64 * 1024)
+
#ifdef _KERNEL
enum {
PVBUS_KVM,
diff --git a/sys/dev/pv/xenstore.c b/sys/dev/pv/xenstore.c
index 494eb40bfb0..c32f1cea7d7 100644
--- a/sys/dev/pv/xenstore.c
+++ b/sys/dev/pv/xenstore.c
@@ -1072,6 +1072,7 @@ xs_kvop(void *xsc, int op, char *key, char *value, size_t
valuelen)
struct xs_transaction xst;
struct iovec iov, *iovp =
int error = 0, iov_cnt = 0, cmd, i;
+ size_t pos;
switch (op) {
case PVBUS_KVWRITE:
@@ -1115,12 +1116,19 @@ xs_kvop(void *xsc, int op, char *key, char *value,
size_t valuelen)
}
/* FALLTHROUGH */
case XS_LIST:
- for (i = 0; i < iov_cnt; i++) {
- if (i && strlcat(value, "\n", valuelen) >= valuelen)
- break;
- if (strlcat(value, iovp[i].iov_base,
- valuelen) >= valuelen)
+ for (i = pos = 0; i < iov_cnt; i++) {
+ if (i) {
+ if (pos + 1 >= valuelen) {
+ error = ERANGE;
+ break;
+ }
+ value[pos++] = '\n';
+ }
+ if (strlen(iovp[i].iov_base) >=
Re: Machine after unhibernate *sometimes* won't suspend/hibernate again or dim screen
On Fri, Dec 23, 2022 at 03:13:53PM -0600, Abel Abraham Camarillo Ojeda wrote: > On Fri, Dec 23, 2022 at 2:46 PM Abel Abraham Camarillo Ojeda < > acam...@verlet.org> wrote: > > > Forgot to mention I don't think this is a regression, just started to use > > hibernate/unhibernate more often lately. > > But I think I can reproduce this at least since 6.8 (the first that I > > installed to this machine) > > > >> > >> > >> But still this apply https://www.openbsd.org/report.html (point 2) > >> > > > > By doesn't work I mean: > > > > $ zzz > > Suspending system... > > $ (nothing happened) > > > > > real mem = 17021566976 (16233MB) > >> > avail mem = 16488275968 (15724MB) > >> > random: good seed from bootblocks > >> > mpath0 at root > >> > scsibus0 at mpath0: 256 targets > >> > mainbus0 at root > >> > bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xb9908000 (58 entries) > >> > bios0: vendor LENOVO version "R0GET56W (1.56 )" date 08/31/2017 > >> > >> You should try > >> https://pcsupport.lenovo.com/us/en/products/laptops-and-netbooks/thinkpad-l-series-laptops/thinkpad-l470/downloads/ds120327 > >> and see if problem is still present (of course good to have backup :-)) > >> > > > > yes, forgot about that. Will update bios and retry > > > > machine now with bios updated, can reproduce issue after 1 unhibernate, > dmesg right now at "zzz does nothing stage": > 1. acpi thread might be stuck as kettenis points out. to verify this, try a suspend (lowercase zzz) instead of a hibernate (capital ZZZ) when it gets stuck. If you can zzz but not ZZZ, then it's not the acpi thread. 2. more likely, IMO, is not being able to find a consecutive region in free memory to store the hibernate data structures. If memory gets fragmented, ZZZ will fail. It should print something to dmesg though, so check that. This matches your symptoms of "always works the first time but sometimes not on subsequent tries".
Re: ksh.1: Add a missing Ns
On Sat, Dec 24, 2022 at 12:25:15PM -0500, Josiah Frentsos wrote: > Index: ksh.1 > === > RCS file: /cvs/src/bin/ksh/ksh.1,v > retrieving revision 1.217 > diff -u -p -r1.217 ksh.1 > --- ksh.1 13 Sep 2022 20:26:26 - 1.217 > +++ ksh.1 24 Dec 2022 17:22:08 - > @@ -3454,9 +3454,7 @@ option is used, input is saved to the hi > .It Xo > .Ic readonly > .Op Fl p > -.Oo Ar parameter > -.Op Ns = Ns Ar value > -.Ar ... Oc > +.Op Ar parameter Ns Oo = Ns Ar value Oc Ar ... > .Xc > Sets the read-only attribute of the named parameters. > If values are given, > so i see this same notation for "alias" and "typeset". do you want to check out whether the same changes make sense there (and whether i've missed any) and submit an updated diff? thanks, jmc
Re: copystr(9) vs strlcpy
On Sun, Dec 25, 2022 at 08:07:11PM +, Miod Vallat wrote:
> Indeed! So the third copystr() call could be replaced with this:
>
> Index: sys/kern/vfs_lookup.c
> ===
> RCS file: /OpenBSD/src/sys/kern/vfs_lookup.c,v
> retrieving revision 1.87
> diff -u -p -r1.87 vfs_lookup.c
> --- sys/kern/vfs_lookup.c 14 Aug 2022 01:58:28 - 1.87
> +++ sys/kern/vfs_lookup.c 25 Dec 2022 20:06:27 -
> @@ -143,10 +143,16 @@ namei(struct nameidata *ndp)
>*/
> if ((cnp->cn_flags & HASBUF) == 0)
> cnp->cn_pnbuf = pool_get(_pool, PR_WAITOK);
> - if (ndp->ni_segflg == UIO_SYSSPACE)
> - error = copystr(ndp->ni_dirp, cnp->cn_pnbuf,
> - MAXPATHLEN, >ni_pathlen);
> - else
> + if (ndp->ni_segflg == UIO_SYSSPACE) {
> + ndp->ni_pathlen = strlcpy(cnp->cn_pnbuf, ndp->ni_dirp,
> + MAXPATHLEN);
> + if (ndp->ni_pathlen >= MAXPATHLEN) {
> + error = ENAMETOOLONG;
> + } else {
> + error = 0;
> + ndp->ni_pathlen++; /* ni_pathlen includes NUL */
> + }
> + } else
> error = copyinstr(ndp->ni_dirp, cnp->cn_pnbuf,
> MAXPATHLEN, >ni_pathlen);
Looks good to me.
Re: copystr(9) vs strlcpy
> > In other words,
> > copystr(src, dst, dstsiz, len)
> > is equivalent to:
> > if (strlcpy(dst, src, dstsiz) >= dstsiz)
> > return ENAMETOOLONG;
> > if (len != NULL)
> > *len = strlen(dst);
>
> This should be *len = strlen(dst)+1 as copystr includes the terminating 0x00
> in the length count.
>
> It doesn't matter for the current diff, but it will matter if you replace the
> last remaining use of copystr which does use the returned length value.
Indeed! So the third copystr() call could be replaced with this:
Index: sys/kern/vfs_lookup.c
===
RCS file: /OpenBSD/src/sys/kern/vfs_lookup.c,v
retrieving revision 1.87
diff -u -p -r1.87 vfs_lookup.c
--- sys/kern/vfs_lookup.c 14 Aug 2022 01:58:28 - 1.87
+++ sys/kern/vfs_lookup.c 25 Dec 2022 20:06:27 -
@@ -143,10 +143,16 @@ namei(struct nameidata *ndp)
*/
if ((cnp->cn_flags & HASBUF) == 0)
cnp->cn_pnbuf = pool_get(_pool, PR_WAITOK);
- if (ndp->ni_segflg == UIO_SYSSPACE)
- error = copystr(ndp->ni_dirp, cnp->cn_pnbuf,
- MAXPATHLEN, >ni_pathlen);
- else
+ if (ndp->ni_segflg == UIO_SYSSPACE) {
+ ndp->ni_pathlen = strlcpy(cnp->cn_pnbuf, ndp->ni_dirp,
+ MAXPATHLEN);
+ if (ndp->ni_pathlen >= MAXPATHLEN) {
+ error = ENAMETOOLONG;
+ } else {
+ error = 0;
+ ndp->ni_pathlen++; /* ni_pathlen includes NUL */
+ }
+ } else
error = copyinstr(ndp->ni_dirp, cnp->cn_pnbuf,
MAXPATHLEN, >ni_pathlen);
PMAP_PREFER dead code
With the introduction of the PMAP_PREFER_{ALIGN,OFFSET} macros a long
time ago, there are actually no more uses of the PMAP_PREFER macro left
in the kernel.
The following diff removes PMAP_PREFER() but keeps a simple #define for
it to let uvm knows the PMAP_PREFER_{ALIGN,OFFSET} macros are available.
It might be worth renaming that enabling macro to __HAVE_PMAP_PREFER to
mimic existing macros such as __HAVE_PMAP_{COLLECT,DIRECT}... but then
PMAP_GROWKERNEL does not start with __HAVE so there is already a lack of
consistency in this area.
Note that this diff actually removes PMAP_PREFER on armv7, since none
of the targeted v7 platforms actually end up having virtual aliasing.
Tested on all affected PMAP_DIRECT platforms (and armv7 which is no
longer part of the club).
Miod
Index: sys/arch/arm/arm/pmap7.c
===
RCS file: /OpenBSD/src/sys/arch/arm/arm/pmap7.c,v
retrieving revision 1.65
diff -u -p -u -p -r1.65 pmap7.c
--- sys/arch/arm/arm/pmap7.c12 Sep 2022 19:28:19 - 1.65
+++ sys/arch/arm/arm/pmap7.c25 Dec 2022 16:53:14 -
@@ -2848,20 +2848,3 @@ pmap_pte_init_armv7(void)
if ((id_mmfr3 & 0x00f0) == 0x0010)
pmap_needs_pte_sync = 0;
}
-
-uint32_t pmap_alias_dist;
-uint32_t pmap_alias_bits;
-
-vaddr_t
-pmap_prefer(vaddr_t foff, vaddr_t va)
-{
- long d, m;
-
- m = pmap_alias_dist;
- if (m == 0) /* m=0 => no cache aliasing */
- return va;
-
- d = foff - va;
- d &= (m - 1);
- return va + d;
-}
Index: sys/arch/arm/include/pmap.h
===
RCS file: /OpenBSD/src/sys/arch/arm/include/pmap.h,v
retrieving revision 1.51
diff -u -p -u -p -r1.51 pmap.h
--- sys/arch/arm/include/pmap.h 12 Sep 2022 19:28:19 - 1.51
+++ sys/arch/arm/include/pmap.h 25 Dec 2022 16:53:14 -
@@ -613,23 +613,6 @@ l2pte_is_writeable(pt_entry_t pte, struc
#defineL2_L_MAPPABLE_P(va, pa, size)
\
va) | (pa)) & L2_L_OFFSET) == 0 && (size) >= L2_L_SIZE)
-#ifndef _LOCORE
-/* pmap_prefer bits for VIPT ARMv7 */
-#define PMAP_PREFER(fo, ap)pmap_prefer((fo), (ap))
-vaddr_tpmap_prefer(vaddr_t, vaddr_t);
-
-extern uint32_t pmap_alias_dist;
-extern uint32_t pmap_alias_bits;
-
-/* pmap prefer alias alignment. */
-#define PMAP_PREFER_ALIGN()(pmap_alias_dist)
-/* pmap prefer offset withing alignment. */
-#define PMAP_PREFER_OFFSET(of) \
-(PMAP_PREFER_ALIGN() == 0 ? 0 : ((of) & (PMAP_PREFER_ALIGN() - 1)))
-
-
-#endif /* _LOCORE */
-
#endif /* _KERNEL */
#ifndef _LOCORE
Index: sys/arch/hppa/include/cpu.h
===
RCS file: /OpenBSD/src/sys/arch/hppa/include/cpu.h,v
retrieving revision 1.97
diff -u -p -u -p -r1.97 cpu.h
--- sys/arch/hppa/include/cpu.h 6 Dec 2022 00:40:09 - 1.97
+++ sys/arch/hppa/include/cpu.h 25 Dec 2022 16:53:14 -
@@ -191,7 +191,6 @@ extern int cpu_hvers;
*/
#defineHPPA_PGALIAS0x0040
-#defineHPPA_PGAMASK0xffc0
#defineHPPA_PGAOFF 0x003f
#defineHPPA_IOBEGIN0xf000
Index: sys/arch/hppa/include/pmap.h
===
RCS file: /OpenBSD/src/sys/arch/hppa/include/pmap.h,v
retrieving revision 1.52
diff -u -p -u -p -r1.52 pmap.h
--- sys/arch/hppa/include/pmap.h25 Oct 2022 18:44:36 - 1.52
+++ sys/arch/hppa/include/pmap.h25 Dec 2022 16:53:14 -
@@ -91,16 +91,7 @@ struct vm_page *pmap_unmap_direct(vaddr_
* according to the parisc manual aliased va's should be
* different by high 12 bits only.
*/
-#definePMAP_PREFER(o,h)pmap_prefer(o, h)
-static __inline__ vaddr_t
-pmap_prefer(vaddr_t offs, vaddr_t hint)
-{
- vaddr_t pmap_prefer_hint = (hint & HPPA_PGAMASK) | (offs & HPPA_PGAOFF);
- if (pmap_prefer_hint < hint)
- pmap_prefer_hint += HPPA_PGALIAS;
- return pmap_prefer_hint;
-}
-
+#definePMAP_PREFER
/* pmap prefer alignment */
#define PMAP_PREFER_ALIGN()(HPPA_PGALIAS)
/* pmap prefer offset within alignment */
Index: sys/arch/mips64/include/pmap.h
===
RCS file: /OpenBSD/src/sys/arch/mips64/include/pmap.h,v
retrieving revision 1.50
diff -u -p -u -p -r1.50 pmap.h
--- sys/arch/mips64/include/pmap.h 10 Sep 2022 20:35:28 - 1.50
+++ sys/arch/mips64/include/pmap.h 25 Dec 2022 16:53:14 -
@@ -149,8 +149,7 @@ extern struct pmap *const kernel_pmap_pt
#definePMAP_STEAL_MEMORY /* Enable 'stealing' during
boot */
-#definePMAP_PREFER(pa, va) pmap_prefer(pa, va)
-
+#definePMAP_PREFER
extern vaddr_t pmap_prefer_mask;
/* pmap prefer alignment */
#definePMAP_PREFER_ALIGN()
Re: copystr(9) vs strlcpy
Hi Miod, On Sun, Dec 25, 2022 at 05:21:50PM +, Miod Vallat wrote: > In other words, > copystr(src, dst, dstsiz, len) > is equivalent to: > if (strlcpy(dst, src, dstsiz) >= dstsiz) > return ENAMETOOLONG; > if (len != NULL) > *len = strlen(dst); This should be *len = strlen(dst)+1 as copystr includes the terminating 0x00 in the length count. It doesn't matter for the current diff, but it will matter if you replace the last remaining use of copystr which does use the returned length value.
Re: em(4) multiqueue
On 15.8.2022. 20:51, Hrvoje Popovski wrote: > On 12.8.2022. 22:15, Hrvoje Popovski wrote: >> Hi, >> >> I'm testing forwarding over >> >> em0 at pci7 dev 0 function 0 "Intel 82576" rev 0x01, msix, 4 queues, >> em1 at pci7 dev 0 function 1 "Intel 82576" rev 0x01, msix, 4 queues, >> em2 at pci8 dev 0 function 0 "Intel I210" rev 0x03, msix, 4 queues, >> em3 at pci9 dev 0 function 0 "Intel I210" rev 0x03, msix, 4 queues, >> em4 at pci12 dev 0 function 0 "Intel I350" rev 0x01, msix, 4 queues, >> em5 at pci12 dev 0 function 1 "Intel I350" rev 0x01, msix, 4 queues, > I've managed to get linux pktgen to send traffic on all 6 em interfaces > at that same time, and box seems to work just fine. Some systat, vmstat > and kstat details in attachment while traffic is flowing over that box. Hi, after 95 day in production with this diff and i350 and everything works as expected. I'm sending this because it's time to upgrade :) Is it maybe time to put this diff in ? ix0 at pci5 dev 0 function 0 "Intel X540T" rev 0x01, msix, 8 queues, address a0:36:9f:29:f3:28 ix1 at pci5 dev 0 function 1 "Intel X540T" rev 0x01, msix, 8 queues, address a0:36:9f:29:f3:2a em0 at pci6 dev 0 function 0 "Intel I350" rev 0x01, msix, 8 queues, address ac:1f:6b:14:bd:b2 em1 at pci6 dev 0 function 1 "Intel I350" rev 0x01, msix, 8 queues, address ac:1f:6b:14:bd:b3 fw2# uptime 6:34PM up 95 days, 19:26, 1 user, load averages: 0.00, 0.00, 0.00 fw2# vmstat -i interrupt total rate irq0/clock 6622294171 799 irq0/ipi 8263089839 998 irq96/acpi0 10 irq114/ix0:0514761687 62 irq115/ix0:1510189468 61 irq116/ix0:2522691117 63 irq117/ix0:3531638415 64 irq118/ix0:4534116996 64 irq119/ix0:5511162669 61 irq120/ix0:6535267806 64 irq121/ix0:7519707637 62 irq122/ix0 20 irq99/xhci0680 irq100/ehci0 190 irq132/em0:0498689640 60 irq133/em0:1516744073 62 irq134/em0:2520784714 62 irq135/em0:3512596405 61 irq136/em0:4521988376 63 irq137/em0:5513939246 62 irq138/em0:6517184525 62 irq139/em0:7509781661 61 irq140/em0 20 irq141/em1:0216273893 26 irq143/em1:2283094667 34 irq148/em1:520 irq151/em1 180 irq100/ehci1 190 irq103/ahci0 50490680 Total 23681046204 2860
Re: copystr(9) vs strlcpy
On Sun, 25 Dec 2022 17:21:50 +, Miod Vallat wrote: > Now, there are three uses of copystr() left in the kernel, and two of > them ignore the return value of copystr(), and do not need the length of > the result to be returned. > > These two can be trivially replaced with strlcpy() calls. Sure. OK millert@ - todd
copystr(9) vs strlcpy
Ho ho ho, copystr(9) is a very old and seldom used kernel function, which performs a bounded string copy and optionally returns the length of the copied string. In other words, copystr(src, dst, dstsiz, len) is equivalent to: if (strlcpy(dst, src, dstsiz) >= dstsiz) return ENAMETOOLONG; if (len != NULL) *len = strlen(dst); return 0; since, unlike all the other copy*(9) functions, this one doesn't have to check for faults since it copies from (supposedly) valid kernel memory to (supposedly) valid kernel memory. But strlcpy() didn't exist at the time copystr() was introduced. Now, there are three uses of copystr() left in the kernel, and two of them ignore the return value of copystr(), and do not need the length of the result to be returned. These two can be trivially replaced with strlcpy() calls. How about this diff? Miod Index: sys/kern/vfs_subr.c === RCS file: /OpenBSD/src/sys/kern/vfs_subr.c,v retrieving revision 1.317 diff -u -p -u -p -r1.317 vfs_subr.c --- sys/kern/vfs_subr.c 14 Aug 2022 01:58:28 - 1.317 +++ sys/kern/vfs_subr.c 25 Dec 2022 16:57:42 - @@ -270,8 +270,8 @@ vfs_rootmountalloc(char *fstypename, cha mp = vfs_mount_alloc(NULLVP, vfsp); mp->mnt_flag |= MNT_RDONLY; mp->mnt_stat.f_mntonname[0] = '/'; - copystr(devname, mp->mnt_stat.f_mntfromname, MNAMELEN, NULL); - copystr(devname, mp->mnt_stat.f_mntfromspec, MNAMELEN, NULL); + strlcpy(mp->mnt_stat.f_mntfromname, devname, MNAMELEN); + strlcpy(mp->mnt_stat.f_mntfromspec, devname, MNAMELEN); *mpp = mp; return (0); }
only open /dev/vmm once in vmd(8)
During h2k22 there was some discussion around how vmd(8) manages vms and
the vmm(4) device's role. While looking into something related, I found
vmd opens /dev/vmm in each subprocess during the initial fork+execve
dance.
The only vmd process that needs /dev/vmm is the vmm process.
The diff below changes it so that *only* the parent process opens
/dev/vmm and then uses fd passing to send it to the vmm process once
fork+exec'd. This adds a new imsg type specific to this handoff.
The other processes don't end up with the vmm pledge, so there's no
reason they need open file descriptors to the vmm device.
OK?
diff refs/heads/master refs/heads/vmd-vmm-open
commit - adc9c11636d08981539860c611938338c714d31e
commit + 1bb17c1c2d6cd28c231fa2eb6f8494e5498bb1a3
blob - bd0d8580ffc25d905e5f20c1de5044397ddf313d
blob + 41e4b7b5852c7523a7b1c0e3a73591638a9c9e56
--- usr.sbin/vmd/vmd.c
+++ usr.sbin/vmd/vmd.c
@@ -847,8 +847,8 @@ main(int argc, char **argv)
proc_priv->p_pw = _privpw; /* initialized to all 0 */
proc_priv->p_chroot = ps->ps_pw->pw_dir; /* from VMD_USER */
- /* Open /dev/vmm */
- if (env->vmd_noaction == 0) {
+ /* Open /dev/vmm early. */
+ if (env->vmd_noaction == 0 && proc_id == PROC_PARENT) {
env->vmd_fd = open(VMM_NODE, O_RDWR);
if (env->vmd_fd == -1)
fatal("%s", VMM_NODE);
@@ -971,6 +971,10 @@ vmd_configure(void)
exit(0);
}
+ /* Send VMM device fd to vmm proc. */
+ proc_compose_imsg(>vmd_ps, PROC_VMM, -1,
+ IMSG_VMDOP_RECEIVE_VMM_FD, -1, env->vmd_fd, NULL, 0);
+
/* Send shared global configuration to all children */
if (config_setconfig(env) == -1)
return (-1);
blob - c27d03df7336a2c8ede22ec0d83b74d327fb3244
blob + 2ca4aa336bf68b0d8bf8183e92c9d0ef99d5411e
--- usr.sbin/vmd/vmd.h
+++ usr.sbin/vmd/vmd.h
@@ -108,6 +108,7 @@ enum imsg_type {
IMSG_VMDOP_GET_INFO_VM_DATA,
IMSG_VMDOP_GET_INFO_VM_END_DATA,
IMSG_VMDOP_LOAD,
+ IMSG_VMDOP_RECEIVE_VMM_FD,
IMSG_VMDOP_RELOAD,
IMSG_VMDOP_PRIV_IFDESCR,
IMSG_VMDOP_PRIV_IFADD,
blob - 6c2bdbd12a3ee11aa88055200e11e0f2a0ff667f
blob + 2f82a241c1c1672770529ef98f9b748714512704
--- usr.sbin/vmd/vmm.c
+++ usr.sbin/vmd/vmm.c
@@ -94,9 +94,6 @@ vmm_run(struct privsep *ps, struct privsep_proc *p, vo
*/
if (pledge("stdio vmm sendfd recvfd proc", NULL) == -1)
fatal("pledge");
-
- /* Get and terminate all running VMs */
- get_info_vm(ps, NULL, 1);
}
int
@@ -315,6 +312,14 @@ vmm_dispatch_parent(int fd, struct privsep_proc *p, st
imsg->hdr.type, imsg->hdr.peerid, imsg->hdr.pid,
imsg->fd, , sizeof(var));
break;
+ case IMSG_VMDOP_RECEIVE_VMM_FD:
+ if (env->vmd_fd > -1)
+ fatalx("already received vmm fd");
+ env->vmd_fd = imsg->fd;
+
+ /* Get and terminate all running VMs */
+ get_info_vm(ps, NULL, 1);
+ break;
default:
return (-1);
}
Re: Size reduction experiments for LLVM-built sparc64 kernel
Some weekend updates:
1. The clang-built kernels seem to be working well enough that I could
complete building a (GCC-built) userland.
2. I tried a larger set of LLVM patches (D51206, D128263, D130006,
D132465, D135515, D138532, D138741, D138887, D138922, D139535, and
D140515) and while it does reduce the kernel binary, it did not
do it much - the kernel only gets about 10k smaller compared to
the previous build.
(that is, still ~77k bigger than the GCC-built binary)
textdatabss dec hex
8089416 2295436 728216 3068a9926c bsd.clang+patch+noinline
8066232 2304032 732528 11102792a96a48 bsd.clang+patchv2+noinline
7862920 2429596 730968 11023484a8347c bsd.gcc
3. Also, additionally I also tried to build the userland with clang but
sadly it fails with some compiler errors:
With `make COMPILER_VERSION=clang CC=clang build`, I'm getting:
In file included from
/usr/src/gnu/llvm/compiler-rt/lib/sanitizer_common/sanitizer_internal_defs.h:15,
from
/usr/src/gnu/llvm/compiler-rt/lib/sanitizer_common/sanitizer_atomic.h:16,
from
/usr/src/gnu/lib/libclang_rt/ubsan_minimal/../../../llvm/compiler-rt/lib/ubsan_minimal/ubsan_minimal_handlers.cpp:1:
/usr/src/gnu/llvm/compiler-rt/lib/sanitizer_common/sanitizer_platform.h:25:18:
error: missing binary operator before token "("
In file included from
/usr/src/gnu/llvm/compiler-rt/lib/sanitizer_common/sanitizer_atomic.h:16,
from
/usr/src/gnu/lib/libclang_rt/ubsan_minimal/../../../llvm/compiler-rt/lib/ubsan_minimal/ubsan_minimal_handlers.cpp:1:
/usr/src/gnu/llvm/compiler-rt/lib/sanitizer_common/sanitizer_internal_defs.h:412:
error: 'constexpr' does not name a type
/usr/src/gnu/llvm/compiler-rt/lib/sanitizer_common/sanitizer_internal_defs.h:413:
error: 'constexpr' does not name a type
In file included from
/usr/src/gnu/llvm/compiler-rt/lib/sanitizer_common/sanitizer_atomic_clang.h:20,
from
/usr/src/gnu/llvm/compiler-rt/lib/sanitizer_common/sanitizer_atomic.h:63,
from
/usr/src/gnu/lib/libclang_rt/ubsan_minimal/../../../llvm/compiler-rt/lib/ubsan_minimal/ubsan_minimal_handlers.cpp:1:
/usr/src/gnu/llvm/compiler-rt/lib/sanitizer_common/sanitizer_atomic_clang_other.h:
In function 'typename T::Type __sanitizer::atomic_load(const volatile T*,
__sanitizer::memory_order)':
/usr/src/gnu/llvm/compiler-rt/lib/sanitizer_common/sanitizer_atomic_clang_other.h:54:
error: '__ATOMIC_SEQ_CST' was not declared in this scope
/usr/src/gnu/llvm/compiler-rt/lib/sanitizer_common/sanitizer_atomic_clang_other.h:
In function 'void __sanitizer::atomic_store(volatile T*, typename T::Type,
__sanitizer::memory_order)':
/usr/src/gnu/llvm/compiler-rt/lib/sanitizer_common/sanitizer_atomic_clang_other.h:79:
error: '__ATOMIC_SEQ_CST' was not declared in this scope
/usr/src/gnu/llvm/compiler-rt/lib/sanitizer_common/sanitizer_atomic_clang_other.h:
In function 'typename T::Type __sanitizer::atomic_load(const volatile T*,
__sanitizer::memory_order) [with T = __sanitizer::atomic_uint32_t]':
/usr/src/gnu/llvm/compiler-rt/lib/sanitizer_common/sanitizer_atomic.h:76:
instantiated from 'typename T::Type __sanitizer::atomic_load_relaxed(const
volatile T*) [with T = __sanitizer::atomic_uint32_t]'
/usr/src/gnu/lib/libclang_rt/ubsan_minimal/../../../llvm/compiler-rt/lib/ubsan_minimal/ubsan_minimal_handlers.cpp:27:
instantiated from here
/usr/src/gnu/llvm/compiler-rt/lib/sanitizer_common/sanitizer_atomic_clang_other.h:53:
error: '__atomic_load' was not declared in this scope
/usr/src/gnu/llvm/compiler-rt/lib/sanitizer_common/sanitizer_atomic_clang_other.h:
In function 'typename T::Type __sanitizer::atomic_load(const volatile T*,
__sanitizer::memory_order) [with T = __sanitizer::atomic_uintptr_t]':
/usr/src/gnu/llvm/compiler-rt/lib/sanitizer_common/sanitizer_atomic.h:76:
instantiated from 'typename T::Type __sanitizer::atomic_load_relaxed(const
volatile T*) [with T = __sanitizer::atomic_uintptr_t]'
/usr/src/gnu/lib/libclang_rt/ubsan_minimal/../../../llvm/compiler-rt/lib/ubsan_minimal/ubsan_minimal_handlers.cpp:34:
instantiated from here
/usr/src/gnu/llvm/compiler-rt/lib/sanitizer_common/sanitizer_atomic_clang_other.h:53:
error: '__atomic_load' was not declared in this scope
/usr/src/gnu/llvm/compiler-rt/lib/sanitizer_common/sanitizer_atomic_clang_other.h:
In function 'void __sanitizer::atomic_store(volatile T*, typename T::Type,
__sanitizer::memory_order) [with T = __sanitizer::atomic_uintptr_t]':
/usr/src/gnu/llvm/compiler-rt/lib/sanitizer_common/sanitizer_atomic.h:81:
instantiated from 'void __sanitizer::atomic_store_relaxed(volatile T*, typename
T::Type) [with T = __sanitizer::atomic_uintptr_t]'
/usr/src/gnu/lib/libclang_rt/ubsan_minimal/../../../llvm/compiler-rt/lib/ubsan_minimal/ubsan_minimal_handlers.cpp:49:
instantiated from here
/usr/src/gnu/llvm/compiler-rt/lib/sanitizer_common/sanitizer_atomic_clang_other.h:79:
error:
Add Apple heic/heif to magic(5) file
Hi, I'd like to add the mime magic for the Apple heic/heif formats, which are used by Apple devices in recent years to store media. This format family can contain still images, short sequences (live photos) and videos. The rules are taken from FreeBSD. OK? Best Regards, Stefan Index: usr.bin/file/magdir/animation === RCS file: /cvs/src/usr.bin/file/magdir/animation,v retrieving revision 1.6 diff -u -p -u -p -r1.6 animation --- usr.bin/file/magdir/animation 2 Jan 2016 13:25:33 - 1.6 +++ usr.bin/file/magdir/animation 25 Dec 2022 13:50:52 - @@ -65,6 +65,35 @@ !:mime video/mp4 >8 string/Wqt \b, Apple QuickTime movie !:mime video/quicktime +# HEIF image format +# see https://nokiatech.github.io/heif/technical.html +>8 string mif1\b, HEIF Image +!:mime image/heif +>8 string msf1\b, HEIF Image Sequence +!:mime image/heif-sequence +>8 string heic\b, HEIF Image HEVC Main or Main Still Picture Profile +!:mime image/heic +>8 string heix\b, HEIF Image HEVC Main 10 Profile +!:mime image/heic +>8 string hevc\b, HEIF Image Sequenz HEVC Main or Main Still Picture Profile +!:mime image/heic-sequence +>8 string hevx\b, HEIF Image Sequence HEVC Main 10 Profile +!:mime image/heic-sequence +# following HEIF brands are not mentioned in the heif technical info currently (Oct 2017) +# but used in the reference implementation: +# https://github.com/nokiatech/heif/blob/d5e9a21c8ba8df712bdf643021dd9f6518134776/Srcs/reader/hevcimagefilereader.cpp +>8 string heim\b, HEIF Image L-HEVC +!:mime image/heif +>8 string heis\b, HEIF Image L-HEVC +!:mime image/heif +>8 string avic\b, HEIF Image AVC +!:mime image/heif +>8 string hevm\b, HEIF Image Sequence L-HEVC +!:mime image/heif-sequence +>8 string hevs\b, HEIF Image Sequence L-HEVC +!:mime image/heif-sequence +>8 string avcs\b, HEIF Image Sequence AVC +!:mime image/heif-sequence >8 string CAEP\b, Canon Digital Camera >8 string caqv\b, Casio Digital Camera >8 string CDes\b, Convergent Design
