strfmon: Fix negative sign handling for C locale
If the locale's positive_sign and negative_sign values would both be
returned by localeconv() as empty strings, strfmon() shall behave as if
the negative_sign value was the string "-".
This occurs with the C locale. The implementation previously assigned
"0" to sign_posn (parentheses around the entire string); now it assigns
it to "1" (sign before the string) when it is undefined (CHAR_MAX).
Austin Group Defect 1199[1] is applied, changing the requirements for
the '+' and '(' flags.
[1]: https://www.austingroupbugs.net/view.php?id=1199
Reviewed by: kib
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D53913
(cherry picked from commit cf85e7034ad5640b18a3b68d6b291b7bf89bfc80)
strfmon: Add tests for Austin Group Defect 1199
Add tests for The Open Group Base Specifications Issue 8[1], Austin
Group Defect 1199[2].
Items marked with XXX represent an invalid output. These items will be
fixed in subsequent commits.
Notice that an existing test is now considered invalid.
Our locale definitions do not include int_p_sep_by_space nor
int_n_sep_by_space[3]. Those will be addressed in a subsequent commit.
However, the CLDR project defines them as "0", which causes the output
to appear as "USD123.45". If our locale definitions were to set the
international {n,p}_sep_by_space to "1", the output would display as the
expected "USD 123.45".
While here, use the SPDX license identifier and add my name to the
file.
[10 lines not shown]
strfmon: Fix negative sign handling for C locale
If the locale's positive_sign and negative_sign values would both be
returned by localeconv() as empty strings, strfmon() shall behave as if
the negative_sign value was the string "-".
This occurs with the C locale. The implementation previously assigned
"0" to sign_posn (parentheses around the entire string); now it assigns
it to "1" (sign before the string) when it is undefined (CHAR_MAX).
Austin Group Defect 1199[1] is applied, changing the requirements for
the '+' and '(' flags.
[1]: https://www.austingroupbugs.net/view.php?id=1199
Reviewed by: kib
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D53913
(cherry picked from commit cf85e7034ad5640b18a3b68d6b291b7bf89bfc80)
strfmon: Add tests for Austin Group Defect 1199
Add tests for The Open Group Base Specifications Issue 8[1], Austin
Group Defect 1199[2].
Items marked with XXX represent an invalid output. These items will be
fixed in subsequent commits.
Notice that an existing test is now considered invalid.
Our locale definitions do not include int_p_sep_by_space nor
int_n_sep_by_space[3]. Those will be addressed in a subsequent commit.
However, the CLDR project defines them as "0", which causes the output
to appear as "USD123.45". If our locale definitions were to set the
international {n,p}_sep_by_space to "1", the output would display as the
expected "USD 123.45".
While here, use the SPDX license identifier and add my name to the
file.
[10 lines not shown]
strfmon: Fix negative sign handling for C locale
If the locale's positive_sign and negative_sign values would both be
returned by localeconv() as empty strings, strfmon() shall behave as if
the negative_sign value was the string "-".
This occurs with the C locale. The implementation previously assigned
"0" to sign_posn (parentheses around the entire string); now it assigns
it to "1" (sign before the string) when it is undefined (CHAR_MAX).
Austin Group Defect 1199[1] is applied, changing the requirements for
the '+' and '(' flags.
[1]: https://www.austingroupbugs.net/view.php?id=1199
Reviewed by: kib
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D53913
(cherry picked from commit cf85e7034ad5640b18a3b68d6b291b7bf89bfc80)
strfmon: Add tests for Austin Group Defect 1199
Add tests for The Open Group Base Specifications Issue 8[1], Austin
Group Defect 1199[2].
Items marked with XXX represent an invalid output. These items will be
fixed in subsequent commits.
Notice that an existing test is now considered invalid.
Our locale definitions do not include int_p_sep_by_space nor
int_n_sep_by_space[3]. Those will be addressed in a subsequent commit.
However, the CLDR project defines them as "0", which causes the output
to appear as "USD123.45". If our locale definitions were to set the
international {n,p}_sep_by_space to "1", the output would display as the
expected "USD 123.45".
While here, use the SPDX license identifier and add my name to the
file.
[10 lines not shown]
LinuxKPI: device: add a pr_debug("TODO") call to device_release_driver()
The logic in device_release_driver() got disabled in 93b14194acaf2
and since left alone. Add a pr_debug() call so we have a chance to
notice if that code is actually still in need to be fixed and re-enabled.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
LinuxKPI: 802.11: make airtime fairness an IMPROVE
We are ways away from implementing "airtime fairness" in LinuxKPI
(or rather net80211). For now make it an 'improve' rather than a
'todo' to get the logging away. Everything will work without it.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
LinuxKPI: 802.11: when synching HT and VHT cap, mask rx_mcs
When we sync the sta data, mask the rx_mcs with what the hardware is
able to do so that we do not leave, e.g., a 2nd stream enabled on a 1x1
chipset.
iwlwifi(4) has a further check for the smps_mode to limit to NSS=1 but
I believe that is historic and not actually in use anymore.
This fixes firmware crashes on TLC updates with nss=1 but the nss=2 array
index also being populated (with HT/VHT80/160 mcs information):
data being populated:
iwlwifi0: 0x20101A0D | ADVANCED_SYSASSERT
iwlwifi0: 0x00000006 | umac data1
iwlwifi0: 0x00000001 | umac data2
iwlwifi0: 0x000003FF | umac data3
iwlwifi0: 0x____050F | last host cmd
Reported by: Claudio Zumbo (claudiozumbo gmail.com), Erik Power
Tested by: Claudio Zumbo, Erik Power (eppower umich.edu)
[3 lines not shown]
LinuxKPI: pci: undo the pci_resource_len() check in lkpi_pci_request_region()
Creating non-passthru SR-IOV interfaces on a mlx5en(4) failed.
The problem lies in the pci_resource_len() call but not that the BAR length
is tmeporary 0 but in that we call lkpi_pci_get_bar() with a true argument
which will create the BAR resource for us and report the approriate length
back. However, the later call to bus_alloc_resource_any() will then fail
given the resource already exists.
Restore the previous behaviour and let bus_alloc_resource_any() do the
work. Adjust the return values from -ENODEV to -EBUSY to match callers
expectations.
In linuxkpi_pcim_request_all_regions(), like in linuxkpi_pci_request_regions(),
filter out the -EBUSY errors as "not an error" and try the next bar.
This also seems to be consistent with the expectations of the callers.
PR: 290793
Reported by: David BOYER (jcduss13 gmail.com)
[6 lines not shown]
nvme: Use memcpy instead of memmove in nvme_cdata_get_disk_ident
These buffers should not overlap.
Reviewed by: imp
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D53842
ipfilter: Load optionlist prior to ippool invocation
As a safety precaution df381bec2d2b limits ippool hash table size to 1K.
This causes any legitimely large hash table to fail to load. The
htable_size_max ipf tuneable adjusts this but the adjustment is made
in the ipfilter rc script, invoked after the ippool script (because it
depends on ippool). Let's load the ipfilter_optionlist in ippool as well.
ipfilter_optionlist load will also occur in the ipfilter rc script in case
the user uses ipfilter without ippool.
Fixes: df381bec2d2b
(cherry picked from commit d5d005e9bf4933d5680dd0bb5d42bdf440122aa4)
ipfilter: Load optionlist prior to ippool invocation
As a safety precaution df381bec2d2b limits ippool hash table size to 1K.
This causes any legitimely large hash table to fail to load. The
htable_size_max ipf tuneable adjusts this but the adjustment is made
in the ipfilter rc script, invoked after the ippool script (because it
depends on ippool). Let's load the ipfilter_optionlist in ippool as well.
ipfilter_optionlist load will also occur in the ipfilter rc script in case
the user uses ipfilter without ippool.
Fixes: df381bec2d2b
(cherry picked from commit d5d005e9bf4933d5680dd0bb5d42bdf440122aa4)
ipfilter: Load optionlist prior to ippool invocation
As a safety precaution df381bec2d2b limits ippool hash table size to 1K.
This causes any legitimely large hash table to fail to load. The
htable_size_max ipf tuneable adjusts this but the adjustment is made
in the ipfilter rc script, invoked after the ippool script (because it
depends on ippool). Let's load the ipfilter_optionlist in ippool as well.
ipfilter_optionlist load will also occur in the ipfilter rc script in case
the user uses ipfilter without ippool.
Fixes: df381bec2d2b
(cherry picked from commit d5d005e9bf4933d5680dd0bb5d42bdf440122aa4)
vmm: Fix a deadlock between vm_smp_rendezvous() and vcpu_lock_all()
vm_smp_rendezvous() invokes a callback on all vCPUs, blocking the
initiator until all vCPUs have responded. vcpu_lock_all() blocks each
vCPU by waiting for it to go idle and setting the vCPU state to frozen.
These two operations can deadlock on each other, particularly when
booting a Windows guest, when vcpu_lock_all() blocks waiting for a
rendezvous initiator, and the initiator is blocked waiting for the vCPU
thread which called vcpu_lock_all() to invoke the rendezvous callback.
Implement vcpu_lock_all() in a way that avoids deadlocks with
vm_smp_rendezvous(). In particular, when traversing vCPUs, invoke the
rendezvous callback on the vCPU's behalf to help the initiator finish.
We can only safely do so when the vCPU is IDLE or we have already locked
it, otherwise we may be racing with the target vCPU thread. Thus:
- Use an exclusive lock to serialize vcpu_lock_all() callers, which lets
us lock vCPUs out of order without fear of deadlock with parallel
vcpu_lock_all() callers.
- If a rendezvous is pending, lock all idle vCPUs and invoke the
[16 lines not shown]
powerpc/_stdint.h: fix SIG_ATOMIC_{MIN,MAX,WIDTH}
On powerpc/powerpc64, sig_atomic_t is an int, but was treated as if
it was a long by <machine/_stdint.h>. This was finally caught by the
unit test added with 4a1c752 / D53831.
Reported by: kib
Reviewed by: kib, imp
Approved by: markj (mentor)
Fixes: c3e289e1ce8c9af8d14e9f727632e22b3bf901f9
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D54026
