uhidev: remove unused code
Hi,
The uhidevsubmatch() routine was imported from NetBSD back in 2002[1] along with
the reportid locator. The same locator was removed in 2004[2] making
this routine and its defines redundant.
Comments? OK?
[1]
https://github.com/openbsd/src/commit/a66cb31e58a16ed957a52ce1b92aafc08fc4900d
[2]
https://github.com/openbsd/src/commit/cd0cdd200650f714bb35984fcf257b23b34b6f39
diff --git sys/dev/usb/uhidev.c sys/dev/usb/uhidev.c
index b56c00ceceb..d4bd3c5fef9 100644
--- sys/dev/usb/uhidev.c
+++ sys/dev/usb/uhidev.c
@@ -89,7 +89,6 @@ void uhidev_intr(struct usbd_xfer *, void *, usbd_status);
int uhidev_maxrepid(void *buf, int len);
int uhidevprint(void *aux, const char *pnp);
-int uhidevsubmatch(struct device *parent, void *cf, void *aux);
int uhidev_match(struct device *, void *, void *);
void uhidev_attach(struct device *, struct device *, void *);
@@ -257,7 +256,7 @@ uhidev_attach(struct device *parent, struct device *self,
void *aux)
uha.nreports = nrepid;
uha.claimed = malloc(nrepid, M_TEMP, M_WAITOK|M_ZERO);
- dev = config_found_sm(self, , NULL, uhidevsubmatch);
+ dev = config_found_sm(self, , NULL, NULL);
if (dev != NULL) {
for (repid = 0; repid < nrepid; repid++) {
/*
@@ -290,7 +289,7 @@ uhidev_attach(struct device *parent, struct device *self,
void *aux)
continue;
uha.reportid = repid;
- dev = config_found_sm(self, , uhidevprint, uhidevsubmatch);
+ dev = config_found_sm(self, , uhidevprint, NULL);
sc->sc_subdevs[repid] = (struct uhidev *)dev;
}
}
@@ -373,17 +372,6 @@ uhidevprint(void *aux, const char *pnp)
return (UNCONF);
}
-int uhidevsubmatch(struct device *parent, void *match, void *aux)
-{
- struct uhidev_attach_arg *uha = aux;
-struct cfdata *cf = match;
-
- if (cf->uhidevcf_reportid != UHIDEV_UNK_REPORTID &&
- cf->uhidevcf_reportid != uha->reportid)
- return (0);
- return ((*cf->cf_attach->ca_match)(parent, cf, aux));
-}
-
int
uhidev_activate(struct device *self, int act)
{
diff --git sys/dev/usb/uhidev.h sys/dev/usb/uhidev.h
index 9ae85e1ab9f..104fe59c8aa 100644
--- sys/dev/usb/uhidev.h
+++ sys/dev/usb/uhidev.h
@@ -31,12 +31,6 @@
* POSSIBILITY OF SUCH DAMAGE.
*/
-#define UHIDBUSCF_REPORTID 0
-#define UHIDBUSCF_REPORTID_DEFAULT -1
-
-#define uhidevcf_reportid cf_loc[UHIDBUSCF_REPORTID]
-#define UHIDEV_UNK_REPORTID UHIDBUSCF_REPORTID_DEFAULT
-
struct uhidev_softc {
struct device sc_dev; /* base device */
struct usbd_device *sc_udev;
Re: bsd.upgrade fails `umount /mnt` with a single partition disk.
Thanks for the comment.
I will see it further more.
On 11/8/21 12:45, Theo de Raadt wrote:
Doesn't this suggest a disk driver failed to perform/complete a write?
Not right at that moment but perhaps in the recent past?
Yuichiro NAITO wrote:
bsd.upgrade fails and shows following messages with a single partition disk.
```
Force checking of clean non-root filesystems? [no] no
umount: /mnt: Device busy
Can't umount sd0a!
```
sd0 has following partitions.
```
#size offset fstype [fsize bsize cpg]
a: 37752672 64 4.2bsd 2048 16384 12959 # /
b: 4176900 37752750swap# none
c: 419430400 unused
```
I don't want to say any thing about disk partitioning policy.
I just want to improve bsd.upgrade more stable.
This error happens in a specific environment.
In my cases, OpenBSD on FreeBSD bhyve in Intel Core i7-6700 box caused
this error. No other environments (that I have) reproduce it.
In my investigation, the following patch caused panic in the bhyve
environment.
diff --git a/sys/kern/vfs_subr.c b/sys/kern/vfs_subr.c
index 43a7cbd4ae9..4f4176a77ac 100644
--- a/sys/kern/vfs_subr.c
+++ b/sys/kern/vfs_subr.c
@@ -966,6 +966,7 @@ vflush_vnode(struct vnode *vp, void *arg)
vprint("vflush: busy vnode", vp);
#endif
va->busy++;
+ panic("vflush_vnode: mark busy");
return (0);
}
I think some vnodes are still remaining while `umount /mnt`.
So, the kernel returns EBUSY.
It's right to kernel behavior and user land should handle this case.
Doing `umount /mnt` just after `fsck -p` in disrib/miniroot/install.sub.
```
3264# Create a skeletal /etc/fstab which is usable for the upgrade process.
3265munge_fstab
3266
3267# fsck -p non-root filesystems in /etc/fstab.
3268check_fs
3269
3270# Mount filesystems in /etc/fstab.
3272umount /mnt || { echo "Can't umount $ROOTDEV!"; exit; }
3273mount_fs
```
Is it necessary that /mnt is mounted while `check_fs` function?
The target disk information is already read from /mnt/etc/fstab in
`munge_fstab` function. `check_fs` uses the merged fstab in /tmp.
Just `umount /mnt` before `check_fs` can get avoid this error.
Is the following patch OK?
```
diff --git a/distrib/miniroot/install.sub b/distrib/miniroot/install.sub
old mode 100644
new mode 100755
index 16d3b6e3420..cf7e15c9754
--- a/distrib/miniroot/install.sub
+++ b/distrib/miniroot/install.sub
@@ -3243,11 +3243,12 @@ do_upgrade() {
# Create a skeletal /etc/fstab which is usable for the upgrade process.
munge_fstab
+ umount /mnt || { echo "Can't umount $ROOTDEV!"; exit; }
+
# fsck -p non-root filesystems in /etc/fstab.
check_fs
# Mount filesystems in /etc/fstab.
- umount /mnt || { echo "Can't umount $ROOTDEV!"; exit; }
mount_fs
rm -f /mnt/bsd.upgrade /mnt/auto_upgrade.conf
```
--
Yuichiro NAITO (naito.yuich...@gmail.com)
--
Yuichiro NAITO (naito.yuich...@gmail.com)
Re: bsd.upgrade fails `umount /mnt` with a single partition disk.
Doesn't this suggest a disk driver failed to perform/complete a write?
Not right at that moment but perhaps in the recent past?
Yuichiro NAITO wrote:
> bsd.upgrade fails and shows following messages with a single partition disk.
>
> ```
> Force checking of clean non-root filesystems? [no] no
> umount: /mnt: Device busy
> Can't umount sd0a!
> ```
>
> sd0 has following partitions.
>
> ```
> #size offset fstype [fsize bsize cpg]
> a: 37752672 64 4.2bsd 2048 16384 12959 # /
> b: 4176900 37752750swap# none
> c: 419430400 unused
> ```
>
> I don't want to say any thing about disk partitioning policy.
> I just want to improve bsd.upgrade more stable.
>
> This error happens in a specific environment.
> In my cases, OpenBSD on FreeBSD bhyve in Intel Core i7-6700 box caused
> this error. No other environments (that I have) reproduce it.
>
> In my investigation, the following patch caused panic in the bhyve
> environment.
>
> diff --git a/sys/kern/vfs_subr.c b/sys/kern/vfs_subr.c
> index 43a7cbd4ae9..4f4176a77ac 100644
> --- a/sys/kern/vfs_subr.c
> +++ b/sys/kern/vfs_subr.c
> @@ -966,6 +966,7 @@ vflush_vnode(struct vnode *vp, void *arg)
> vprint("vflush: busy vnode", vp);
> #endif
> va->busy++;
> + panic("vflush_vnode: mark busy");
> return (0);
> }
>
> I think some vnodes are still remaining while `umount /mnt`.
> So, the kernel returns EBUSY.
> It's right to kernel behavior and user land should handle this case.
>
> Doing `umount /mnt` just after `fsck -p` in disrib/miniroot/install.sub.
>
> ```
> 3264 # Create a skeletal /etc/fstab which is usable for the upgrade process.
> 3265 munge_fstab
> 3266
> 3267 # fsck -p non-root filesystems in /etc/fstab.
> 3268 check_fs
> 3269
> 3270 # Mount filesystems in /etc/fstab.
> 3272 umount /mnt || { echo "Can't umount $ROOTDEV!"; exit; }
> 3273 mount_fs
> ```
>
> Is it necessary that /mnt is mounted while `check_fs` function?
> The target disk information is already read from /mnt/etc/fstab in
> `munge_fstab` function. `check_fs` uses the merged fstab in /tmp.
>
> Just `umount /mnt` before `check_fs` can get avoid this error.
> Is the following patch OK?
>
> ```
> diff --git a/distrib/miniroot/install.sub b/distrib/miniroot/install.sub
> old mode 100644
> new mode 100755
> index 16d3b6e3420..cf7e15c9754
> --- a/distrib/miniroot/install.sub
> +++ b/distrib/miniroot/install.sub
> @@ -3243,11 +3243,12 @@ do_upgrade() {
> # Create a skeletal /etc/fstab which is usable for the upgrade process.
> munge_fstab
>
> + umount /mnt || { echo "Can't umount $ROOTDEV!"; exit; }
> +
> # fsck -p non-root filesystems in /etc/fstab.
> check_fs
>
> # Mount filesystems in /etc/fstab.
> - umount /mnt || { echo "Can't umount $ROOTDEV!"; exit; }
> mount_fs
>
> rm -f /mnt/bsd.upgrade /mnt/auto_upgrade.conf
> ```
>
> --
> Yuichiro NAITO (naito.yuich...@gmail.com)
>
bsd.upgrade fails `umount /mnt` with a single partition disk.
bsd.upgrade fails and shows following messages with a single partition disk.
```
Force checking of clean non-root filesystems? [no] no
umount: /mnt: Device busy
Can't umount sd0a!
```
sd0 has following partitions.
```
#size offset fstype [fsize bsize cpg]
a: 37752672 64 4.2bsd 2048 16384 12959 # /
b: 4176900 37752750swap# none
c: 419430400 unused
```
I don't want to say any thing about disk partitioning policy.
I just want to improve bsd.upgrade more stable.
This error happens in a specific environment.
In my cases, OpenBSD on FreeBSD bhyve in Intel Core i7-6700 box caused
this error. No other environments (that I have) reproduce it.
In my investigation, the following patch caused panic in the bhyve
environment.
diff --git a/sys/kern/vfs_subr.c b/sys/kern/vfs_subr.c
index 43a7cbd4ae9..4f4176a77ac 100644
--- a/sys/kern/vfs_subr.c
+++ b/sys/kern/vfs_subr.c
@@ -966,6 +966,7 @@ vflush_vnode(struct vnode *vp, void *arg)
vprint("vflush: busy vnode", vp);
#endif
va->busy++;
+ panic("vflush_vnode: mark busy");
return (0);
}
I think some vnodes are still remaining while `umount /mnt`.
So, the kernel returns EBUSY.
It's right to kernel behavior and user land should handle this case.
Doing `umount /mnt` just after `fsck -p` in disrib/miniroot/install.sub.
```
3264# Create a skeletal /etc/fstab which is usable for the upgrade process.
3265munge_fstab
3266
3267# fsck -p non-root filesystems in /etc/fstab.
3268check_fs
3269
3270# Mount filesystems in /etc/fstab.
3272umount /mnt || { echo "Can't umount $ROOTDEV!"; exit; }
3273mount_fs
```
Is it necessary that /mnt is mounted while `check_fs` function?
The target disk information is already read from /mnt/etc/fstab in
`munge_fstab` function. `check_fs` uses the merged fstab in /tmp.
Just `umount /mnt` before `check_fs` can get avoid this error.
Is the following patch OK?
```
diff --git a/distrib/miniroot/install.sub b/distrib/miniroot/install.sub
old mode 100644
new mode 100755
index 16d3b6e3420..cf7e15c9754
--- a/distrib/miniroot/install.sub
+++ b/distrib/miniroot/install.sub
@@ -3243,11 +3243,12 @@ do_upgrade() {
# Create a skeletal /etc/fstab which is usable for the upgrade process.
munge_fstab
+ umount /mnt || { echo "Can't umount $ROOTDEV!"; exit; }
+
# fsck -p non-root filesystems in /etc/fstab.
check_fs
# Mount filesystems in /etc/fstab.
- umount /mnt || { echo "Can't umount $ROOTDEV!"; exit; }
mount_fs
rm -f /mnt/bsd.upgrade /mnt/auto_upgrade.conf
```
--
Yuichiro NAITO (naito.yuich...@gmail.com)
Re: armv7 and arm64 media: fail on missing packages
This change is wrong, because existance of a file is unsatisfactory --
it might be an OLD file. This will not update it.
Official builds do something else. And since official builds try to
not encode logic directly into the scripts, it is not documented.
Having the builds fail in this way would suck.
So, no.
Klemens Nanni wrote:
> I built arm64 media on a new machine and forgot to install firmware
> from packages.
>
> It took me some digging to find out which packages these were, plus it
> failed in the middle of the build rather than up-front.
>
> While here, I noticed that arm64 does not use the "dtb" package like
> armv7 does, but it still defines an unused variable.
>
> This makes `make obj' run and not warn but `make' in e.g. the ramdisk
> directory will immediately warn and not build anything.
>
> $ cd /usr/src/distrib
> $ make obj ; echo $?
> ...
> 0
> $ cd arm64/ramdisk
> $ doas make
> Run "pkg_add u-boot-aarch64 raspberrypi-firmware"
> *** Error 1 in /usr/src/distrib/arm64/ramdisk (Makefile:46 'all':
> @false)
> $ doas pkg_add u-boot-aarch64 raspberrypi-firmware
> u-boot-aarch64-2021.10p1: ok
> raspberrypi-firmware-1.20210527: ok
> $ doas make ; echo $?
> ...
> 0
>
>
> Feedback? Objections? OK?
>
>
> diff 08275eee86493afb82b5297b2f958fa9eeaedf41 /usr/src
> blob - 68c30398cea3fff2184278e14d0c9fbea2154938
> file + distrib/arm64/iso/Makefile
> --- distrib/arm64/iso/Makefile
> +++ distrib/arm64/iso/Makefile
> @@ -24,7 +24,6 @@ FFSSTART!= expr ${MSDOSSTART} + ${MSDOSSIZE}
> NEWFS_ARGS_msdos=-L boot -c1 -F16
> MOUNT_ARGS_msdos=-o-l
>
> -PDTB=/usr/local/share/dtb/arm64
> PUBOOT= /usr/local/share/u-boot
> PRPI=/usr/local/share/raspberrypi-firmware/boot
>
> @@ -45,6 +44,12 @@ PIFILES=\
> PIDTBO=\
> disable-bt.dtbo
>
> +.if !exists(${PUBOOT}/rpi_arm64) || !exists(${PRPI})
> +all:
> + @echo 'Run "pkg_add u-boot-aarch64 raspberrypi-firmware"'
> + @false
> +.endif
> +
> all: ${FS}
>
> ${FS}: ${BASE} ${XBASE}
> blob - 5dda462c0f42314e7bb21d264e814903440baa02
> file + distrib/arm64/ramdisk/Makefile
> --- distrib/arm64/ramdisk/Makefile
> +++ distrib/arm64/ramdisk/Makefile
> @@ -14,7 +14,6 @@ FFSSTART!= expr ${MSDOSSTART} + ${MSDOSSIZE}
> NEWFS_ARGS_msdos=-L boot -c1 -F16
> MOUNT_ARGS_msdos=-o-l
>
> -PDTB=/usr/local/share/dtb/arm64
> PUBOOT= /usr/local/share/u-boot
> PRPI=/usr/local/share/raspberrypi-firmware/boot
>
> @@ -41,6 +40,12 @@ PIFILES=\
> PIDTBO=\
> disable-bt.dtbo
>
> +.if !exists(${PUBOOT}/rpi_arm64) || !exists(${PRPI})
> +all:
> + @echo 'Run "pkg_add u-boot-aarch64 raspberrypi-firmware"'
> + @false
> +.endif
> +
> all: ${FS}
>
> ${FS}: bsd.rd
> blob - bb00f4360a80fa3e93e426e67eaa635a958d0168
> file + distrib/armv7/miniroot/Makefile.inc
> --- distrib/armv7/miniroot/Makefile.inc
> +++ distrib/armv7/miniroot/Makefile.inc
> @@ -14,6 +14,12 @@ FFSSTART!= expr ${MSDOSSTART} + ${MSDOSSIZE}
> PDTB=/usr/local/share/dtb/arm
> PUBOOT= /usr/local/share/u-boot
>
> +.if !exists(${PDTB}) || !exists(${PUBOOT}/wandboard)
> +all:
> + @echo 'Run "pkg_add dtb u-boot-arm"'
> + @false
> +.endif
> +
> all: ${FS}
>
> ${FS}: bsd.rd
>
Re: regress/rpki-client: test openssl in regress target only
> rpki-client seems to be the one-off under regress/ in this regard. Maybe. I wish I had a better idea than this Index: Makefile === RCS file: /cvs/src/regress/usr.sbin/rpki-client/Makefile,v retrieving revision 1.10 diff -u -p -r1.10 Makefile --- Makefile9 Nov 2020 15:49:48 - 1.10 +++ Makefile7 Nov 2021 23:59:10 - @@ -1,7 +1,8 @@ # $OpenBSD: Makefile,v 1.10 2020/11/09 15:49:48 tb Exp $ SUBDIR += libressl -.if exists(/usr/local/bin/eopenssl11) +.if exists(/usr/local/bin/eopenssl11) || \ + make(obj) || make(clean) || make(cleandir) SUBDIR += openssl11 .else .END:
Re: regress/rpki-client: test openssl in regress target only
On Sun, Nov 07, 2021 at 11:33:29PM +0100, Theo Buehler wrote: > On Sun, Nov 07, 2021 at 10:28:22PM +, Klemens Nanni wrote: > > On Sun, Nov 07, 2021 at 11:16:57PM +0100, Theo Buehler wrote: > > > On Sun, Nov 07, 2021 at 10:13:44PM +, Klemens Nanni wrote: > > > > Spotted in `make obj' from /usr/src: > > > > > > > > ===> regress/usr.sbin/rpki-client/libressl > > > > /usr/src/regress/usr.sbin/rpki-client/libressl/obj -> > > > > /usr/obj/regress/usr.sbin/rpki-client/libressl > > > > Run "pkg_add openssl--%1.1" to run tests against OpenSSL 1.1 > > > > SKIPPED > > > > ===> regress/usr.sbin/snmpd > > > > > > > > OK? > > > > > > That won't print if you only type 'make' and don't OpenSSL installed. > > > > It does for me: > > > > $ cd /usr/src/regress/usr.sbin/rpki-client > > $ make > > Run "pkg_add openssl--%1.1" to run tests against OpenSSL 1.1 > > SKIPPED > > The point of putting it at the end is that it stands out. Fair point, although nothing but the symlink creation should happen during `make obj'. rpki-client seems to be the one-off under regress/ in this regard.
armv7 and arm64 media: fail on missing packages
I built arm64 media on a new machine and forgot to install firmware
from packages.
It took me some digging to find out which packages these were, plus it
failed in the middle of the build rather than up-front.
While here, I noticed that arm64 does not use the "dtb" package like
armv7 does, but it still defines an unused variable.
This makes `make obj' run and not warn but `make' in e.g. the ramdisk
directory will immediately warn and not build anything.
$ cd /usr/src/distrib
$ make obj ; echo $?
...
0
$ cd arm64/ramdisk
$ doas make
Run "pkg_add u-boot-aarch64 raspberrypi-firmware"
*** Error 1 in /usr/src/distrib/arm64/ramdisk (Makefile:46 'all':
@false)
$ doas pkg_add u-boot-aarch64 raspberrypi-firmware
u-boot-aarch64-2021.10p1: ok
raspberrypi-firmware-1.20210527: ok
$ doas make ; echo $?
...
0
Feedback? Objections? OK?
diff 08275eee86493afb82b5297b2f958fa9eeaedf41 /usr/src
blob - 68c30398cea3fff2184278e14d0c9fbea2154938
file + distrib/arm64/iso/Makefile
--- distrib/arm64/iso/Makefile
+++ distrib/arm64/iso/Makefile
@@ -24,7 +24,6 @@ FFSSTART!=expr ${MSDOSSTART} + ${MSDOSSIZE}
NEWFS_ARGS_msdos=-L boot -c1 -F16
MOUNT_ARGS_msdos=-o-l
-PDTB= /usr/local/share/dtb/arm64
PUBOOT=/usr/local/share/u-boot
PRPI= /usr/local/share/raspberrypi-firmware/boot
@@ -45,6 +44,12 @@ PIFILES=\
PIDTBO=\
disable-bt.dtbo
+.if !exists(${PUBOOT}/rpi_arm64) || !exists(${PRPI})
+all:
+ @echo 'Run "pkg_add u-boot-aarch64 raspberrypi-firmware"'
+ @false
+.endif
+
all: ${FS}
${FS}: ${BASE} ${XBASE}
blob - 5dda462c0f42314e7bb21d264e814903440baa02
file + distrib/arm64/ramdisk/Makefile
--- distrib/arm64/ramdisk/Makefile
+++ distrib/arm64/ramdisk/Makefile
@@ -14,7 +14,6 @@ FFSSTART!=expr ${MSDOSSTART} + ${MSDOSSIZE}
NEWFS_ARGS_msdos=-L boot -c1 -F16
MOUNT_ARGS_msdos=-o-l
-PDTB= /usr/local/share/dtb/arm64
PUBOOT=/usr/local/share/u-boot
PRPI= /usr/local/share/raspberrypi-firmware/boot
@@ -41,6 +40,12 @@ PIFILES=\
PIDTBO=\
disable-bt.dtbo
+.if !exists(${PUBOOT}/rpi_arm64) || !exists(${PRPI})
+all:
+ @echo 'Run "pkg_add u-boot-aarch64 raspberrypi-firmware"'
+ @false
+.endif
+
all: ${FS}
${FS}: bsd.rd
blob - bb00f4360a80fa3e93e426e67eaa635a958d0168
file + distrib/armv7/miniroot/Makefile.inc
--- distrib/armv7/miniroot/Makefile.inc
+++ distrib/armv7/miniroot/Makefile.inc
@@ -14,6 +14,12 @@ FFSSTART!= expr ${MSDOSSTART} + ${MSDOSSIZE}
PDTB= /usr/local/share/dtb/arm
PUBOOT=/usr/local/share/u-boot
+.if !exists(${PDTB}) || !exists(${PUBOOT}/wandboard)
+all:
+ @echo 'Run "pkg_add dtb u-boot-arm"'
+ @false
+.endif
+
all: ${FS}
${FS}: bsd.rd
Re: regress/rpki-client: test openssl in regress target only
On Sun, Nov 07, 2021 at 10:28:22PM +, Klemens Nanni wrote: > On Sun, Nov 07, 2021 at 11:16:57PM +0100, Theo Buehler wrote: > > On Sun, Nov 07, 2021 at 10:13:44PM +, Klemens Nanni wrote: > > > Spotted in `make obj' from /usr/src: > > > > > > ===> regress/usr.sbin/rpki-client/libressl > > > /usr/src/regress/usr.sbin/rpki-client/libressl/obj -> > > > /usr/obj/regress/usr.sbin/rpki-client/libressl > > > Run "pkg_add openssl--%1.1" to run tests against OpenSSL 1.1 > > > SKIPPED > > > ===> regress/usr.sbin/snmpd > > > > > > OK? > > > > That won't print if you only type 'make' and don't OpenSSL installed. > > It does for me: > > $ cd /usr/src/regress/usr.sbin/rpki-client > $ make > Run "pkg_add openssl--%1.1" to run tests against OpenSSL 1.1 > SKIPPED The point of putting it at the end is that it stands out.
Re: regress/rpki-client: test openssl in regress target only
On Sun, Nov 07, 2021 at 11:16:57PM +0100, Theo Buehler wrote: > On Sun, Nov 07, 2021 at 10:13:44PM +, Klemens Nanni wrote: > > Spotted in `make obj' from /usr/src: > > > > ===> regress/usr.sbin/rpki-client/libressl > > /usr/src/regress/usr.sbin/rpki-client/libressl/obj -> > > /usr/obj/regress/usr.sbin/rpki-client/libressl > > Run "pkg_add openssl--%1.1" to run tests against OpenSSL 1.1 > > SKIPPED > > ===> regress/usr.sbin/snmpd > > > > OK? > > That won't print if you only type 'make' and don't OpenSSL installed. It does for me: $ cd /usr/src/regress/usr.sbin/rpki-client $ make Run "pkg_add openssl--%1.1" to run tests against OpenSSL 1.1 SKIPPED ===> libressl cc -O2 -pipe -I/usr/src/regress/usr.sbin/rpki-client/libressl/.. -I/usr/src/regress/usr.sbin/rpki-client/libressl/../../../../usr.sbin/rpki-client -MD -MP -c /usr/src/regress/usr.sbin/rpki-client/libressl/../../../../usr.sbin/rpki-client/cert.c ... Adding to the regress target is what most (if not all) other regress tests seem to do, e.g. $ head /usr/src/regress/sys/netinet/pmtu/Makefile # $OpenBSD: Makefile,v 1.15 2020/12/30 21:40:33 kn Exp $ # The following ports must be installed: # # scapy powerful interactive packet manipulation in python .if ! exists(/usr/local/bin/scapy) regress: @echo Install scapy package to run this regress. @echo SKIPPED Am I missing something?
Re: regress/rpki-client: test openssl in regress target only
On Sun, Nov 07, 2021 at 10:13:44PM +, Klemens Nanni wrote: > Spotted in `make obj' from /usr/src: > > ===> regress/usr.sbin/rpki-client/libressl > /usr/src/regress/usr.sbin/rpki-client/libressl/obj -> > /usr/obj/regress/usr.sbin/rpki-client/libressl > Run "pkg_add openssl--%1.1" to run tests against OpenSSL 1.1 > SKIPPED > ===> regress/usr.sbin/snmpd > > OK? That won't print if you only type 'make' and don't OpenSSL installed.
regress/rpki-client: test openssl in regress target only
Spotted in `make obj' from /usr/src: ===> regress/usr.sbin/rpki-client/libressl /usr/src/regress/usr.sbin/rpki-client/libressl/obj -> /usr/obj/regress/usr.sbin/rpki-client/libressl Run "pkg_add openssl--%1.1" to run tests against OpenSSL 1.1 SKIPPED ===> regress/usr.sbin/snmpd OK? Index: Makefile === RCS file: /cvs/src/regress/usr.sbin/rpki-client/Makefile,v retrieving revision 1.10 diff -u -p -r1.10 Makefile --- Makefile9 Nov 2020 15:49:48 - 1.10 +++ Makefile7 Nov 2021 22:11:52 - @@ -4,7 +4,7 @@ SUBDIR += libressl .if exists(/usr/local/bin/eopenssl11) SUBDIR += openssl11 .else -.END: +regress: @echo 'Run "pkg_add openssl--%1.1" to run tests against OpenSSL 1.1' @echo SKIPPED .endif
Re: [PATCH] Change maximum size of /usr/src to 3G for autoinstall
On Sun, Nov 07, 2021 at 07:44:57PM +0300, Mikhail wrote: > On Sat, Oct 30, 2021 at 11:39:54AM +0300, Mikhail wrote: > > On Sun, Oct 24, 2021 at 02:17:25PM +0300, Mikhail wrote: > > > On Sun, Oct 24, 2021 at 11:32:26AM +0100, Stuart Henderson wrote: > > > > The minimum needs to go up too, a cvs checkout is 1.3G already. > > > > > > > > (Not that I use auto defaults without changes anyway, they don't > > > > work too well for ports dev..) > > > > > > Changed minimum to 1.5G. > > > > Weekly friendly ping. Comments, objections, feedback? > > > > Maybe someone has another opinion on max (3G) and min (1.5G) values? > > > > I think bumping them makes sense, since more and more users use git. > > Last ping, maybe interested committer appeared on this week. > I'll take a look. Remind me if I forget. Sorry for the delay. -Otto
Re: [PATCH] Change maximum size of /usr/src to 3G for autoinstall
On Sat, Oct 30, 2021 at 11:39:54AM +0300, Mikhail wrote: > On Sun, Oct 24, 2021 at 02:17:25PM +0300, Mikhail wrote: > > On Sun, Oct 24, 2021 at 11:32:26AM +0100, Stuart Henderson wrote: > > > The minimum needs to go up too, a cvs checkout is 1.3G already. > > > > > > (Not that I use auto defaults without changes anyway, they don't > > > work too well for ports dev..) > > > > Changed minimum to 1.5G. > > Weekly friendly ping. Comments, objections, feedback? > > Maybe someone has another opinion on max (3G) and min (1.5G) values? > > I think bumping them makes sense, since more and more users use git. Last ping, maybe interested committer appeared on this week.
Re: poll/select: Lazy removal of knotes
On Sat, Nov 06, 2021 at 06:23:27PM +0100, Martin Pieuchot wrote:
> On 06/11/21(Sat) 15:53, Visa Hankala wrote:
> > On Fri, Nov 05, 2021 at 10:04:50AM +0100, Martin Pieuchot wrote:
> > > New poll/select(2) implementation convert 'struct pollfd' and 'fdset' to
> > > knotes (kqueue event descriptors) then pass them to the kqueue subsystem.
> > > A knote is allocated, with kqueue_register(), for every read, write and
> > > except condition watched on a given FD. That means at most 3 allocations
> > > might be necessary per FD.
> > >
> > > The diff below reduce the overhead of per-syscall allocation/free of those
> > > descriptors by leaving those which didn't trigger on the kqueue across
> > > syscall. Leaving knotes on the kqueue allows kqueue_register() to re-use
> > > existing descriptor instead of re-allocating a new one.
> > >
> > > With this knotes are now lazily removed. The mechanism uses a serial
> > > number which is incremented for every syscall that indicates if a knote
> > > sitting in the kqueue is still valid or should be freed.
> > >
> > > Note that performance improvements might not be visible with this diff
> > > alone because kqueue_register() still pre-allocate a descriptor then drop
> > > it.
> > >
> > > visa@ already pointed out that the lazy removal logic could be integrated
> > > in kqueue_scan() which would reduce the complexity of those two syscalls.
> > > I'm arguing for doing this in a next step in-tree.
> >
> > I think it would make more sense to add the removal logic to the scan
> > function first as doing so would keep the code modifications more
> > logical and simpler. This would also avoid the need to go through
> > a temporary removal approach.
>
> I totally support your effort and your design however I don't have the
> time to do another round of test/debugging. So please, can you take
> care of doing these cleanups afterward? If not, please send a full diff
> and take over this feature, it's too much effort for me to work out of
> tree.
Here is a full diff that does lazy removal in kqueue_scan().
The implementation clears all kqpoll knotes when p_kq_serial is about
to wrap. This keeps the code relatively simple because any knote with
a serial less than p_kq_serial is expired.
With current speeds of hardware, serial wraparound should not happen
when p_kq_serial is 64-bits wide. However, long-running and busy
processes might experience wraparounds on 32-bit hardware.
p_kq_serial is still initialized with a 32-bit random number. It is not
clear to me if this gives any clear benefit over a constant initializer.
With native kqueue, kev->udata values are user-controlled. With poll and
select, the user cannot directly manipulate the knotes, but the udata
values are observable through ktrace. Going for 64-bit initial random
values on 64-bit systems is an option as well, though at the cost of
increased noise in ktrace output.
Index: kern/kern_event.c
===
RCS file: src/sys/kern/kern_event.c,v
retrieving revision 1.170
diff -u -p -r1.170 kern_event.c
--- kern/kern_event.c 6 Nov 2021 05:48:47 - 1.170
+++ kern/kern_event.c 7 Nov 2021 12:31:12 -
@@ -73,6 +73,7 @@ void kqueue_terminate(struct proc *p, st
void KQREF(struct kqueue *);
void KQRELE(struct kqueue *);
+void kqueue_purge(struct proc *, struct kqueue *);
intkqueue_sleep(struct kqueue *, struct timespec *);
intkqueue_read(struct file *, struct uio *, int);
@@ -763,29 +764,55 @@ filter_process(struct knote *kn, struct
return (active);
}
+/*
+ * Initialize the current thread for poll/select system call.
+ * num indicates the number of serials that the system call may utilize.
+ * After this function, the valid range of serials is
+ * p_kq_serial <= x < p_kq_serial + num.
+ */
void
-kqpoll_init(void)
+kqpoll_init(unsigned int num)
{
struct proc *p = curproc;
struct filedesc *fdp;
- if (p->p_kq != NULL) {
- /*
-* Discard any badfd knotes that have been enqueued after
-* previous scan.
-* This prevents them from accumulating in case
-* scan does not make progress for some reason.
-*/
- kqpoll_dequeue(p, 0);
- return;
+ if (p->p_kq == NULL) {
+ p->p_kq = kqueue_alloc(p->p_fd);
+ p->p_kq_serial = arc4random();
+ fdp = p->p_fd;
+ fdplock(fdp);
+ LIST_INSERT_HEAD(>fd_kqlist, p->p_kq, kq_next);
+ fdpunlock(fdp);
}
- p->p_kq = kqueue_alloc(p->p_fd);
- p->p_kq_serial = arc4random();
- fdp = p->p_fd;
- fdplock(fdp);
- LIST_INSERT_HEAD(>fd_kqlist, p->p_kq, kq_next);
- fdpunlock(fdp);
+ if (p->p_kq_serial + num < p->p_kq_serial) {
+ /* Serial is about to wrap. Clear all attached knotes. */
+
net.inet6.icmp6.nd6_debug and RDNSS
net.inet6.icmp6.nd6_debug is fairly noisy if you advertise nameservers, OK to silence those warnings? Nov 7 00:45:34 bamboo /bsd: nd6_options: unsupported option 25 - option ignored Nov 7 04:26:22 bamboo /bsd: nd6_options: unsupported option 25 - option ignored Nov 7 04:26:26 bamboo /bsd: nd6_options: unsupported option 25 - option ignored Nov 7 04:31:10 bamboo /bsd: nd6_options: unsupported option 25 - option ignored Nov 7 06:04:41 bamboo /bsd: nd6_options: unsupported option 25 - option ignored Nov 7 08:57:05 bamboo /bsd: nd6_options: unsupported option 25 - option ignored Nov 7 10:48:36 bamboo /bsd: nd6_options: unsupported option 25 - option ignored Nov 7 12:02:51 bamboo /bsd: nd6_options: unsupported option 25 - option ignored Nov 7 12:08:21 bamboo /bsd: nd6_options: unsupported option 25 - option ignored Nov 7 12:09:57 bamboo /bsd: nd6_options: unsupported option 25 - option ignored Nov 7 12:11:41 bamboo /bsd: nd6_options: unsupported option 25 - option ignored Nov 7 12:15:48 bamboo /bsd: nd6_options: unsupported option 25 - option ignored Index: netinet6/nd6.c === RCS file: /cvs/src/sys/netinet6/nd6.c,v retrieving revision 1.235 diff -u -p -r1.235 nd6.c --- netinet6/nd6.c 8 Mar 2021 16:49:07 - 1.235 +++ netinet6/nd6.c 7 Nov 2021 12:24:03 - @@ -271,6 +271,10 @@ nd6_options(union nd_opts *ndopts) ndopts->nd_opts_pi_end = (struct nd_opt_prefix_info *)nd_opt; break; + case ND_OPT_DNSSL: + case ND_OPT_RDNSS: + /* Don't warn */ + break; default: /* * Unknown options must be silently ignored,
