Re: rc.subr - allow setting daemon start directory
On Thu, May 05, 2022 at 04:49:10PM -0600, Aaron Bieber wrote: > > > On Thu, May 5, 2022, at 4:46 PM, Antoine Jacoutot wrote: > > Can you elaborate? > > Do they need to start from a specific directory or from a directory > > they have write access to? > > Because we could cd /tmp unconditionally > > > > From a specific directory. I can’t think of which ones off the top of my > head, but for sure I have some personal rc scripts that need it for nodejs > things. Ok. Let me think about it. -- Antoine
Re: rc.subr - allow setting daemon start directory
On Thu, May 5, 2022, at 4:46 PM, Antoine Jacoutot wrote:
> Can you elaborate?
> Do they need to start from a specific directory or from a directory
> they have write access to?
> Because we could cd /tmp unconditionally
>
>From a specific directory. I can’t think of which ones off the top of my head,
>but for sure I have some personal rc scripts that need it for nodejs things.
> —
> Antoine
>
>> On 6 May 2022, at 00:43, Aaron Bieber wrote:
>>
>>
>>
>>> On Thu, May 5, 2022, at 3:24 PM, Antoine Jacoutot wrote:
>>> Not a fan adding a knob for this.
>>> I don’t remember why amd needs to start from /etc/amd.
>>>
>>> —
>>> Antoine
>>
>> There are a number of ports that would benefit from this as well.
>>
>>>
> On 5 May 2022, at 23:12, aisha wrote:
Hi,
I've attached a patch which allows setting the daemon start directory
using the variable `daemon_startdir`.
I think this is useful in the cases where it is desirable to change the
start directory before running the daemon, e.g. with /etc/rc.d/amd .
A major benefit of this is that this allows setting the start directory
manually while also allowing the use of daemon_logger, which gets lost in
case someone writes their own rc_start (again, amd is an example).
This is not always possible using the rcexec which uses `su -l` as the
daemon might be running as root (or if user has home directory to
/nonexistent).
Thanks,
Aisha
diff --git a/etc/rc.d/amd b/etc/rc.d/amd
index 3bfe9dc555e..5c1b8a897ed 100644
--- a/etc/rc.d/amd
+++ b/etc/rc.d/amd
@@ -3,6 +3,7 @@
# $OpenBSD: amd,v 1.9 2018/01/11 21:09:26 rpe Exp $
daemon="/usr/sbin/amd"
+daemon_startdir="/etc/amd"
. /etc/rc.d/rc.subr
@@ -15,8 +16,4 @@ rc_pre() {
daemon_flags="${daemon_flags} $(print -rn -- $(< ${amd_master}))"
}
-rc_start() {
-${rcexec} "cd /etc/amd; ${daemon} ${daemon_flags}"
-}
-
rc_cmd $1
diff --git a/etc/rc.d/rc.subr b/etc/rc.d/rc.subr
index ed2adb6515e..035f8d9b172 100644
--- a/etc/rc.d/rc.subr
+++ b/etc/rc.d/rc.subr
@@ -117,6 +117,7 @@ daemon_class=${daemon_class}
daemon_flags=${daemon_flags}
daemon_logger=${daemon_logger}
daemon_rtable=${daemon_rtable}
+daemon_startdir=${daemon_startdir}
daemon_timeout=${daemon_timeout}
daemon_user=${daemon_user}
pexp=${pexp}
@@ -160,7 +161,7 @@ _rc_wait_for_start() {
}
rc_start() {
-${rcexec} "${daemon_logger:+set -o pipefail; }${daemon}
${daemon_flags}${daemon_logger:+ 2>&1 |
+${rcexec} "${daemon_logger:+set -o pipefail; }${daemon_startdir:+cd
${daemon_startdir}; }${daemon} ${daemon_flags}${daemon_logger:+ 2>&1 |
logger -ip ${daemon_logger} -t ${_name}}"
}
@@ -312,6 +313,7 @@ rc_stop_signal=${rc_stop_signal:=TERM}
eval _rcflags=\${${_name}_flags}
eval _rclogger=\${${_name}_logger}
eval _rcrtable=\${${_name}_rtable}
+eval _rcstartdir=\${${_name}_startdir}
eval _rctimeout=\${${_name}_timeout}
eval _rcuser=\${${_name}_user}
@@ -329,6 +331,7 @@ getcap -f /etc/login.conf.d/${_name}:/etc/login.conf
${_name} 1>/dev/null 2>&1 &
[ -n "${_rcflags}" ] && daemon_flags=${_rcflags}
[ -n "${_rclogger}" ] && daemon_logger=${_rclogger}
[ -n "${_rcrtable}" ] && daemon_rtable=${_rcrtable}
+[ -n "${_rcstartdir}" ] && daemon_startdir=${_rcstartdir}
[ -n "${_rctimeout}" ] && daemon_timeout=${_rctimeout}
[ -n "${_rcuser}" ] && daemon_user=${_rcuser}
>>
Re: rc.subr - allow setting daemon start directory
Can you elaborate?
Do they need to start from a specific directory or from a directory they have
write access to?
Because we could cd /tmp unconditionally
—
Antoine
> On 6 May 2022, at 00:43, Aaron Bieber wrote:
>
>
>
>> On Thu, May 5, 2022, at 3:24 PM, Antoine Jacoutot wrote:
>> Not a fan adding a knob for this.
>> I don’t remember why amd needs to start from /etc/amd.
>>
>> —
>> Antoine
>
> There are a number of ports that would benefit from this as well.
>
>>
On 5 May 2022, at 23:12, aisha wrote:
>>>
>>> Hi,
>>> I've attached a patch which allows setting the daemon start directory using
>>> the variable `daemon_startdir`.
>>> I think this is useful in the cases where it is desirable to change the
>>> start directory before running the daemon, e.g. with /etc/rc.d/amd .
>>> A major benefit of this is that this allows setting the start directory
>>> manually while also allowing the use of daemon_logger, which gets lost in
>>> case someone writes their own rc_start (again, amd is an example).
>>>
>>> This is not always possible using the rcexec which uses `su -l` as the
>>> daemon might be running as root (or if user has home directory to
>>> /nonexistent).
>>>
>>> Thanks,
>>> Aisha
>>>
>>> diff --git a/etc/rc.d/amd b/etc/rc.d/amd
>>> index 3bfe9dc555e..5c1b8a897ed 100644
>>> --- a/etc/rc.d/amd
>>> +++ b/etc/rc.d/amd
>>> @@ -3,6 +3,7 @@
>>> # $OpenBSD: amd,v 1.9 2018/01/11 21:09:26 rpe Exp $
>>>
>>> daemon="/usr/sbin/amd"
>>> +daemon_startdir="/etc/amd"
>>>
>>> . /etc/rc.d/rc.subr
>>>
>>> @@ -15,8 +16,4 @@ rc_pre() {
>>> daemon_flags="${daemon_flags} $(print -rn -- $(< ${amd_master}))"
>>> }
>>>
>>> -rc_start() {
>>> -${rcexec} "cd /etc/amd; ${daemon} ${daemon_flags}"
>>> -}
>>> -
>>> rc_cmd $1
>>> diff --git a/etc/rc.d/rc.subr b/etc/rc.d/rc.subr
>>> index ed2adb6515e..035f8d9b172 100644
>>> --- a/etc/rc.d/rc.subr
>>> +++ b/etc/rc.d/rc.subr
>>> @@ -117,6 +117,7 @@ daemon_class=${daemon_class}
>>> daemon_flags=${daemon_flags}
>>> daemon_logger=${daemon_logger}
>>> daemon_rtable=${daemon_rtable}
>>> +daemon_startdir=${daemon_startdir}
>>> daemon_timeout=${daemon_timeout}
>>> daemon_user=${daemon_user}
>>> pexp=${pexp}
>>> @@ -160,7 +161,7 @@ _rc_wait_for_start() {
>>> }
>>>
>>> rc_start() {
>>> -${rcexec} "${daemon_logger:+set -o pipefail; }${daemon}
>>> ${daemon_flags}${daemon_logger:+ 2>&1 |
>>> +${rcexec} "${daemon_logger:+set -o pipefail; }${daemon_startdir:+cd
>>> ${daemon_startdir}; }${daemon} ${daemon_flags}${daemon_logger:+ 2>&1 |
>>> logger -ip ${daemon_logger} -t ${_name}}"
>>> }
>>>
>>> @@ -312,6 +313,7 @@ rc_stop_signal=${rc_stop_signal:=TERM}
>>> eval _rcflags=\${${_name}_flags}
>>> eval _rclogger=\${${_name}_logger}
>>> eval _rcrtable=\${${_name}_rtable}
>>> +eval _rcstartdir=\${${_name}_startdir}
>>> eval _rctimeout=\${${_name}_timeout}
>>> eval _rcuser=\${${_name}_user}
>>>
>>> @@ -329,6 +331,7 @@ getcap -f /etc/login.conf.d/${_name}:/etc/login.conf
>>> ${_name} 1>/dev/null 2>&1 &
>>> [ -n "${_rcflags}" ] && daemon_flags=${_rcflags}
>>> [ -n "${_rclogger}" ] && daemon_logger=${_rclogger}
>>> [ -n "${_rcrtable}" ] && daemon_rtable=${_rcrtable}
>>> +[ -n "${_rcstartdir}" ] && daemon_startdir=${_rcstartdir}
>>> [ -n "${_rctimeout}" ] && daemon_timeout=${_rctimeout}
>>> [ -n "${_rcuser}" ] && daemon_user=${_rcuser}
>>>
>>>
>
Re: rc.subr - allow setting daemon start directory
On Thu, May 5, 2022, at 3:24 PM, Antoine Jacoutot wrote:
> Not a fan adding a knob for this.
> I don’t remember why amd needs to start from /etc/amd.
>
> —
> Antoine
There are a number of ports that would benefit from this as well.
>
>> On 5 May 2022, at 23:12, aisha wrote:
>>
>> Hi,
>> I've attached a patch which allows setting the daemon start directory using
>> the variable `daemon_startdir`.
>> I think this is useful in the cases where it is desirable to change the
>> start directory before running the daemon, e.g. with /etc/rc.d/amd .
>> A major benefit of this is that this allows setting the start directory
>> manually while also allowing the use of daemon_logger, which gets lost in
>> case someone writes their own rc_start (again, amd is an example).
>>
>> This is not always possible using the rcexec which uses `su -l` as the
>> daemon might be running as root (or if user has home directory to
>> /nonexistent).
>>
>> Thanks,
>> Aisha
>>
>> diff --git a/etc/rc.d/amd b/etc/rc.d/amd
>> index 3bfe9dc555e..5c1b8a897ed 100644
>> --- a/etc/rc.d/amd
>> +++ b/etc/rc.d/amd
>> @@ -3,6 +3,7 @@
>> # $OpenBSD: amd,v 1.9 2018/01/11 21:09:26 rpe Exp $
>>
>> daemon="/usr/sbin/amd"
>> +daemon_startdir="/etc/amd"
>>
>> . /etc/rc.d/rc.subr
>>
>> @@ -15,8 +16,4 @@ rc_pre() {
>>daemon_flags="${daemon_flags} $(print -rn -- $(< ${amd_master}))"
>> }
>>
>> -rc_start() {
>> -${rcexec} "cd /etc/amd; ${daemon} ${daemon_flags}"
>> -}
>> -
>> rc_cmd $1
>> diff --git a/etc/rc.d/rc.subr b/etc/rc.d/rc.subr
>> index ed2adb6515e..035f8d9b172 100644
>> --- a/etc/rc.d/rc.subr
>> +++ b/etc/rc.d/rc.subr
>> @@ -117,6 +117,7 @@ daemon_class=${daemon_class}
>> daemon_flags=${daemon_flags}
>> daemon_logger=${daemon_logger}
>> daemon_rtable=${daemon_rtable}
>> +daemon_startdir=${daemon_startdir}
>> daemon_timeout=${daemon_timeout}
>> daemon_user=${daemon_user}
>> pexp=${pexp}
>> @@ -160,7 +161,7 @@ _rc_wait_for_start() {
>> }
>>
>> rc_start() {
>> -${rcexec} "${daemon_logger:+set -o pipefail; }${daemon}
>> ${daemon_flags}${daemon_logger:+ 2>&1 |
>> +${rcexec} "${daemon_logger:+set -o pipefail; }${daemon_startdir:+cd
>> ${daemon_startdir}; }${daemon} ${daemon_flags}${daemon_logger:+ 2>&1 |
>>logger -ip ${daemon_logger} -t ${_name}}"
>> }
>>
>> @@ -312,6 +313,7 @@ rc_stop_signal=${rc_stop_signal:=TERM}
>> eval _rcflags=\${${_name}_flags}
>> eval _rclogger=\${${_name}_logger}
>> eval _rcrtable=\${${_name}_rtable}
>> +eval _rcstartdir=\${${_name}_startdir}
>> eval _rctimeout=\${${_name}_timeout}
>> eval _rcuser=\${${_name}_user}
>>
>> @@ -329,6 +331,7 @@ getcap -f /etc/login.conf.d/${_name}:/etc/login.conf
>> ${_name} 1>/dev/null 2>&1 &
>> [ -n "${_rcflags}" ] && daemon_flags=${_rcflags}
>> [ -n "${_rclogger}" ] && daemon_logger=${_rclogger}
>> [ -n "${_rcrtable}" ] && daemon_rtable=${_rcrtable}
>> +[ -n "${_rcstartdir}" ] && daemon_startdir=${_rcstartdir}
>> [ -n "${_rctimeout}" ] && daemon_timeout=${_rctimeout}
>> [ -n "${_rcuser}" ] && daemon_user=${_rcuser}
>>
>>
Re: rc.subr - allow setting daemon start directory
Not a fan adding a knob for this.
I don’t remember why amd needs to start from /etc/amd.
—
Antoine
> On 5 May 2022, at 23:12, aisha wrote:
>
> Hi,
> I've attached a patch which allows setting the daemon start directory using
> the variable `daemon_startdir`.
> I think this is useful in the cases where it is desirable to change the start
> directory before running the daemon, e.g. with /etc/rc.d/amd .
> A major benefit of this is that this allows setting the start directory
> manually while also allowing the use of daemon_logger, which gets lost in
> case someone writes their own rc_start (again, amd is an example).
>
> This is not always possible using the rcexec which uses `su -l` as the daemon
> might be running as root (or if user has home directory to /nonexistent).
>
> Thanks,
> Aisha
>
> diff --git a/etc/rc.d/amd b/etc/rc.d/amd
> index 3bfe9dc555e..5c1b8a897ed 100644
> --- a/etc/rc.d/amd
> +++ b/etc/rc.d/amd
> @@ -3,6 +3,7 @@
> # $OpenBSD: amd,v 1.9 2018/01/11 21:09:26 rpe Exp $
>
> daemon="/usr/sbin/amd"
> +daemon_startdir="/etc/amd"
>
> . /etc/rc.d/rc.subr
>
> @@ -15,8 +16,4 @@ rc_pre() {
>daemon_flags="${daemon_flags} $(print -rn -- $(< ${amd_master}))"
> }
>
> -rc_start() {
> -${rcexec} "cd /etc/amd; ${daemon} ${daemon_flags}"
> -}
> -
> rc_cmd $1
> diff --git a/etc/rc.d/rc.subr b/etc/rc.d/rc.subr
> index ed2adb6515e..035f8d9b172 100644
> --- a/etc/rc.d/rc.subr
> +++ b/etc/rc.d/rc.subr
> @@ -117,6 +117,7 @@ daemon_class=${daemon_class}
> daemon_flags=${daemon_flags}
> daemon_logger=${daemon_logger}
> daemon_rtable=${daemon_rtable}
> +daemon_startdir=${daemon_startdir}
> daemon_timeout=${daemon_timeout}
> daemon_user=${daemon_user}
> pexp=${pexp}
> @@ -160,7 +161,7 @@ _rc_wait_for_start() {
> }
>
> rc_start() {
> -${rcexec} "${daemon_logger:+set -o pipefail; }${daemon}
> ${daemon_flags}${daemon_logger:+ 2>&1 |
> +${rcexec} "${daemon_logger:+set -o pipefail; }${daemon_startdir:+cd
> ${daemon_startdir}; }${daemon} ${daemon_flags}${daemon_logger:+ 2>&1 |
>logger -ip ${daemon_logger} -t ${_name}}"
> }
>
> @@ -312,6 +313,7 @@ rc_stop_signal=${rc_stop_signal:=TERM}
> eval _rcflags=\${${_name}_flags}
> eval _rclogger=\${${_name}_logger}
> eval _rcrtable=\${${_name}_rtable}
> +eval _rcstartdir=\${${_name}_startdir}
> eval _rctimeout=\${${_name}_timeout}
> eval _rcuser=\${${_name}_user}
>
> @@ -329,6 +331,7 @@ getcap -f /etc/login.conf.d/${_name}:/etc/login.conf
> ${_name} 1>/dev/null 2>&1 &
> [ -n "${_rcflags}" ] && daemon_flags=${_rcflags}
> [ -n "${_rclogger}" ] && daemon_logger=${_rclogger}
> [ -n "${_rcrtable}" ] && daemon_rtable=${_rcrtable}
> +[ -n "${_rcstartdir}" ] && daemon_startdir=${_rcstartdir}
> [ -n "${_rctimeout}" ] && daemon_timeout=${_rctimeout}
> [ -n "${_rcuser}" ] && daemon_user=${_rcuser}
>
>
Re: divert packet kernel lock
> Date: Thu, 5 May 2022 22:41:01 +0200
> From: Alexander Bluhm
>
> Hi,
>
> The easiest way to make divert_packet() MP safe for now, is to
> protect sbappendaddr() with kernel lock.
All other invocations of sbappendaddr() run with the kernel lock held?
If so, maybe that should be asserted inside sbappendaddr()?
If not, I don't understand how this would help...
> ok?
>
> bluhm
>
> Index: netinet/ip_divert.c
> ===
> RCS file: /data/mirror/openbsd/cvs/src/sys/netinet/ip_divert.c,v
> retrieving revision 1.67
> diff -u -p -r1.67 ip_divert.c
> --- netinet/ip_divert.c 5 May 2022 16:44:22 - 1.67
> +++ netinet/ip_divert.c 5 May 2022 20:36:23 -
> @@ -222,11 +222,18 @@ divert_packet(struct mbuf *m, int dir, u
> }
>
> so = inp->inp_socket;
> + /*
> + * XXXSMP sbappendaddr() is not MP safe and this function is called
> + * from pf with shared netlock. To run only one sbappendaddr()
> + * protect it with kernel lock. Socket buffer access from system
> + * call is protected with exclusive net lock.
> + */
> + KERNEL_LOCK();
> if (sbappendaddr(so, &so->so_rcv, sintosa(&sin), m, NULL) == 0) {
> + KERNEL_UNLOCK();
> divstat_inc(divs_fullsock);
> goto bad;
> }
> - KERNEL_LOCK();
> sorwakeup(inp->inp_socket);
> KERNEL_UNLOCK();
>
> Index: netinet6/ip6_divert.c
> ===
> RCS file: /data/mirror/openbsd/cvs/src/sys/netinet6/ip6_divert.c,v
> retrieving revision 1.66
> diff -u -p -r1.66 ip6_divert.c
> --- netinet6/ip6_divert.c 5 May 2022 16:44:22 - 1.66
> +++ netinet6/ip6_divert.c 5 May 2022 20:36:23 -
> @@ -228,11 +228,18 @@ divert6_packet(struct mbuf *m, int dir,
> }
>
> so = inp->inp_socket;
> + /*
> + * XXXSMP sbappendaddr() is not MP safe and this function is called
> + * from pf with shared netlock. To run only one sbappendaddr()
> + * protect it with kernel lock. Socket buffer access from system
> + * call is protected with exclusive net lock.
> + */
> + KERNEL_LOCK();
> if (sbappendaddr(so, &so->so_rcv, sin6tosa(&sin6), m, NULL) == 0) {
> + KERNEL_UNLOCK();
> div6stat_inc(div6s_fullsock);
> goto bad;
> }
> - KERNEL_LOCK();
> sorwakeup(inp->inp_socket);
> KERNEL_UNLOCK();
>
>
>
divert packet kernel lock
Hi,
The easiest way to make divert_packet() MP safe for now, is to
protect sbappendaddr() with kernel lock.
ok?
bluhm
Index: netinet/ip_divert.c
===
RCS file: /data/mirror/openbsd/cvs/src/sys/netinet/ip_divert.c,v
retrieving revision 1.67
diff -u -p -r1.67 ip_divert.c
--- netinet/ip_divert.c 5 May 2022 16:44:22 - 1.67
+++ netinet/ip_divert.c 5 May 2022 20:36:23 -
@@ -222,11 +222,18 @@ divert_packet(struct mbuf *m, int dir, u
}
so = inp->inp_socket;
+ /*
+* XXXSMP sbappendaddr() is not MP safe and this function is called
+* from pf with shared netlock. To run only one sbappendaddr()
+* protect it with kernel lock. Socket buffer access from system
+* call is protected with exclusive net lock.
+*/
+ KERNEL_LOCK();
if (sbappendaddr(so, &so->so_rcv, sintosa(&sin), m, NULL) == 0) {
+ KERNEL_UNLOCK();
divstat_inc(divs_fullsock);
goto bad;
}
- KERNEL_LOCK();
sorwakeup(inp->inp_socket);
KERNEL_UNLOCK();
Index: netinet6/ip6_divert.c
===
RCS file: /data/mirror/openbsd/cvs/src/sys/netinet6/ip6_divert.c,v
retrieving revision 1.66
diff -u -p -r1.66 ip6_divert.c
--- netinet6/ip6_divert.c 5 May 2022 16:44:22 - 1.66
+++ netinet6/ip6_divert.c 5 May 2022 20:36:23 -
@@ -228,11 +228,18 @@ divert6_packet(struct mbuf *m, int dir,
}
so = inp->inp_socket;
+ /*
+* XXXSMP sbappendaddr() is not MP safe and this function is called
+* from pf with shared netlock. To run only one sbappendaddr()
+* protect it with kernel lock. Socket buffer access from system
+* call is protected with exclusive net lock.
+*/
+ KERNEL_LOCK();
if (sbappendaddr(so, &so->so_rcv, sin6tosa(&sin6), m, NULL) == 0) {
+ KERNEL_UNLOCK();
div6stat_inc(div6s_fullsock);
goto bad;
}
- KERNEL_LOCK();
sorwakeup(inp->inp_socket);
KERNEL_UNLOCK();
Fix console screen blanker - timeout of zero cannot be set
Summary:
A bug in wsdisplay.c prevents the console screen blanker from being disabled
once it has been enabled.
Details:
The console code includes a screen blanker facility, controlled with wsconsctl:
# wsconsctl display.screen_off
display.screen_off=0
By default, the screen blanker is disabled, (a timeout of zero milliseconds to
switch off the display).
If this is changed to, say, 1 msec, (10 seconds), the screen blanks after
being inactive for the requested amount of time. However, this cannot then be
disabled again, as a value of zero cannot be set. If this is attempted, the
previous value is retained:
# wsconsctl display.screen_off=1
display.screen_off=1
# wsconsctl display.screen_off=0
display.screen_off=1
Fix:
Although this issue can be worked around by setting the timeout to a very large
value, the following patch fixes the problem correctly by allowing a value of
zero to be set.
untrusted comment: verify with Exotic Silicon public signify key
RWRn5d3Yx35u0xMu23d1FXp8/gk1RD6tbS4V4/itPfs30MERqir90ezxVsxgmI9B3yshg2e/mTDYayITyM9vFpbECHwGSZySEAI=
--- wsdisplay.c.distThu May 5 15:50:12 2022
+++ wsdisplay.c Thu May 5 16:10:45 2022
@@ -1233,7 +1233,7 @@
error = 0;
sc->sc_burnflags = d->flags;
/* disable timeout if necessary */
- if ((sc->sc_burnflags & (WSDISPLAY_BURN_OUTPUT |
+ if (d->off==0 || (sc->sc_burnflags & (WSDISPLAY_BURN_OUTPUT |
WSDISPLAY_BURN_KBD | WSDISPLAY_BURN_MOUSE)) == 0) {
if (sc->sc_burnout)
timeout_del(&sc->sc_burner);
@@ -1252,14 +1252,12 @@
wsdisplay_burn(sc, sc->sc_burnflags);
}
}
- if (d->off) {
- sc->sc_burnoutintvl = d->off;
- if (!sc->sc_burnman) {
- sc->sc_burnout = sc->sc_burnoutintvl;
- /* reinit timeout if changed */
- if ((active->scr_flags & SCR_GRAPHICS) == 0)
- wsdisplay_burn(sc, sc->sc_burnflags);
- }
+ sc->sc_burnoutintvl = d->off;
+ if (!sc->sc_burnman) {
+ sc->sc_burnout = sc->sc_burnoutintvl;
+ /* reinit timeout if changed */
+ if ((active->scr_flags & SCR_GRAPHICS) == 0)
+ wsdisplay_burn(sc, sc->sc_burnflags);
}
return (error);
}
pkg_add: better correspondence of file names
In the old pkg_add model (prior to 7.1), we create tmp files anyway, so the
code is fine.
7.1 and later, we try to avoid creating temp files, so a better name matching
correspondence would be cool
What this patch does:
the old code creates a simple hash where we associate ONE packing-list element
with a given sha256 value.
the new code creates a list of entries for an sha256 hash and iterates
over them.
Of course, it's unlikely two entries with the same sha256 will have different
content (though we still check the size, just in case, and -Dchecksum is
really paranoid about it and also really slow).
BUT, even if we find a good match, we will keep going... until we find
the exact same name ! (or settle on the last one we saw if we don't)
[... which means no temp file creation]
It might be quite accidental, but python has lots of __init__.py files with
0 size, and ALSO a significant amount of file with non empty content, but which
are identical (for reasons...? I don't want to know why the python guys think
it's a good idea to ship LOTS of identical files, and I don't mean symlinks
or hardlinks but actual copies)
As a measure point, on the python 3.9 package, without this diff, we
misidentify ~500 names out of 2700, and so churn 500 temp files if we
replace python with itself.
I haven't measured data points for other packages, but I would guess most
python packages are probably similarly afflicted (yeah, not affected,
I think it's a disease :D )
Please test.
Something else might have been fucked up.
Index: OpenBSD/PkgAdd.pm
===
RCS file: /cvs/src/usr.sbin/pkg_add/OpenBSD/PkgAdd.pm,v
retrieving revision 1.130
diff -u -p -r1.130 PkgAdd.pm
--- OpenBSD/PkgAdd.pm 27 Apr 2022 15:27:45 - 1.130
+++ OpenBSD/PkgAdd.pm 5 May 2022 17:55:01 -
@@ -84,7 +84,7 @@ sub hash_files
my ($self, $sha, $state) = @_;
return if $self->{link} or $self->{symlink} or $self->{nochecksum};
if (defined $self->{d}) {
- $sha->{$self->{d}->key} = $self;
+ push @{$sha->{$self->{d}->key}}, $self;
}
}
@@ -94,13 +94,17 @@ sub tie_files
return if $self->{link} or $self->{symlink} or $self->{nochecksum};
# XXX python doesn't like this, overreliance on timestamps
return if $self->{name} =~ m/\.py$/ && !defined $self->{ts};
- if (defined $sha->{$self->{d}->key}) {
- my $tied = $sha->{$self->{d}->key};
- # don't tie if there's a problem with the file
- my $realname = $tied->realname($state);
- return unless -f $realname;
- # and do a sanity check that this file wasn't altered
- return unless (stat _)[7] == $self->{size};
+ if (exists $sha->{$self->{d}->key}) {
+ my ($tied, $realname);
+ for my $c (@{$sha->{$self->{d}->key}}) {
+ # don't tie if there's a problem with the file
+ my $realname = $c->realname($state);
+ next unless -f $realname;
+ # and do a sanity check that this file wasn't altered
+ next unless (stat _)[7] == $self->{size};
+ $tied = $c;
+ last if $tied->name eq $self->name;
+ }
if ($state->defines('checksum')) {
my $d = $self->compute_digest($realname, $self->{d});
# XXX we don't have to display anything here
athn(4) USB question: Where is Tx interrupt handler?
Hi all, Summary Question: Broadly, I am trying to understand where a interrupt callback is specified if not already specified by usbd_open_pipe_intr(9). Specifically, for the athn(4) driver, I am trying to understand if/how athn_usb_intr() is executed for Tx interrupts. This seems necessary yet I do not see a callback specified by usbd_setup_xfer(9) or by usbd_open_pipe_intr(9). All code is located in sys/dev/usb/if_athn_usb.c. Question Walk-through: >From reading the code, it seems that the athn_usb_intr() function is called whenever a Tx interrupt is triggered. The reason I think this is because there is a tsleep_nsec(9) for a Tx interrupt that awaits for a wakeup(9) that only happens in athn_usb_intr(). The 3 relevant steps are listed below in athn_usb_htc_setup() under the comment "Set credits for WLAN Tx pipe": 1. athn_usb_htc_msg(), which runs usbd_setup_xfer(9) and usbd_transfer(9) for a Tx interrupt. The callback is set to NULL. 2. usc->wait_msg_id is set to AR_HTC_MSG_CONF_PIPE_RSP. 3. A tsleep_nsec() on &usc->wait_msg_id The only place I see a wakeup(9) on &usc->wait_msg_id is within athn_usb_intr(), on condition that usc->wait_msg_id is set to AR_HTC_MSG_CONF_PIPE_RSP. Seems like a perfect match. Additionally, I do not see an Rx interrupt anywhere else. But even if it does happen somewhere and I am just missing it, the only place AR_HTC_MSG_CONF_PIPE_RSP is used is step 2. Rx interrupt callbacks to athn_usb_intr() are specified by the usbd_open_pipe_intr(9) call in athn_usb_open_pipes(). That seems explicit. But for the Tx interrupt, I do not see where the mapping to athn_usb_intr() is. Please assist, thank you. - Farhan
Re: uvm: Consider BUFPAGES_DEFICIT in swap_shortage
On Thu, May 05, 2022 at 10:16:23AM -0600, Bob Beck wrote:
> Ugh. You???re digging in the most perilous parts of the pile.
>
> I will go look with you??? sigh. (This is not yet an ok for that.)
>
> > On May 5, 2022, at 7:53 AM, Martin Pieuchot wrote:
> >
> > When considering the amount of free pages in the page daemon a small
> > amount is always kept for the buffer cache... except in one place.
> >
> > The diff below gets rid of this exception. This is important because
> > uvmpd_scan() is called conditionally using the following check:
> >
> > if (uvmexp.free - BUFPAGES_DEFICIT) < uvmexp.freetarg) {
> >...
> > }
> >
> > So in case of swap shortage we might end up freeing fewer pages than
> > wanted.
So a bit of backgroud.
I am pretty much of the belief that this "low water mark" for pages is
nonsense now. I was in the midst of trying to prove that
to myself and therefore rip down some of the crazy accounting and
very arbitrary limits in the buffer cache and got distracted.
Maybe something like this to start? (buf failing that I think
your current diff is probably ok).
Index: sys/sys/mount.h
===
RCS file: /cvs/src/sys/sys/mount.h,v
retrieving revision 1.148
diff -u -p -u -p -r1.148 mount.h
--- sys/sys/mount.h 6 Apr 2021 14:17:35 - 1.148
+++ sys/sys/mount.h 5 May 2022 16:50:50 -
@@ -488,10 +488,8 @@ struct bcachestats {
#ifdef _KERNEL
extern struct bcachestats bcstats;
extern long buflowpages, bufhighpages, bufbackpages;
-#define BUFPAGES_DEFICIT (((buflowpages - bcstats.numbufpages) < 0) ? 0 \
-: buflowpages - bcstats.numbufpages)
-#define BUFPAGES_INACT (((bcstats.numcleanpages - buflowpages) < 0) ? 0 \
-: bcstats.numcleanpages - buflowpages)
+#define BUFPAGES_DEFICIT 0
+#define BUFPAGES_INACT bcstats.numcleanpages
extern int bufcachepercent;
extern void bufadjust(int);
struct uvm_constraint_range;
> >
> > ok?
> >
> > Index: uvm/uvm_pdaemon.c
> > ===
> > RCS file: /cvs/src/sys/uvm/uvm_pdaemon.c,v
> > retrieving revision 1.98
> > diff -u -p -r1.98 uvm_pdaemon.c
> > --- uvm/uvm_pdaemon.c 4 May 2022 14:58:26 - 1.98
> > +++ uvm/uvm_pdaemon.c 5 May 2022 13:40:28 -
> > @@ -923,12 +923,13 @@ uvmpd_scan(void)
> > * detect if we're not going to be able to page anything out
> > * until we free some swap resources from active pages.
> > */
> > + free = uvmexp.free - BUFPAGES_DEFICIT;
> > swap_shortage = 0;
> > - if (uvmexp.free < uvmexp.freetarg &&
> > + if (free < uvmexp.freetarg &&
> > uvmexp.swpginuse == uvmexp.swpages &&
> > !uvm_swapisfull() &&
> > pages_freed == 0) {
> > - swap_shortage = uvmexp.freetarg - uvmexp.free;
> > + swap_shortage = uvmexp.freetarg - free;
> > }
> >
> > for (p = TAILQ_FIRST(&uvm.page_active);
> >
>
Re: acme-client: check token names
An ok beck@ from me with my usual curmudgeonly mutterings
about the people who made this necessary for isalnum(), walls,
and revolutions...
> On May 5, 2022, at 7:57 AM, Florian Obser wrote:
>
> On 2022-05-04 13:21 +0430, Ali Farzanrad wrote:
>> OK, I've tested following diff on my own domain and it works.
>> I did 2 modifications:
>>
>> 1. I explicitly call setlocate with "C" to ensure C locale,
>
> I came to the conclusion that it's best to call setlocale in first thing
> in main, that's what other code does, too and seems less surprising.
>
>>
>> 2. I did a string length check. According to RFC it must have 128 bit
>> of random entropy, so it should have at least 22 base64 characters,
>> but I was unsure. So I only check for empty strings.
>
> Checking for an empty string gives us a better error message, we would
> error out with EISDIR in open(2) later, so that's good I guess.
> Trying to enforce entropy seems a bit silly though, it's there to
> protect the CA, if they mess this up it's their problem.
>
> The following diff just moves setlocale to main and is OK florian
>
> Or I can commit it myself is someone else OKs it.
>
> diff --git chngproc.c chngproc.c
> index 0cbfaf27c31..f9cff65311d 100644
> --- chngproc.c
> +++ chngproc.c
> @@ -16,6 +16,7 @@
> */
>
> #include
> +#include
> #include
> #include
> #include
> @@ -77,6 +78,18 @@ chngproc(int netsock, const char *root)
> goto out;
> else if ((tok = readstr(netsock, COMM_TOK)) == NULL)
> goto out;
> + else if (strlen(tok) < 1) {
> + warnx("token is too short");
> + goto out;
> + }
> +
> + for (i = 0; tok[i]; ++i) {
> + int ch = (unsigned char)tok[i];
> + if (!isalnum(ch) && ch != '-' && ch != '_') {
> + warnx("token is not a valid base64url");
> + goto out;
> + }
> + }
>
> if (asprintf(&fmt, "%s.%s", tok, th) == -1) {
> warn("asprintf");
> diff --git main.c main.c
> index 65ea2cf3ac3..a3006ca1483 100644
> --- main.c
> +++ main.c
> @@ -20,6 +20,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -56,6 +57,9 @@ main(int argc, char *argv[])
> struct domain_c *domain = NULL;
> struct altname_c*ac;
>
> + if (setlocale(LC_CTYPE, "C") == NULL)
> + errx(1, "setlocale");
> +
> while ((c = getopt(argc, argv, "Fnrvf:")) != -1)
> switch (c) {
> case 'F':
>
>
> --
> I'm not entirely sure you are real.
Re: acme-client: check token names
On 2022-05-04 13:21 +0430, Ali Farzanrad wrote:
> OK, I've tested following diff on my own domain and it works.
> I did 2 modifications:
>
> 1. I explicitly call setlocate with "C" to ensure C locale,
I came to the conclusion that it's best to call setlocale in first thing
in main, that's what other code does, too and seems less surprising.
>
> 2. I did a string length check. According to RFC it must have 128 bit
> of random entropy, so it should have at least 22 base64 characters,
> but I was unsure. So I only check for empty strings.
Checking for an empty string gives us a better error message, we would
error out with EISDIR in open(2) later, so that's good I guess.
Trying to enforce entropy seems a bit silly though, it's there to
protect the CA, if they mess this up it's their problem.
The following diff just moves setlocale to main and is OK florian
Or I can commit it myself is someone else OKs it.
diff --git chngproc.c chngproc.c
index 0cbfaf27c31..f9cff65311d 100644
--- chngproc.c
+++ chngproc.c
@@ -16,6 +16,7 @@
*/
#include
+#include
#include
#include
#include
@@ -77,6 +78,18 @@ chngproc(int netsock, const char *root)
goto out;
else if ((tok = readstr(netsock, COMM_TOK)) == NULL)
goto out;
+ else if (strlen(tok) < 1) {
+ warnx("token is too short");
+ goto out;
+ }
+
+ for (i = 0; tok[i]; ++i) {
+ int ch = (unsigned char)tok[i];
+ if (!isalnum(ch) && ch != '-' && ch != '_') {
+ warnx("token is not a valid base64url");
+ goto out;
+ }
+ }
if (asprintf(&fmt, "%s.%s", tok, th) == -1) {
warn("asprintf");
diff --git main.c main.c
index 65ea2cf3ac3..a3006ca1483 100644
--- main.c
+++ main.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -56,6 +57,9 @@ main(int argc, char *argv[])
struct domain_c *domain = NULL;
struct altname_c*ac;
+ if (setlocale(LC_CTYPE, "C") == NULL)
+ errx(1, "setlocale");
+
while ((c = getopt(argc, argv, "Fnrvf:")) != -1)
switch (c) {
case 'F':
--
I'm not entirely sure you are real.
uvm: Consider BUFPAGES_DEFICIT in swap_shortage
When considering the amount of free pages in the page daemon a small
amount is always kept for the buffer cache... except in one place.
The diff below gets rid of this exception. This is important because
uvmpd_scan() is called conditionally using the following check:
if (uvmexp.free - BUFPAGES_DEFICIT) < uvmexp.freetarg) {
...
}
So in case of swap shortage we might end up freeing fewer pages than
wanted.
ok?
Index: uvm/uvm_pdaemon.c
===
RCS file: /cvs/src/sys/uvm/uvm_pdaemon.c,v
retrieving revision 1.98
diff -u -p -r1.98 uvm_pdaemon.c
--- uvm/uvm_pdaemon.c 4 May 2022 14:58:26 - 1.98
+++ uvm/uvm_pdaemon.c 5 May 2022 13:40:28 -
@@ -923,12 +923,13 @@ uvmpd_scan(void)
* detect if we're not going to be able to page anything out
* until we free some swap resources from active pages.
*/
+ free = uvmexp.free - BUFPAGES_DEFICIT;
swap_shortage = 0;
- if (uvmexp.free < uvmexp.freetarg &&
+ if (free < uvmexp.freetarg &&
uvmexp.swpginuse == uvmexp.swpages &&
!uvm_swapisfull() &&
pages_freed == 0) {
- swap_shortage = uvmexp.freetarg - uvmexp.free;
+ swap_shortage = uvmexp.freetarg - free;
}
for (p = TAILQ_FIRST(&uvm.page_active);
Re: allow 240/4 in various network daemons
On 2022/05/05 15:28, Jeroen Massar wrote: > Though they did it with 1.0.0.0/8 (though that is just a huge network > telescope). No this still does not work reliably
Re: allow 240/4 in various network daemons
It is like you are trying to predict the next 20 years, but I'm sorry I find it too confusing. Jeroen Massar wrote: > > On 5 May 2022, at 15:36, Theo de Raadt wrote: > > > > Jeroen Massar wrote: > > > >> I thus mostly see these odd prefixes (0/8, 127/8, 240/4) as extra RFC1918 > >> space > >> for those who do want to deploy more IPv4 as they can't be arsed after > >> almost > >> 30 years to finally do this IPv6 thing... > > > > But that's the dangerous part. > > > > If the operating systems suddenly allow use of this space for anything, and > > While security sensitive admins will too, there are way too many hosts that > have uptimes of several years and that will never be upgraded. > Rolling out such a change so that it is going to matter will be even slower > than an IPv6 rollout... decades. > > There are still stats out there which show how much ancient Android, or even > bare normal Linux is out there, and not forget about all the Windows boxes. > > Globally using these magic prefixes will thus become magic; operations teams > will never accept that debugging challenge, they have other things to do (in > the large corps: delivering ads, and those have to be delivered for sure, > hence why we have HTTPS everywhere now). > These magic prefixes don't have the properties of delivering ads, thus very > unlikely those types will use them for that (global routing). > > > everyone considers these address blocks new free-for-all new rfc1918 space, > > THEN the result will be that these spaces can never be globally announced > > later. > > IMHO they should not be, folks should be moving to IPv6 for global addresses. > > If the powers that be decide that it is "globally unique routeable space", > then I wish folks a lot of lot with debugging that. > > > You are suggesting facts on the ground should be allowed to beat the > > establishment of a policy. > > In case a policy is needed first, then one would have to wait for patching > too ;) > > > As an avid IPv6 user, IPv4 is only as compatibility on the edge for me, these > changes thus do not directly affect me (till the moment somebody wants to use > it globally and start breaking things). > > Greets, > Jeroen > >
Re: allow 240/4 in various network daemons
Jeroen Massar wrote: > I thus mostly see these odd prefixes (0/8, 127/8, 240/4) as extra RFC1918 > space > for those who do want to deploy more IPv4 as they can't be arsed after almost > 30 years to finally do this IPv6 thing... But that's the dangerous part. If the operating systems suddenly allow use of this space for anything, and everyone considers these address blocks new free-for-all new rfc1918 space, THEN the result will be that these spaces can never be globally announced later. You are suggesting facts on the ground should be allowed to beat the establishment of a policy.
Re: Use static allocation for rt_timer_queue
On Thu, May 05, 2022 at 03:08:39PM +0200, Claudio Jeker wrote:
> In total there are 6 rt_timer_queues in our kernel. 3 IPv4 and 3 IPv6.
> That number may be increased to 8 if arp and nd would use these timers as
> well. Because of this allocation the queue heads via pool(9) is overkill.
>
> Switch rt_timer_queue_create to rt_timer_queue_init which just sets up the
> struct and links it to the rt_timer_queue.
OK bluhm@
> Index: net/route.c
> ===
> RCS file: /cvs/src/sys/net/route.c,v
> retrieving revision 1.409
> diff -u -p -r1.409 route.c
> --- net/route.c 4 May 2022 16:52:10 - 1.409
> +++ net/route.c 5 May 2022 12:38:16 -
> @@ -150,7 +150,6 @@ int ifatrash; /* ifas not in
> ifp list
>
> struct pool rtentry_pool; /* pool for rtentry structures */
> struct pool rttimer_pool; /* pool for rttimer structures */
> -struct pool rttimer_queue_pool; /* pool for rttimer_queue structures */
>
> int rt_setgwroute(struct rtentry *, u_int);
> void rt_putgwroute(struct rtentry *);
> @@ -1393,8 +1392,6 @@ rt_timer_init(void)
>
> pool_init(&rttimer_pool, sizeof(struct rttimer), 0,
> IPL_MPFLOOR, 0, "rttmr", NULL);
> - pool_init(&rttimer_queue_pool, sizeof(struct rttimer_queue), 0,
> - IPL_MPFLOOR, 0, "rttmrq", NULL);
>
> mtx_init(&rttimer_mtx, IPL_MPFLOOR);
> LIST_INIT(&rttimer_queue_head);
> @@ -1402,13 +1399,10 @@ rt_timer_init(void)
> timeout_add_sec(&rt_timer_timeout, 1);
> }
>
> -struct rttimer_queue *
> -rt_timer_queue_create(int timeout, void (*func)(struct rtentry *, u_int))
> +void
> +rt_timer_queue_init(struct rttimer_queue *rtq, int timeout,
> +void (*func)(struct rtentry *, u_int))
> {
> - struct rttimer_queue*rtq;
> -
> - rtq = pool_get(&rttimer_queue_pool, PR_WAITOK | PR_ZERO);
> -
> rtq->rtq_timeout = timeout;
> rtq->rtq_count = 0;
> rtq->rtq_func = func;
> @@ -1417,8 +1411,6 @@ rt_timer_queue_create(int timeout, void
> mtx_enter(&rttimer_mtx);
> LIST_INSERT_HEAD(&rttimer_queue_head, rtq, rtq_link);
> mtx_leave(&rttimer_mtx);
> -
> - return (rtq);
> }
>
> void
> Index: net/route.h
> ===
> RCS file: /cvs/src/sys/net/route.h,v
> retrieving revision 1.193
> diff -u -p -r1.193 route.h
> --- net/route.h 4 May 2022 16:52:10 - 1.193
> +++ net/route.h 5 May 2022 12:39:15 -
> @@ -457,16 +457,16 @@ void rtm_proposal(struct ifnet *, struc
> int rt_setgate(struct rtentry *, struct sockaddr *, u_int);
> struct rtentry *rt_getll(struct rtentry *);
>
> -void rt_timer_init(void);
> -int rt_timer_add(struct rtentry *,
> - struct rttimer_queue *, u_int);
> -void rt_timer_remove_all(struct rtentry *);
> -struct rttimer_queue *rt_timer_queue_create(int,
> - void(*)(struct rtentry *, u_int));
> -void rt_timer_queue_change(struct rttimer_queue *, int);
> -void rt_timer_queue_flush(struct rttimer_queue *);
> -unsigned long rt_timer_queue_count(struct rttimer_queue *);
> -void rt_timer_timer(void *);
> +void rt_timer_init(void);
> +int rt_timer_add(struct rtentry *,
> + struct rttimer_queue *, u_int);
> +void rt_timer_remove_all(struct rtentry *);
> +void rt_timer_queue_init(struct rttimer_queue *, int,
> + void(*)(struct rtentry *, u_int));
> +void rt_timer_queue_change(struct rttimer_queue *, int);
> +void rt_timer_queue_flush(struct rttimer_queue *);
> +unsigned longrt_timer_queue_count(struct rttimer_queue *);
> +void rt_timer_timer(void *);
>
> int rt_mpls_set(struct rtentry *, struct sockaddr *, uint8_t);
> void rt_mpls_clear(struct rtentry *);
> Index: netinet/ip_icmp.c
> ===
> RCS file: /cvs/src/sys/netinet/ip_icmp.c,v
> retrieving revision 1.190
> diff -u -p -r1.190 ip_icmp.c
> --- netinet/ip_icmp.c 4 May 2022 16:52:10 - 1.190
> +++ netinet/ip_icmp.c 5 May 2022 12:49:51 -
> @@ -120,8 +120,8 @@ int icmp_redirtimeout = 10 * 60;
> static int icmperrpps_count = 0;
> static struct timeval icmperrppslim_last;
>
> -struct rttimer_queue *ip_mtudisc_timeout_q;
> -struct rttimer_queue *icmp_redirect_timeout_q;
> +struct rttimer_queue ip_mtudisc_timeout_q;
> +struct rttimer_queue icmp_redirect_timeout_q;
> struct cpumem *icmpcounters;
>
> const struct sysctl_bounded_args icmpctl_vars[] = {
> @@ -141,9 +141,9 @@ int icmp_sysctl_icmpstat(void *, size_t
> void
> icmp_init(void)
> {
> - ip_mtudisc_timeout_q = rt_timer_queue_create(ip_mtudisc_timeout,
> + rt_timer_queue_init(&ip_mtudisc_timeout_q, ip_m
Re: allow 240/4 in various network daemons
This discussion relates to only one step of a number of potential increments. I believe it is a bad idea to conflate all of these potential address space recovery changes as the same singular discussion. Not all the decisions being made on intranets are sane. Not all of these proposals make sense. Not all of these proposals make sense right away. Instead, they should be done piecemeal, and each one should be discussed seperately, or we will lose the way. Some of these address space changes will NEVER be globabaly routable because it has already been stomped on by squatters and will create visibility issues, or maybe NEVER is a decade hence. Other parts of thes address space changes have the potential for becoming globally routed. It is important to be careful and not just turn it into a free-for-all where people will make further bad decisions. Jeroen Massar wrote: > Hi Claudio, > > Why not update the BADCLASS check? > Though likely for IPv4 it will reduce to 0 items at one point and then can be > eliminated indeed. > > > Note that there are checks for loopback (127.0.0.0/8), there are a bunch of > organisations that started using everything but 127.0.0.0/24 (thus 127.0.0.1 > specifically) in their internal networks, routed, just like a normal prefix; > as that gives one kinda easily a whole /8 minus one /24. > Same for 0.0.0.0/8, there are orgs that instead of finally upgrading to IPv6 > just started using that, next to 240/8 and whatever they could find. > > Greets, > Jeroen >
Use static allocation for rt_timer_queue
In total there are 6 rt_timer_queues in our kernel. 3 IPv4 and 3 IPv6.
That number may be increased to 8 if arp and nd would use these timers as
well. Because of this allocation the queue heads via pool(9) is overkill.
Switch rt_timer_queue_create to rt_timer_queue_init which just sets up the
struct and links it to the rt_timer_queue.
--
:wq Claudio
Index: net/route.c
===
RCS file: /cvs/src/sys/net/route.c,v
retrieving revision 1.409
diff -u -p -r1.409 route.c
--- net/route.c 4 May 2022 16:52:10 - 1.409
+++ net/route.c 5 May 2022 12:38:16 -
@@ -150,7 +150,6 @@ int ifatrash; /* ifas not in ifp list
struct poolrtentry_pool; /* pool for rtentry structures */
struct poolrttimer_pool; /* pool for rttimer structures */
-struct poolrttimer_queue_pool; /* pool for rttimer_queue structures */
intrt_setgwroute(struct rtentry *, u_int);
void rt_putgwroute(struct rtentry *);
@@ -1393,8 +1392,6 @@ rt_timer_init(void)
pool_init(&rttimer_pool, sizeof(struct rttimer), 0,
IPL_MPFLOOR, 0, "rttmr", NULL);
- pool_init(&rttimer_queue_pool, sizeof(struct rttimer_queue), 0,
- IPL_MPFLOOR, 0, "rttmrq", NULL);
mtx_init(&rttimer_mtx, IPL_MPFLOOR);
LIST_INIT(&rttimer_queue_head);
@@ -1402,13 +1399,10 @@ rt_timer_init(void)
timeout_add_sec(&rt_timer_timeout, 1);
}
-struct rttimer_queue *
-rt_timer_queue_create(int timeout, void (*func)(struct rtentry *, u_int))
+void
+rt_timer_queue_init(struct rttimer_queue *rtq, int timeout,
+void (*func)(struct rtentry *, u_int))
{
- struct rttimer_queue*rtq;
-
- rtq = pool_get(&rttimer_queue_pool, PR_WAITOK | PR_ZERO);
-
rtq->rtq_timeout = timeout;
rtq->rtq_count = 0;
rtq->rtq_func = func;
@@ -1417,8 +1411,6 @@ rt_timer_queue_create(int timeout, void
mtx_enter(&rttimer_mtx);
LIST_INSERT_HEAD(&rttimer_queue_head, rtq, rtq_link);
mtx_leave(&rttimer_mtx);
-
- return (rtq);
}
void
Index: net/route.h
===
RCS file: /cvs/src/sys/net/route.h,v
retrieving revision 1.193
diff -u -p -r1.193 route.h
--- net/route.h 4 May 2022 16:52:10 - 1.193
+++ net/route.h 5 May 2022 12:39:15 -
@@ -457,16 +457,16 @@ void rtm_proposal(struct ifnet *, struc
int rt_setgate(struct rtentry *, struct sockaddr *, u_int);
struct rtentry *rt_getll(struct rtentry *);
-voidrt_timer_init(void);
-int rt_timer_add(struct rtentry *,
- struct rttimer_queue *, u_int);
-voidrt_timer_remove_all(struct rtentry *);
-struct rttimer_queue *rt_timer_queue_create(int,
- void(*)(struct rtentry *, u_int));
-voidrt_timer_queue_change(struct rttimer_queue *, int);
-voidrt_timer_queue_flush(struct rttimer_queue *);
-unsigned long rt_timer_queue_count(struct rttimer_queue *);
-voidrt_timer_timer(void *);
+void rt_timer_init(void);
+intrt_timer_add(struct rtentry *,
+ struct rttimer_queue *, u_int);
+void rt_timer_remove_all(struct rtentry *);
+void rt_timer_queue_init(struct rttimer_queue *, int,
+ void(*)(struct rtentry *, u_int));
+void rt_timer_queue_change(struct rttimer_queue *, int);
+void rt_timer_queue_flush(struct rttimer_queue *);
+unsigned long rt_timer_queue_count(struct rttimer_queue *);
+void rt_timer_timer(void *);
int rt_mpls_set(struct rtentry *, struct sockaddr *, uint8_t);
voidrt_mpls_clear(struct rtentry *);
Index: netinet/ip_icmp.c
===
RCS file: /cvs/src/sys/netinet/ip_icmp.c,v
retrieving revision 1.190
diff -u -p -r1.190 ip_icmp.c
--- netinet/ip_icmp.c 4 May 2022 16:52:10 - 1.190
+++ netinet/ip_icmp.c 5 May 2022 12:49:51 -
@@ -120,8 +120,8 @@ int icmp_redirtimeout = 10 * 60;
static int icmperrpps_count = 0;
static struct timeval icmperrppslim_last;
-struct rttimer_queue *ip_mtudisc_timeout_q;
-struct rttimer_queue *icmp_redirect_timeout_q;
+struct rttimer_queue ip_mtudisc_timeout_q;
+struct rttimer_queue icmp_redirect_timeout_q;
struct cpumem *icmpcounters;
const struct sysctl_bounded_args icmpctl_vars[] = {
@@ -141,9 +141,9 @@ int icmp_sysctl_icmpstat(void *, size_t
void
icmp_init(void)
{
- ip_mtudisc_timeout_q = rt_timer_queue_create(ip_mtudisc_timeout,
+ rt_timer_queue_init(&ip_mtudisc_timeout_q, ip_mtudisc_timeout,
&icmp_mtudisc_timeout);
- icmp_redirect_timeout_q = rt_timer_queue_create(icmp_redirtimeout,
+ rt_timer_queue_init(&icmp_redirect_timeout_q, icmp_redirtimeout,
NULL);
icmpcounters =
uvm_pagedequeue()
Diff below introduces a new wrapper to manipulate active/inactive page
queues.
ok?
Index: uvm/uvm_page.c
===
RCS file: /cvs/src/sys/uvm/uvm_page.c,v
retrieving revision 1.165
diff -u -p -r1.165 uvm_page.c
--- uvm/uvm_page.c 4 May 2022 14:58:26 - 1.165
+++ uvm/uvm_page.c 5 May 2022 12:49:13 -
@@ -987,16 +987,7 @@ uvm_pageclean(struct vm_page *pg)
/*
* now remove the page from the queues
*/
- if (pg->pg_flags & PQ_ACTIVE) {
- TAILQ_REMOVE(&uvm.page_active, pg, pageq);
- flags_to_clear |= PQ_ACTIVE;
- uvmexp.active--;
- }
- if (pg->pg_flags & PQ_INACTIVE) {
- TAILQ_REMOVE(&uvm.page_inactive, pg, pageq);
- flags_to_clear |= PQ_INACTIVE;
- uvmexp.inactive--;
- }
+ uvm_pagedequeue(pg);
/*
* if the page was wired, unwire it now.
@@ -1243,16 +1234,7 @@ uvm_pagewire(struct vm_page *pg)
MUTEX_ASSERT_LOCKED(&uvm.pageqlock);
if (pg->wire_count == 0) {
- if (pg->pg_flags & PQ_ACTIVE) {
- TAILQ_REMOVE(&uvm.page_active, pg, pageq);
- atomic_clearbits_int(&pg->pg_flags, PQ_ACTIVE);
- uvmexp.active--;
- }
- if (pg->pg_flags & PQ_INACTIVE) {
- TAILQ_REMOVE(&uvm.page_inactive, pg, pageq);
- atomic_clearbits_int(&pg->pg_flags, PQ_INACTIVE);
- uvmexp.inactive--;
- }
+ uvm_pagedequeue(pg);
uvmexp.wired++;
}
pg->wire_count++;
@@ -1324,28 +1306,32 @@ uvm_pageactivate(struct vm_page *pg)
KASSERT(uvm_page_owner_locked_p(pg));
MUTEX_ASSERT_LOCKED(&uvm.pageqlock);
+ uvm_pagedequeue(pg);
+ if (pg->wire_count == 0) {
+ TAILQ_INSERT_TAIL(&uvm.page_active, pg, pageq);
+ atomic_setbits_int(&pg->pg_flags, PQ_ACTIVE);
+ uvmexp.active++;
+
+ }
+}
+
+/*
+ * uvm_pagedequeue: remove a page from any paging queue
+ */
+void
+uvm_pagedequeue(struct vm_page *pg)
+{
+ if (pg->pg_flags & PQ_ACTIVE) {
+ TAILQ_REMOVE(&uvm.page_active, pg, pageq);
+ atomic_clearbits_int(&pg->pg_flags, PQ_ACTIVE);
+ uvmexp.active--;
+ }
if (pg->pg_flags & PQ_INACTIVE) {
TAILQ_REMOVE(&uvm.page_inactive, pg, pageq);
atomic_clearbits_int(&pg->pg_flags, PQ_INACTIVE);
uvmexp.inactive--;
}
- if (pg->wire_count == 0) {
- /*
-* if page is already active, remove it from list so we
-* can put it at tail. if it wasn't active, then mark
-* it active and bump active count
-*/
- if (pg->pg_flags & PQ_ACTIVE)
- TAILQ_REMOVE(&uvm.page_active, pg, pageq);
- else {
- atomic_setbits_int(&pg->pg_flags, PQ_ACTIVE);
- uvmexp.active++;
- }
-
- TAILQ_INSERT_TAIL(&uvm.page_active, pg, pageq);
- }
}
-
/*
* uvm_pagezero: zero fill a page
*/
Index: uvm/uvm_page.h
===
RCS file: /cvs/src/sys/uvm/uvm_page.h,v
retrieving revision 1.67
diff -u -p -r1.67 uvm_page.h
--- uvm/uvm_page.h 29 Jan 2022 06:25:33 - 1.67
+++ uvm/uvm_page.h 5 May 2022 12:49:13 -
@@ -224,6 +224,7 @@ boolean_t uvm_page_physget(paddr_t *);
#endif
void uvm_pageactivate(struct vm_page *);
+void uvm_pagedequeue(struct vm_page *);
vaddr_tuvm_pageboot_alloc(vsize_t);
void uvm_pagecopy(struct vm_page *, struct vm_page *);
void uvm_pagedeactivate(struct vm_page *);
OpenBSD Errata: May 5, 2022 (ipsec)
Errata patch for kernel IPsec has been released for OpenBSD 7.1. Binary updates for the amd64, i386 and arm64 platform are available via the syspatch utility. Source code patches can be found on the respective errata page: https://www.openbsd.org/errata71.html
Re: com.c: ASIX AX99100(PCIe UART) probed FIFO depth=0 issue
ping?
OpenBSD-7.1 still occur this.
--
SASANO Takayoshi (JG1UAA)
On Sat, 16 Oct 2021 12:21:57 +0900,
SASANO Takayoshi wrote:
>
> Hi,
>
> At least 6.9 and 7.0 (and -current) sometimes shows a dmesg that:
>
> puc1 at pci1 dev 0 function 1 "ASIX AX99100" rev 0x00: ports: 16 com
> com5 at puc1 port 0 apic 1 int 1: st16650, 32 byte fifo
> com5: probed fifo depth: 0 bytes
>
> In sys/dev/ic/com.c:com_fifo_probe(), I found that transmitted data to
> determine FIFO depth is not received. And, a bit delay is required after
> TX/RX FIFO reset.
>
> Simply adding com_read_reg(sc, com_iir) resolves this issue on my PC,
> but I think delay(100) may be better like other resetting FIFO.
>
> Here is the diff, any comments will be welcomed.
>
> Index: com.c
> ===
> RCS file: /cvs/src/sys/dev/ic/com.c,v
> retrieving revision 1.174
> diff -u -p -r1.174 com.c
> --- com.c 6 May 2021 20:35:21 - 1.174
> +++ com.c 16 Oct 2021 03:05:54 -
> @@ -1562,6 +1562,7 @@ com_fifo_probe(struct com_softc *sc)
> fifo |= FIFO_ENABLE_64BYTE;
>
> com_write_reg(sc, com_fifo, fifo);
> + delay(100);
>
> for (len = 0; len < 256; len++) {
> com_write_reg(sc, com_data, (len + 1));
>
> --
> SASANO Takayoshi (JG1UAA)
>
Re: pcidevs update for AMD Sensor Fusion Hub
On Thu, May 05, 2022 at 12:34:33PM +0200, Frederic Cambus wrote: > On Thu, May 05, 2022 at 08:04:16PM +1000, Jonathan Gray wrote: > > On Thu, May 05, 2022 at 11:26:23AM +0200, Frederic Cambus wrote: > > > Hi tech@, > > > > > > Here is a diff to add ID for the AMD Sensor Fusion Hub found on my > > > Ryzen-based ZBOX CA621. Full dmesg below. > > > > > > Comments? OK? > > > > Can the string instead be "17h/1xh SFH"? > > Sure thing, new diff below. ok jsg@ > > Index: sys/dev/pci/pcidevs > === > RCS file: /cvs/src/sys/dev/pci/pcidevs,v > retrieving revision 1.1992 > diff -u -p -r1.1992 pcidevs > --- sys/dev/pci/pcidevs 4 May 2022 08:10:43 - 1.1992 > +++ sys/dev/pci/pcidevs 5 May 2022 10:28:50 - > @@ -818,6 +818,7 @@ product AMD 17_1X_XHCI_1 0x15e0 17h/1xh > product AMD 17_1X_XHCI_2 0x15e1 17h/1xh xHCI > product AMD 17_1X_ACP0x15e2 17h/1xh I2S Audio > product AMD 17_1X_HDA0x15e3 17h/1xh HD Audio > +product AMD 17_1X_SFH0x15e6 17h/1xh SFH > product AMD 17_1X_DF_0 0x15e8 17h/1xh Data Fabric > product AMD 17_1X_DF_1 0x15e9 17h/1xh Data Fabric > product AMD 17_1X_DF_2 0x15ea 17h/1xh Data Fabric >
Re: pcidevs update for AMD Sensor Fusion Hub
On Thu, May 05, 2022 at 08:04:16PM +1000, Jonathan Gray wrote: > On Thu, May 05, 2022 at 11:26:23AM +0200, Frederic Cambus wrote: > > Hi tech@, > > > > Here is a diff to add ID for the AMD Sensor Fusion Hub found on my > > Ryzen-based ZBOX CA621. Full dmesg below. > > > > Comments? OK? > > Can the string instead be "17h/1xh SFH"? Sure thing, new diff below. Index: sys/dev/pci/pcidevs === RCS file: /cvs/src/sys/dev/pci/pcidevs,v retrieving revision 1.1992 diff -u -p -r1.1992 pcidevs --- sys/dev/pci/pcidevs 4 May 2022 08:10:43 - 1.1992 +++ sys/dev/pci/pcidevs 5 May 2022 10:28:50 - @@ -818,6 +818,7 @@ product AMD 17_1X_XHCI_10x15e0 17h/1xh product AMD 17_1X_XHCI_2 0x15e1 17h/1xh xHCI product AMD 17_1X_ACP 0x15e2 17h/1xh I2S Audio product AMD 17_1X_HDA 0x15e3 17h/1xh HD Audio +product AMD 17_1X_SFH 0x15e6 17h/1xh SFH product AMD 17_1X_DF_0 0x15e8 17h/1xh Data Fabric product AMD 17_1X_DF_1 0x15e9 17h/1xh Data Fabric product AMD 17_1X_DF_2 0x15ea 17h/1xh Data Fabric
Re: kbd set error message
anyone?
On Sun, Apr 17, 2022 at 08:20:40PM +0200, Alexander Bluhm wrote:
> Hi,
>
> After fixing the kbd -l error handling, kbd set needs the same diff.
> While there, shorten long lines and avoid v--; v++; logic.
>
> $ ./kbd de
> kbd: /dev/wskbd0: Permission denied
>
> ok?
>
> bluhm
>
> Index: sbin/kbd/kbd_wscons.c
> ===
> RCS file: /data/mirror/openbsd/cvs/src/sbin/kbd/kbd_wscons.c,v
> retrieving revision 1.35
> diff -u -p -r1.35 kbd_wscons.c
> --- sbin/kbd/kbd_wscons.c 17 Apr 2022 17:33:50 - 1.35
> +++ sbin/kbd/kbd_wscons.c 17 Apr 2022 17:39:56 -
> @@ -232,7 +232,7 @@ void
> kbd_set(char *name, int verbose)
> {
> charbuf[LINE_MAX], *c, *b, device[sizeof "/dev/wskbd00"];
> - int map = 0, v, i, fd;
> + int map = 0, v, i, fd, error = 0;
> struct nameint *n;
>
> c = name;
> @@ -271,19 +271,29 @@ kbd_set(char *name, int verbose)
> fd = open(device, O_WRONLY);
> if (fd == -1)
> fd = open(device, O_RDONLY);
> - if (fd >= 0) {
> + if (fd == -1) {
> + /* remember the first error number */
> + if (error == 0)
> + error = errno;
> + } else {
> + /* at least one success, do not print error */
> + error = -1;
> +
> if (ioctl(fd, WSKBDIO_SETENCODING, &map) == -1) {
> - if (errno == EINVAL) {
> - fprintf(stderr,
> - "%s: unsupported encoding %s on
> %s\n",
> - __progname, name, device);
> - } else
> - err(1, "WSKBDIO_SETENCODING: %s",
> device);
> - v--;
> - }
> - v++;
> + if (errno != EINVAL)
> + err(1, "WSKBDIO_SETENCODING %s",
> + device);
> + fprintf(stderr,
> + "%s: unsupported encoding %s on %s\n",
> + __progname, name, device);
> + } else
> + v++;
> close(fd);
> }
> + }
> + if (error > 0) {
> + errno = error;
> + err(1, "/dev/wskbd0");
> }
>
> if (verbose && v > 0)
Re: pcidevs update for AMD Sensor Fusion Hub
On Thu, May 05, 2022 at 11:26:23AM +0200, Frederic Cambus wrote: > Hi tech@, > > Here is a diff to add ID for the AMD Sensor Fusion Hub found on my > Ryzen-based ZBOX CA621. Full dmesg below. > > Comments? OK? Can the string instead be "17h/1xh SFH"? > > Index: sys/dev/pci/pcidevs > === > RCS file: /cvs/src/sys/dev/pci/pcidevs,v > retrieving revision 1.1988 > diff -u -p -r1.1988 pcidevs > --- sys/dev/pci/pcidevs 11 Mar 2022 08:28:40 - 1.1988 > +++ sys/dev/pci/pcidevs 4 May 2022 09:04:34 - > @@ -818,6 +818,7 @@ product AMD 17_1X_XHCI_1 0x15e0 17h/1xh > product AMD 17_1X_XHCI_2 0x15e1 17h/1xh xHCI > product AMD 17_1X_ACP0x15e2 17h/1xh I2S Audio > product AMD 17_1X_HDA0x15e3 17h/1xh HD Audio > +product AMD 17_1X_SFH0x15e6 17h/1xh Sensor Fusion Hub > product AMD 17_1X_DF_0 0x15e8 17h/1xh Data Fabric > product AMD 17_1X_DF_1 0x15e9 17h/1xh Data Fabric > product AMD 17_1X_DF_2 0x15ea 17h/1xh Data Fabric > > > OpenBSD 7.1-current (GENERIC.MP) #1: Wed May 4 13:09:09 CEST 2022 > fcam...@amd64.my.domain:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 32125165568 (30636MB) > avail mem = 31134224384 (29691MB) > random: good seed from bootblocks > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 3.2 @ 0xeacc0 (44 entries) > bios0: vendor American Megatrends Inc. version "B410P112" date 09/08/2021 > bios0: ZOTAC B410 > acpi0 at bios0: ACPI 6.0 > acpi0: sleep states S0 S3 S4 S5 > acpi0: tables DSDT FACP APIC FPDT FIDT SSDT MCFG HPET UEFI TPM2 SSDT CRAT > CDIT SSDT SSDT SSDT WSMT SSDT > acpi0: wakeup devices GPP0(S4) GPP1(S4) GPP2(S4) GPP3(S4) GPP4(S4) GPP5(S4) > GPP6(S4) GP17(S4) XHC0(S4) XHC1(S4) GP18(S4) SIO1(S3) > acpitimer0 at acpi0: 3579545 Hz, 32 bits > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: AMD Ryzen 3 3200U with Radeon Vega Mobile Gfx, 2595.56 MHz, 17-18-01 > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES > cpu0: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB > 64b/line 8-way L2 cache > cpu0: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative > cpu0: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges > cpu0: apic clock running at 24MHz > cpu0: mwait min=64, max=64, C-substates=1.1, IBE > cpu1 at mainbus0: apid 1 (application processor) > cpu1: AMD Ryzen 3 3200U with Radeon Vega Mobile Gfx, 2595.10 MHz, 17-18-01 > cpu1: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES > cpu1: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB > 64b/line 8-way L2 cache > cpu1: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative > cpu1: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative > cpu1: smt 1, core 0, package 0 > cpu2 at mainbus0: apid 2 (application processor) > cpu2: AMD Ryzen 3 3200U with Radeon Vega Mobile Gfx, 2595.10 MHz, 17-18-01 > cpu2: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES > cpu2: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB > 64b/line 8-way L2 cache > cpu2: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative > cpu2: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative > cpu2: smt 0, core 1, package 0 > cpu3 at mainbus0: apid 3 (application processor) > cpu3: AMD Ryzen 3 3200U with Radeon Vega Mobile Gfx, 2595.10 MHz, 17-18-01 > cpu3: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVB
allow 240/4 in various network daemons
So most routing daemons and other network daemons like pppd do not allow
240/4 as IPs because they check the IP against IN_BADCLASS().
I think it is time to remove this restriction.
Now there is another magical network 0.0.0.0/8 which is not allowed in
some but not all of the routing daemons. Not sure if that should be
removed or blocked in all daemons.
--
:wq Claudio
Index: usr.sbin/bgpd/kroute.c
===
RCS file: /cvs/src/usr.sbin/bgpd/kroute.c,v
retrieving revision 1.244
diff -u -p -r1.244 kroute.c
--- usr.sbin/bgpd/kroute.c 8 Mar 2022 12:58:57 - 1.244
+++ usr.sbin/bgpd/kroute.c 5 May 2022 08:48:27 -
@@ -1448,12 +1448,11 @@ kr_redistribute(int type, struct ktable
return;
/*
-* We consider the loopback net, multicast and experimental addresses
+* We consider the loopback net and multicast addresses
* as not redistributable.
*/
a = ntohl(kr->prefix.s_addr);
- if (IN_MULTICAST(a) || IN_BADCLASS(a) ||
- (a >> IN_CLASSA_NSHIFT) == IN_LOOPBACKNET)
+ if (IN_MULTICAST(a) || (a >> IN_CLASSA_NSHIFT) == IN_LOOPBACKNET)
return;
/* Check if the nexthop is the loopback addr. */
Index: usr.sbin/bgpd/rde.c
===
RCS file: /cvs/src/usr.sbin/bgpd/rde.c,v
retrieving revision 1.544
diff -u -p -r1.544 rde.c
--- usr.sbin/bgpd/rde.c 22 Mar 2022 10:53:08 - 1.544
+++ usr.sbin/bgpd/rde.c 5 May 2022 08:48:49 -
@@ -1790,10 +1790,10 @@ bad_flags:
UPD_READ(&nexthop.v4.s_addr, p, plen, 4);
/*
* Check if the nexthop is a valid IP address. We consider
-* multicast and experimental addresses as invalid.
+* multicast addresses as invalid.
*/
tmp32 = ntohl(nexthop.v4.s_addr);
- if (IN_MULTICAST(tmp32) || IN_BADCLASS(tmp32)) {
+ if (IN_MULTICAST(tmp32)) {
rde_update_err(peer, ERR_UPDATE, ERR_UPD_NEXTHOP,
op, len);
return (-1);
Index: usr.sbin/eigrpd/util.c
===
RCS file: /cvs/src/usr.sbin/eigrpd/util.c,v
retrieving revision 1.10
diff -u -p -r1.10 util.c
--- usr.sbin/eigrpd/util.c 7 Dec 2018 08:40:54 - 1.10
+++ usr.sbin/eigrpd/util.c 5 May 2022 08:53:31 -
@@ -224,7 +224,7 @@ bad_addr_v4(struct in_addr addr)
if (((a >> IN_CLASSA_NSHIFT) == 0) ||
((a >> IN_CLASSA_NSHIFT) == IN_LOOPBACKNET) ||
- IN_MULTICAST(a) || IN_BADCLASS(a))
+ IN_MULTICAST(a))
return (1);
return (0);
Index: usr.sbin/ldpd/util.c
===
RCS file: /cvs/src/usr.sbin/ldpd/util.c,v
retrieving revision 1.5
diff -u -p -r1.5 util.c
--- usr.sbin/ldpd/util.c7 Dec 2018 08:40:54 - 1.5
+++ usr.sbin/ldpd/util.c5 May 2022 08:54:03 -
@@ -223,7 +223,7 @@ bad_addr_v4(struct in_addr addr)
if (((a >> IN_CLASSA_NSHIFT) == 0) ||
((a >> IN_CLASSA_NSHIFT) == IN_LOOPBACKNET) ||
- IN_MULTICAST(a) || IN_BADCLASS(a))
+ IN_MULTICAST(a))
return (1);
return (0);
Index: usr.sbin/mrouted/inet.c
===
RCS file: /cvs/src/usr.sbin/mrouted/inet.c,v
retrieving revision 1.6
diff -u -p -r1.6 inet.c
--- usr.sbin/mrouted/inet.c 21 Apr 2013 06:42:43 - 1.6
+++ usr.sbin/mrouted/inet.c 5 May 2022 08:57:09 -
@@ -36,7 +36,6 @@ inet_valid_host(u_int32_t naddr)
addr = ntohl(naddr);
return (!(IN_MULTICAST(addr) ||
- IN_BADCLASS (addr) ||
(addr & 0xff00) == 0));
}
@@ -83,7 +82,7 @@ inet_valid_subnet(u_int32_t nsubnet, u_i
(subnet & 0xff00) == 0x7f00 ||
(subnet & 0xff00) == 0x) return (FALSE);
}
-else if (IN_CLASSD(subnet) || IN_BADCLASS(subnet)) {
+else if (IN_CLASSD(subnet)) {
/* Above Class C address space */
return (FALSE);
}
Index: usr.sbin/ospfd/kroute.c
===
RCS file: /cvs/src/usr.sbin/ospfd/kroute.c,v
retrieving revision 1.114
diff -u -p -r1.114 kroute.c
--- usr.sbin/ospfd/kroute.c 20 Aug 2020 03:09:28 - 1.114
+++ usr.sbin/ospfd/kroute.c 5 May 2022 08:54:30 -
@@ -565,12 +565,11 @@ kr_redist_eval(struct kroute *kr, struct
goto dont_redistribute;
/*
-* We consider the loopback net, multicast and experimental addresses
+* We consider the loopback net and multicast addresses
* as not redistributable.
*/
a = ntohl(kr->prefix.s_addr);
- if (IN_MULTICAST(a) || IN_BADCLAS
pcidevs update for AMD Sensor Fusion Hub
Hi tech@, Here is a diff to add ID for the AMD Sensor Fusion Hub found on my Ryzen-based ZBOX CA621. Full dmesg below. Comments? OK? Index: sys/dev/pci/pcidevs === RCS file: /cvs/src/sys/dev/pci/pcidevs,v retrieving revision 1.1988 diff -u -p -r1.1988 pcidevs --- sys/dev/pci/pcidevs 11 Mar 2022 08:28:40 - 1.1988 +++ sys/dev/pci/pcidevs 4 May 2022 09:04:34 - @@ -818,6 +818,7 @@ product AMD 17_1X_XHCI_10x15e0 17h/1xh product AMD 17_1X_XHCI_2 0x15e1 17h/1xh xHCI product AMD 17_1X_ACP 0x15e2 17h/1xh I2S Audio product AMD 17_1X_HDA 0x15e3 17h/1xh HD Audio +product AMD 17_1X_SFH 0x15e6 17h/1xh Sensor Fusion Hub product AMD 17_1X_DF_0 0x15e8 17h/1xh Data Fabric product AMD 17_1X_DF_1 0x15e9 17h/1xh Data Fabric product AMD 17_1X_DF_2 0x15ea 17h/1xh Data Fabric OpenBSD 7.1-current (GENERIC.MP) #1: Wed May 4 13:09:09 CEST 2022 fcam...@amd64.my.domain:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 32125165568 (30636MB) avail mem = 31134224384 (29691MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.2 @ 0xeacc0 (44 entries) bios0: vendor American Megatrends Inc. version "B410P112" date 09/08/2021 bios0: ZOTAC B410 acpi0 at bios0: ACPI 6.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT FIDT SSDT MCFG HPET UEFI TPM2 SSDT CRAT CDIT SSDT SSDT SSDT WSMT SSDT acpi0: wakeup devices GPP0(S4) GPP1(S4) GPP2(S4) GPP3(S4) GPP4(S4) GPP5(S4) GPP6(S4) GP17(S4) XHC0(S4) XHC1(S4) GP18(S4) SIO1(S3) acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD Ryzen 3 3200U with Radeon Vega Mobile Gfx, 2595.56 MHz, 17-18-01 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu0: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 8-way L2 cache cpu0: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu0: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 24MHz cpu0: mwait min=64, max=64, C-substates=1.1, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD Ryzen 3 3200U with Radeon Vega Mobile Gfx, 2595.10 MHz, 17-18-01 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu1: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 8-way L2 cache cpu1: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu1: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu1: smt 1, core 0, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: AMD Ryzen 3 3200U with Radeon Vega Mobile Gfx, 2595.10 MHz, 17-18-01 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu2: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 8-way L2 cache cpu2: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu2: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu2: smt 0, core 1, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: AMD Ryzen 3 3200U with Radeon Vega Mobile Gfx, 2595.10 MHz, 17-18-01 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu3: 64KB 64b/line 4-way I-cache,
Re: Reserved address behavior (alternate broadcast and 240/4)
On 2022/05/05 08:36, Claudio Jeker wrote: > > Agreed, there is also IN_BADCLASS() which is used by the routing daemons. > IN_EXPERIMENTAL and IN_BADCLASS are the same definition. > > Looking at debian code search IN_EXPERIMENTAL() is still referenced in a > bunch of packages. So I wonder if your alternative to just make > IN_EXPERIMENTAL never match is the right approach. It looks all or nearly all guarded with ifdefs in some way or other. I don't know what the best approach is but I will do a ports bulk with this removed completely to collect data about how many things fail (I think it will be at the most single-digit numbers, and quite possibly 0).
Re: Reserved address behavior (alternate broadcast and 240/4)
On Wed, May 04, 2022 at 06:48:14PM -0700, Seth David Schoen wrote:
> This has some odd consequences. For instance, if an OpenBSD system
> has an interface numbered with an address in 240/4, it can initiate
> and receive TCP connections using that address, and it can ping other
> hosts using that address, but it won't respond to pings from other
> hosts. This patch cleans this up:
As forwarding and icmp reflect is the only place where IN_EXPERIMENTAL()
is used, I cannot see a downside of this patch.
OK bluhm@
> Index: in.c
> ===
> RCS file: /cvs/src/sys/netinet/in.c,v
> retrieving revision 1.173
> diff -u -p -r1.173 in.c
> --- in.c 28 Mar 2022 16:31:26 - 1.173
> +++ in.c 5 May 2022 01:05:04 -
> @@ -103,7 +103,7 @@ in_canforward(struct in_addr in)
> {
> u_int32_t net;
>
> - if (IN_EXPERIMENTAL(in.s_addr) || IN_MULTICAST(in.s_addr))
> + if (IN_MULTICAST(in.s_addr))
> return (0);
> if (IN_CLASSA(in.s_addr)) {
> net = in.s_addr & IN_CLASSA_NET;
