217481a3 melifaro Jan. 29, 2022, 9:59 a.m.
Submitted by:	<tda.77793 at gmail.com>
PR:		260218
MFC after:	2 weeks
cgit
c9d1fa70 peterj Jan. 29, 2022, 9:41 a.m.
Providing a timestamp with seconds granularity helps make it obvious
that the display is updating.

Reviewed by:    mckusick
MFC after:      1 week
Differential Revision:  https://reviews.freebsd.org/D29181
cgit
9146546e wosch Jan. 29, 2022, 7:13 a.m.
21cc4bee wosch Jan. 29, 2022, 7:12 a.m.
- stop on first error
- improve awk script: print the last two characters for bigram -  not the second word
- remove unnecessary checks
- use mktemp
- refactor
cgit
9dac0268 kp Jan. 28, 2022, 10:09 p.m.
If there are no more entries, or if we fail to restore the rcvif of a
queued mbuf dn_dequeue() can return NULL.
Cope with this.

Reviewed by:	glebius
Sponsored by:	Rubicon Communications, LLC ("Netgate")
Differential Revision:	https://reviews.freebsd.org/D34078
cgit
703e533d kp Jan. 28, 2022, 10:09 p.m.
When we remove an interface it is first removed from the interface list
V_ifnet (by if_unlink_ifnet()) and marked as IFF_DYING. We then wait for
any possible references to stop being used (i.e.
epoch_wait/epoch_drain_callbacks) before we tear it fully down.

However, the index in ifindex_table is not removed, so m_rcvif_restore()
can still find the (now dying) interface.

This results in panics, for example when dummynet restores the rcvif
pointer and passes a packet to ip6_input() we can panic because the
AF_INET6 domain has already been removed (so we end up dereferencing a
NULL pointer there).

Check that the interface is not dying before we restore it, which is
equivalent to checking its presence in V_ifnet, and thus ensures that
future accesses (while in NET_EPOCH) are safe.

Reviewed by:	glebius
Sponsored by:	Rubicon Communications, LLC ("Netgate")
Differential Revision:	https://reviews.freebsd.org/D34076
cgit
1c91aedf emaste Jan. 28, 2022, 10:49 p.m.
This was prompted by the recent pkexec vulnerability (CVE-2021-4034).
This change is being made on general principle for setuid/setgid
binaries and is not in response to an actual issue.

Reviewed by:	kevans, markj (both earlier)
MFC after:	1 week
Sponsored by:	The FreeBSD Foundation
Differential Revision:	https://reviews.freebsd.org/D34087
cgit
8d8b9b56 markj Jan. 28, 2022, 9:52 p.m.
- Check that catopen() succeeded before calling catclose().  musl will
  crash in the latter if the catalogue descriptor is -1.
- Keep the message catalogue open for most of sort(1)'s actual
  operation.
- Don't use catgets(3) to print error messages if catopen(3) had failed.

Reviewed by:	arichardson, emaste
MFC after:	1 week
Sponsored by:	The FreeBSD Foundation
Differential Revision:	https://reviews.freebsd.org/D34081
cgit
29d481ae jhb Jan. 28, 2022, 9:14 p.m.
Add a nested include of <sys/systm.h> for recently added assertions.
Without this, existing code (such as in drm-kmod) needs to be patched
to add the newly required header.

While here, rewrite the assertions using KASSERT().

Reviewed by:	dougm, alc, imp, kib
Differential Revision:	https://reviews.freebsd.org/D34070
cgit
2e8d1a55 jhb Jan. 28, 2022, 9:07 p.m.
When an iSCSI target session is terminated, an internal nexus reset
task is posted to abort existing tasks belonging to the session.
Previously, the ctl_io for this internal nexus reset stored a pointer
to the session in the slot that normally holds a pointer to the PDU
from the initiator that triggered the I/O request.  The completion
handler then assumed that any nexus reset I/O was due to an internal
request and fetched the session pointer (instead of the PDU pointer)
from the ctl_io.  However, it is possible to trigger a nexus reset via
an on-the-wire task management PDU.  If such a PDU were sent to the
target, then the completion handler would incorrectly treat this
request as an internal request and treat the pointer to the received
PDU as a pointer to the session instead.

To fix, allocate a dummy PDU for the internal reset task and use an
invalid opcode to differentiate internal nexus resets from resets
requested by the initiator.

PR:		260449
Reported by:	Robert Morris <rtm@lcs.mit.edu>
Reviewed by:	mav
Sponsored by:	Chelsio Communications
Differential Revision:	https://reviews.freebsd.org/D34055
cgit
b1ab9568 mhorne Jan. 28, 2022, 8:37 p.m.
Reviewed by:	imp, emaste
Sponsored by:	The FreeBSD Foundation
Differential Revision:	https://reviews.freebsd.org/D34084
cgit
99830f70 mhorne Jan. 28, 2022, 8:35 p.m.
Bye bye!

Reviewed by:	imp, emaste
Sponsored by:	The FreeBSD Foundation
Differential Revision:	https://reviews.freebsd.org/D34083
cgit
29998bf2 mav Jan. 28, 2022, 7:22 p.m.
All I/O requests through the taste consumer are synchronous, done
with g_read_data() and without any locks held.  It makes no sense
to delegate the I/O to g_down/g_up threads.

This removes many of context switches during disk retaste.

MFC after:	2 weeks
cgit
ffc1cc95 mav Jan. 28, 2022, 7:21 p.m.
The only cases when direct dispatch does not make sense is for I/O
submission from down thread and for completion from up thread.  In
all other cases, if both consumer and producer are OK about it, we
can save on context switches.

MFC after:	2 weeks
cgit
964b8f8b glebius Jan. 28, 2022, 5:51 p.m.
Last use was removed in 5adea417d49.
cgit