fusefs: make the tests more robust to changes to maxphys
Remove assumptions in two test cases that maxphys won't be huge.
Reported by: kib
MFC after: 2 weeks
Sponsored by: Axcient
adduser: Fix confusion between `uclass` and `_class`.
This caused adduser to produce an invalid `pw(8)` command line. Due to
bugs in `pw(8)`, the command line was silently accepted and led to the
user being created, but locked out and with no home directory.
Also fix the default value for the “Another user?” prompt.
Fixes: 170d0882903e
MFC after: 3 days
Reviewed by: karels, allanjude
Differential Revision: https://reviews.freebsd.org/D45098
(cherry picked from commit 46c4e86ebf1819fc09084c8aa79423d96fcaad4a)
(cherry picked from commit e121845426c8d587491370432de0657099a22843)
Approved by: re (cperciva)
Update example from gcc6 to gcc13
We only "support" gcc12 and gcc13 for cross building, for some value of
"support". Update the example from gcc6 to gcc13.
Sponsored by: Netflix
sched: Simplify sched_lend_user_prio_cond()
If 'td_lend_user_pri' has the expected value, there is no need to check
the fields that sched_lend_user_prio() modifies, they either are already
good or soon will be ('td->td_lend_user_pri' has just been changed by
a concurrent update).
Reviewed by: kib
Approved by: emaste (mentor)
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D44050
(cherry picked from commit aeff15b392e68f5f193fff3bb01728b965cacc3a)
Approved by: emaste (mentor)
PP mutexes: lock: Reduce 'umtx_lock' holding before taking the user lock
There is no need to have it for the priority check (that the thread
doesn't have a higher priority than the mutex's ceiling), and there's
also no need to take it if the thread doesn't have privileges to set its
priority to the mutex's ceiling.
While here, turn 'su' into a 'bool' and compute the internal priority
corresponding to the mutex's ceiling once and for all, putting it in new
'new_pri'.
Reviewed by: kib
Approved by: emaste (mentor)
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D44045
(cherry picked from commit 39e4665c9694b9f9b07d1cfa85befc288cabe906)
Approved by: emaste (mentor)
PP mutexes: lock: Check if priority is too high against base one
Doing this instead of using the current (user) priority, which includes
current lendings, prevents gratuitous failures for threads involved in
multiple locking groups, where each group is defined as the threads that
can lock a particular PP or PI mutex. No deadlock can occur in this
case. Indeed, if a thread holds such a lock A giving it a higher
priority than the ceiling of some other lock B that is PP, and B is
acquired by another thread, effectively the latter may not be able to
run but this situation can only last until the first thread releases A,
which it will do eventually.
Reviewed by: kib
Approved by: emaste (mentor)
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D44044
(cherry picked from commit 9ac3ac9ece6269365ac314fa5fdb484e96d4a32e)
[2 lines not shown]
PP mutexes: unlock: Reset inherited prio regardless of privileges
'uq_inherited_pri' contains the current priority inherited from Priority
Protection mutexes. If -1 is passed through 'm_ceilings[1]', meaning
that there are no such mutexes held anymore, this must be reflected into
it by setting it to PRI_MAX, regardless of whether the thread has
privilege to set realtime priorities (PRI_MAX is also obviously not
a realtime priority level). By contrast, it shall not be updated and
the computed 'new_inherited_pri' shall stay unused if the thread doesn't
have the ability to set a realtime priority, possibly keeping an older
such priority acquired previously.
Reviewed by: kib
Approved by: emaste (mentor)
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D43984
(cherry picked from commit 1df8700aa6cff7c759e90f7e507de4b8714435a4)
[2 lines not shown]
sched: Simplify sched_lend_user_prio_cond()
If 'td_lend_user_pri' has the expected value, there is no need to check
the fields that sched_lend_user_prio() modifies, they either are already
good or soon will be ('td->td_lend_user_pri' has just been changed by
a concurrent update).
Reviewed by: kib
Approved by: emaste (mentor)
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D44050
(cherry picked from commit aeff15b392e68f5f193fff3bb01728b965cacc3a)
Approved by: emaste (mentor)
PP mutexes: lock: Check if priority is too high against base one
Doing this instead of using the current (user) priority, which includes
current lendings, prevents gratuitous failures for threads involved in
multiple locking groups, where each group is defined as the threads that
can lock a particular PP or PI mutex. No deadlock can occur in this
case. Indeed, if a thread holds such a lock A giving it a higher
priority than the ceiling of some other lock B that is PP, and B is
acquired by another thread, effectively the latter may not be able to
run but this situation can only last until the first thread releases A,
which it will do eventually.
Reviewed by: kib
Approved by: emaste (mentor)
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D44044
(cherry picked from commit 9ac3ac9ece6269365ac314fa5fdb484e96d4a32e)
[2 lines not shown]
PP mutexes: lock: Reduce 'umtx_lock' holding before taking the user lock
There is no need to have it for the priority check (that the thread
doesn't have a higher priority than the mutex's ceiling), and there's
also no need to take it if the thread doesn't have privileges to set its
priority to the mutex's ceiling.
While here, turn 'su' into a 'bool' and compute the internal priority
corresponding to the mutex's ceiling once and for all, putting it in new
'new_pri'.
Reviewed by: kib
Approved by: emaste (mentor)
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D44045
(cherry picked from commit 39e4665c9694b9f9b07d1cfa85befc288cabe906)
Approved by: emaste (mentor)
PP mutexes: unlock: Reset inherited prio regardless of privileges
'uq_inherited_pri' contains the current priority inherited from Priority
Protection mutexes. If -1 is passed through 'm_ceilings[1]', meaning
that there are no such mutexes held anymore, this must be reflected into
it by setting it to PRI_MAX, regardless of whether the thread has
privilege to set realtime priorities (PRI_MAX is also obviously not
a realtime priority level). By contrast, it shall not be updated and
the computed 'new_inherited_pri' shall stay unused if the thread doesn't
have the ability to set a realtime priority, possibly keeping an older
such priority acquired previously.
Reviewed by: kib
Approved by: emaste (mentor)
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D43984
(cherry picked from commit 1df8700aa6cff7c759e90f7e507de4b8714435a4)
[2 lines not shown]
libpfctl: fix file descriptor leak
pfctl_get_rules_info() opened a netlink socket, but failed to close it again.
Fix this by factoring out the netlink-based function into a _h variant that
takes struct pfctl_handle, and implement pfctl_get_rules_info() based on that,
remembering to close the fd.
While here migrate all in-tree consumers to the _h variant.
MFC after: 3 days
Sponsored by: Rubicon Communications, LLC ("Netgate")
adduser: Fix confusion between `uclass` and `_class`.
This caused adduser to produce an invalid `pw(8)` command line. Due to
bugs in `pw(8)`, the command line was silently accepted and led to the
user being created, but locked out and with no home directory.
Also fix the default value for the “Another user?” prompt.
Fixes: 170d0882903e
MFC after: 3 days
Reviewed by: karels, allanjude
Differential Revision: https://reviews.freebsd.org/D45098
(cherry picked from commit 46c4e86ebf1819fc09084c8aa79423d96fcaad4a)
pw: Ensure group membership is not duplicated
Fix the following problem:
1. A nonexistent user, someuser, is added to somegroup in /etc/group.
2. someuser is then created with membership in somegroup.
The entry for somegroup in /etc/group will then contain
somegroup:*:12345:someuser,someuser
With this fix, the entry will be
somegroup:*:12345:someuser
PR: 238995
Reviewed by: bapt, jrm
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D41076
[2 lines not shown]
adduser: Fix confusion between `uclass` and `_class`.
This caused adduser to produce an invalid `pw(8)` command line. Due to
bugs in `pw(8)`, the command line was silently accepted and led to the
user being created, but locked out and with no home directory.
Also fix the default value for the “Another user?” prompt.
Fixes: 170d0882903e
MFC after: 3 days
Reviewed by: karels, allanjude
Differential Revision: https://reviews.freebsd.org/D45098
(cherry picked from commit 46c4e86ebf1819fc09084c8aa79423d96fcaad4a)
xen/debug: remove usage of sbuf_{clear,finish}() on drained sbuf
Using sbuf_clear() on a drained sbuf is explicitly prohibited, and using
sbuf_finish() after printing a trace leads to a single trace being printed, as
after calling sbuf_finish() further attempts to use the same sbuf will lead to
a panic.
While there also switch to using xen_emergency_print() instead of attempting to
write directly to the hypervisor console. xen_emergency_print() can be
implemented per-arch to use a different mechanism than the console hypercall
(note the default implementation still uses the console hypercall).
Fixes: df62b8a25f47 ('xen: add a handler for the debug interrupt')
Sponsored by: Cloud Software Group
Reviewed by: markj
Differential review: https://reviews.freebsd.org/D45060
Remove remnants of portsnap(8)
This was prompted by noticing that '/var/db/portsnap' still exists on
newly-installed machines.
With this change, all mentions of portsnap(8) in the tree are gone,
except for the historical note in the AUTHORS section of manpage
phttpget(8).
locate(1) will thus start indexing again '/var/db/portsnap' on machines
where this directory still exists, which may be a good way to push
administrators to delete it.
Reviewed by: cperciva
Approved by: emaste (mentor)
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D45023
[21 lines not shown]
release: make dependencies, not recursive make
For historical reasons, the vm-release and cloudware-release targets
were written as recursive makes of ${VMTARGETS} and ${CLOUDTARGETS};
this worked fine until we started running `make release -jN` and
had both VM and cloud targets depending on ${QEMUTGT}, at which
point things exploded when we tried to build the port twice at the
same time.
Switch vm-release and cloudware-release to have make dependencies on
their individual components; this way a single make process runs and
is aware of the duplicate dependency (and only runs it once).
MFC after: 5 days
Remove remnants of portsnap(8)
This was prompted by noticing that '/var/db/portsnap' still exists on
newly-installed machines.
With this change, all mentions of portsnap(8) in the tree are gone,
except for the historical note in the AUTHORS section of manpage
phttpget(8).
locate(1) will thus start indexing again '/var/db/portsnap' on machines
where this directory still exists, which may be a good way to push
administrators to delete it.
Reviewed by: cperciva
Approved by: emaste (mentor)
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D45023
[16 lines not shown]
net80211: add new ciphers and RSN flags
These are the rest of the ciphers and RSN flags from 802.11-2016.
* add the rest of the ciphers from 802.11-2016
* add the rest of the RSN flags from 802.11-2016
Of special interest here are the extended key ID field for supporting
>1 unicast key (to support seamless rekeying w/out dropping frames)
and the MFP (management frame protection) config bits.
This is a no-op; no code is using these new fields.
(In particular, no code in net80211 uses the RSN capability bits;
but that will change when we start on MFP support.)
Differential Revision: https://reviews.freebsd.org/D44864
net80211: add driver / crypto methods to set the hardware / software cipher suites
Drivers currently announce hardware crypto cipher support by
setting up ic_cryptocaps.
This adds two public function calls:
* ieee80211_set_software_ciphers() - set the software cipher set;
* ieee80211_set_hardware_ciphers() - set the hardware cipher set.
For now these just call into the newly crypto routines to set the ciphers.
This then adds the two crypto routines, similarly named, to set
the hardware/software cipher suite.
This is a no-op right now - wep/tkip/ccmp are already set by default
so drivers aren't required to call these routines for software
encryption, and drivers already set ic_cryptocaps for hardware
encryption.
[2 lines not shown]
wpa: Remove the now not-needed local logic to hard-code cipher support
A previous commit now exposes the supported net80211 ciphers for the
given NIC, rather than the hardware cipher list. This is going to be
especially important moving forward when we add more cipher and key
management support.
Differential Revision: https://reviews.freebsd.org/D44821
net80211: add a new field specifically for announcing specific ciphers
This dates way, way back with the original net80211 support w/ atheros chips.
The earliest chip (AR5210) had limitations supporting software encryption.
It only had the four WEP slots, and not any keycache entries. So when
trying to do CCMP/TKIP encryption would be enabled and the key slots
would have nothing useful in them, resulting in garbage encryption/decryption.
I changed this back in 2012 to disable supporting hardware WEP for AR5210
so if_ath(4) / net80211 crypto is all done in software and yes,
I could do CCMP/TKIP on AR5210 in software.
Fast-forward to newer-ish hardware - the Qualcomm 11ac hardware.
Those also don't support pass-through keycache slots! Well, the hardware
does at that layer, but then there's a whole offload data path encap/decap
layer that's turning the frames from raw wifi into ethernet frames (for
"dumb" AP behaviours) or "wifi direct" frames (ie, "windows".)
This hides a bunch of header frame contents required for doing the software
[29 lines not shown]
nvme: Explicitly align struct nvme_command on an 8 byte boundary
This was already true for most architectures due to uint64_t structure
members. However, i386 is special in that it only requires 4 byte
alignment for uint64_t. As a result, casts from struct nvme_command
to struct nvmf_fabric_cmd were raising a "cast increases alignment"
warning on i386. Explicitly aligning struct nvme_command pacifies
this warning on i386.
Reported by: rscheff
Sponsored by: Chelsio Communications
sctp: don't provide uninitialized memory to process_chunk_drop()
Right now, the code in process_chunk_drop() does not look the
the corresponding fields.
Therefore, no functional change intended.
Reported by: Coverity Scan
CID: 1472476
MFC after: 3 days
