For example, "sysctl -w kern.mbuf=" had been displayed extra node names in the MIB.
# sysctl -w kern.mbuf=
kern.mbuf.mbuf.msize = 512
kern.mbuf.mbuf.mclbytes = 2048
:
Summary of changes in tzdata2023c (2023-03-28 12:42:14 -0700):
This essentially reverts the 2023b update, as the proposed delay
of the start of summer time in Lebanon didn't end up happening as
intended. What did happen was apparently chaos ... the official
start of summer time was still delayed, but only until last Wednesday
night (between 2023-03-29 and 2029-03-30) - which has already passed.
Since it is unclear what local time was actually observed during
the period between when summer time was originally planned to start
(last Sat night, between 2023-03-25 and 2023-03-26) and when it
officially did, for now, this update simply reverts to the original
start time (2023-03-26 00:00:00 local). Should that turn out to
be sub-optimal, a later update can correct it. Only timestamps
for the period between 2023-03-26 00:00:00 and 2023-03-30 00:00:00
are affected.
Descriptors can be chained by themself. And descriptors added to
avail ring or used ring are already chained. But it was not used
for unused descriptors and another linked list structure named
vq_entry was used.
The chain is also used for unused descriptors to make virtio(4)
simpler.
May be helpful explanation but it didn't make its way upstream,
whereas the file has moved and had other upstream changes, so let's
make the next merge less painful.
No functional change intended.
Limited to architectures where it is actually needed by gcc for any
calls to stdatomic.h atomic_is_lock_free for now.
We should also add it to other architectures too, along with lockful
atomic r/m/w operations for sizes that can't be handled natively, but
that's a lot more work. It is also necessary for -fno-inline-atomics
but we're missing a lot of other symbols for that too, to be fixed.
For now, this should enable the OpenSSL build to complete on these
architectures again after I reverted a local change.
XXX pullup-10
... too bad what it really needs is reconstructive surgery. I tried
to fix the most obvious problems (unsorted lists, obviously wrong
markup, pleonastic wording that drowns out useful information in
repetition and lifetime supply of quote marks).
This page really needs a native speaker to take some loving care of it.
Be consistent with method (and style) when referring to the mbufs and
ifstat sub-commands when describing what is available (and correct
"mbuf" to be "mbufs" which is what the internal command really is).
That is don't just "double quote" one and 'single quote' the other.
Upstream OpenSSL changed
loop 1b
to
dec %rcx
jnz 1b
which has mostly the same semantics, in this change:
https://github.com/openssl/openssl/pull/4743
For some reason, in one of the OpenSSL updates, we ended up with a
local change to revert this.
The Intel and AMD optimization guides are silent on the LOOP
instruction, but Agner Fog's tables shows that while LOOP is one
cycle shorter than DEC;JNZ on AMD Zen microarchitectures, it is a
good half dozen cycles longer than DEC;JNZ on recent Intel
microarchitectures.
The history of the OpenSSL change suggests it was intended, and I
can't find any indication other than `merge conflicts' that we
intended to keep the LOOP version. So let's reduce the local diff by
nixing it.
Cute as it is to write the an instruction in a delay slot with an
extra space, it's not really useful to keep this around as a local
change since the substantive change was applied upstream years ago.
Much as I'm happy to eliminate sprintf, there's very little value to
maintaining a local change under an #ifdef that will never, ever be
taken on NetBSD.
Verified libcrypto.so does not sprout any references to sprintf as a
result.
This was needed back when the file was patched locally to cast a
pointer to intptr_t rather than to int, but that code is now gone and
the include is no longer necessary. So let's reduce the local diff
by omitting this unnecessary change.
According to the commit history, this was introduced when gcc4.5
complained about using the return value of fileno without checking it
against -1. gcc 10.4 no longer appears to object, so let's just nix
the local patch.
vq->vq_avail[0].ring is a zero-length array, and thus sizeof is zero;
likewise vq->vq_used[0].ring.
Use vq->vq_avail[0].ring[0] and vq->vq_used[0].ring[0] to fix this
and restore the previous allocation sizing logic.
XXX We shouldn't use zero-length arrays here -- they are asking for
trouble like this, and C99 has a standard way to express what we're
actually trying to get at it, flexible array members.
PR kern/57304
Reported-by: syzbot+7fb1047f5dfa33b26331@syzkaller.appspotmail.com
https://mail-index.netbsd.org/tech-userlevel/2023/03/15/msg013727.html
The previous attempt (message 351 about 'extern' declarations outside
headers) did not cover the proposal from the tech-userlevel mailing list
but instead warns about a different usage pattern of the 'extern'
keyword.
ryo