Use PVO_PADDR macro to get the physical address from a PVO, instead of
explicitly ANDing pvo_pte.pa with LPTE_RPGN where it is needed. Besides
improving readability, this is needed to support superpages (D25237), where
the steps to get the PA from a PVO are different.
Reviewed by: markj
Sponsored by: Eldorado Research Institute (eldorado.org.br)
Differential Revision: https://reviews.freebsd.org/D25654
read_ibdiag_config NULL deref
read_ibdiag_config mem leak
ib_mad_inv_field_str Missing comma in a string array initialization
print_node_header NULL deref
diff_node_ports copy-paste error
ibportstate.c main() missing break in switch
set_thresholds NULL ptr deref
dump_unicast_tables leaks mapnd
umad_cm_attr_str dead code
__ibv_close_device close(-1)
check return value of listen()
mlx5 bitmap.h - bad bit shift - UB
get_dst_addr check return value of inet_pton
osm_perfmgr_init check return value of cl_spinlock_init
osm_port_new memory leak on error path
sa_mad_ctrl_rcv_callback missing break in switch case
I did not include CID numbers because these were found by an internal
run at Isilon.
Reviewed by: cem kib
MFC after: 2 weeks
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D25676
The current localedef simply assumes that the locale headers on build system
are compatible with those on the target system which is not necessarily true.
It generally works on FreeBSD (as long as we don't change the locale headers),
but Linux and macOS provide completely different locale headers.
This change adds new bootstrap headers that namespace certain xlocale
structures defined or used by in the headers that localdef needs.
This is required since system headers *must* be able to include the "real"
locale headers for printf(), etc., but we also want to access the target
systems's internal locale structures.
Reviewed By: yuripv, brooks
Differential Revision: https://reviews.freebsd.org/D25229
I hit those error messages when using a localedef built against headers
that don't match the target system (cross-building from a Linux host).
This problem will be fixed in the next commit.
Generate libpmc_events.c in a temporary file first and only overwrite it
if the files are actually different.
This avoids compiling and relinking the different variants of libpmc on
every incremental build.
Reviewed By: jhb
Differential Revision: https://reviews.freebsd.org/D24784
It keeps recalculated way more often than it is needed.
Provide a routine (fdlastfile) to get it if necessary.
Consumers may be better off with a bitmap iterator instead.
The code in nfscl_dofflayout() loops when a flexible file layout server
provides a small write data limit (no extant server is known to do this).
If/when it looped, it erroneously reused the "drpc" argument for the
mirror worker thread, corrupting it.
This patch fixes the problem by only using the calling thread after the
first loop iteration.
Found during testing by simulating a server with a small write size.
Since no extant pNFS server is known to provide a small write size,
this fix it not needed in practice at this time.
MFC after: 2 weeks
Unset VIS_SAFE flag as it turned out to be actually unsafe
for continuos top display as it's passing through sequences
resulting cursor movement (backspace, tab, carriage-return),
and explicitly set VIS_TAB for the same reason.
Reported by: Mark Millard <marklmi@yahoo.com>, swills
Tested by: Mark Millard <marklmi@yahoo.com>, swills
pmc_cpuid was uninitialized for most AMD processor families. We can still
populate this string for unimplemented families.
Also added a CPUID_TO_STEPPING macro and converted existing code to use it.
Reviewed by: mav
MFC after: 2 weeks
Sponsored by: iXsystems, Inc.
Differential Revision: https://reviews.freebsd.org/D25673
That follows Linux and fixes related drm-kmod-5.3 panic.
Reviewed by: imp, hselasky
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D25657
Previously it would check 4, 3, 2, 1 lists. In practice by the time
it is getting called all lists have some elements and consequently
this does not result in new evictions.
Nonetheless, the code is clearer.
Tested by: pho
I made an attempt to fix this in r362978, but all it really did was
confine the issue to the $MACHINE_CPUARCH == "riscv" case. The real
problem is that LINKER_FEATURES is not defined here, so bsd.linker.mk
needs to be included.
This error with cleandir only occurs when META_MODE is disabled, which
explains why it was missed by both CI and myself.
Note that this effectively reverts r362978.
Reported by: mjg
Reviewed by: imp, kevans (in IRC)
.. and stuff if into the unused target vnode field
This gets rid of concurrent nc_flag modifications racing with the
shrinker and consequently fixes a bug where such a change could have
been missed when cache_ncp_invalidate was being issued..
Reported by: zeising
Tested by: pho, zeising
Fixes: r362828 ("cache: lockless forward lookup with smr")
Stop using smp_ipi_mtx to protect global shootdown state, and
move/multiply the global state into pcpu. Now each CPU can initiate
shootdown IPI independently from other CPUs. Initiator enters
critical section, then fills its local PCPU shootdown info
(pc_smp_tlb_XXX), then clears scoreboard generation at location (cpu,
my_cpuid) for each target cpu. After that IPI is sent to all targets
which scan for zeroed scoreboard generation words. Upon finding such
word the shootdown data is read from corresponding cpu' pcpu, and
generation is set. Meantime initiator loops waiting for all zeroed
generations in scoreboard to update.
Initiator does not disable interrupts, which should allow
non-invalidation IPIs from deadlocking, it only needs to disable
preemption to pin itself to the instance of the pcpu smp_tlb data.
The generation is set before the actual invalidation is performed in
handler. It is safe because target CPU cannot return to userspace
before handler finishes. In principle only NMI can preempt the
handler, but NMI would see the kernel handler frame and not touch
not-invalidated user page table.
Handlers loop until they do not see zeroed scoreboard generations.
This, together with hardware keeping one pending IPI in LAPIC IRR
should prevent lost shootdowns.
Notes.
1. The code does protect writes to LAPIC ICR with exclusion. I believe
this is fine because we in fact do not send IPIs from interrupt
handlers. More for !x2APIC mode where ICR access for write requires
two registers write, we disable interrupts around it. If considered
incorrect, I can add per-cpu spinlock around ipi_send().
2. Scoreboard lines owned by given target CPU can be padded to the
cache line, to reduce ping-pong.
Reviewed by: markj (previous version)
Discussed with: alc
Tested by: pho
Sponsored by: The FreeBSD Foundation
MFC after: 3 weeks
Differential revision: https://reviews.freebsd.org/D25510
In case of errors, the cleanup was not consistent.
Thanks to Felix Weinrank for fuzzing the userland stack and making
me aware of the issue.
MFC after: 1 week
realtime priorities
The current `ps -axO rtprio' show threads running at interrupt
priority such as the [intr] thread as '1:48' and threads running
at kernel priority such as [pagedaemon] as normal:4294967260.
This change shows [intr] as intr:48 and [pagedaemon] as kernel:4.
Reviewed by: kib
MFC after: 1 week (together with -r362369)
Differential Revision: https://reviews.freebsd.org/D25660
It can be useful to get a dump of all registers when investigating why we
received an exception that we are unable to handle. In these cases we
already call panic, however we don't always print the registers.
Add calls to print_registers and print esr and far when applicable.
Sponsored by: Innovate UK
It follows the equivalent Linux change to be able to differentiate
skylakex and cascadelakex, sharing the same model but not stepping.
This fixes skylakex handling broken by r363144.
MFC after: 6 days
EFI support is a hard requirement for generating Hyper-V Gen2 VM images.
Reviewed by: gjb
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D25655
The EIP-97 is a packet processing module found on the ESPRESSObin. This
commit adds a crypto(9) driver for the crypto and hash engine in this
device. An initial skeleton driver that could attach and submit
requests was written by loos and others at Netgate, and the driver was
finished by me.
Support for separate AAD and output buffers will be added in a separate
commit, to simplify merging to stable/12 (where those features don't
exist).
Reviewed by: gnn, jhb
Feedback from: andrew, cem, manu
MFC after: 1 week
Sponsored by: Rubicon Communications, LLC (Netgate)
Differential Revision: https://reviews.freebsd.org/D25417
We don't mention the first appearance of a utility in FreeBSD, when it first
appeared in a BSD version that predates FreeBSD.
PR: 223520, 223521
Reported by: rgrimes, imp
Reviewed by: bcr (mentor)
Approved by: bcr (mentor)
Differential Revision: https://reviews.freebsd.org/D25521
so it can be used on other IOMMU systems.
Provide MI iommu_unit, iommu_domain and iommu_ctx structs in sys/iommu.h;
use them as a first member of MD dmar_unit, dmar_domain and dmar_ctx.
Change the namespace in DMAR backend: use iommu_ prefix instead of dmar_.
Move some macroses and function prototypes to sys/iommu.h.
Reviewed by: kib
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D25574
This is mostly an exercise to set variables to NULL/0 when declared, but
one was ensuring a string variable was set before printing it.
We should never see "<unknown>" in a printed rule; if we do then this code
definitely has some bugs that need addressing.
to coalesce tx work requests.
Note that Coverity will still treat this as an out-of-bounds access. We
do want to compare 16B starting from ethmacdst but cmp_l2hdr was was
going beyond that by 2B.
cmp_l2hdr was introduced in r362905.
Reported by: Coverity (CID 1430284)
Sponsored by: Chelsio Communications
struct _ipfw_dyn_rule is defined as packed, and as a result, its
uint64_t fields are misaligned on some 32-bit platforms. Since
pr_u64() is explicitly supposed to handle this case, avoid using a
uint64_t * for the input pointer to make sure that the compiler won't
(correctly) warn about the misalignment.
Reported by: jenkins
MFC with: r363164
