Intel json's now have pretty reasonable fixed counters representation
via event=0 and umask. Hardcoded values create more confusion than fix.
MFC after: 1 month
Intel json's use event=0 to specify fixed counter number via umask.
Alternatively fixed counters have equivalent programmable event/umask.
MFC after: 1 month
This module depends on the presence of both INET and INET6 options in
order to compile.
Reviewed by: erj
Fixes: cdcd52d41e24 ("irdma: Add RDMA driver for Intel(R) Ethernet...")
Differential Revision: https://reviews.freebsd.org/D35343
The algorithm pre-allocates a cm_id since allocation cannot be done while
holding the cm.lock spinlock, however it doesn't free it on one error
path, leading to a memory leak.
Linux commit:
c14dfddbd869bf0c2bafb7ef260c41d9cebbcfec
PR: 264248
MFC after: 1 week
Sponsored by: NVIDIA Networking
mlx4_delete_all_resources_for_slave() in the resource tracker should free
all memory allocated for a slave. While releasing memory of fs_rule,
it misses releasing memory of fs_rule->mirr_mbox.
Linux commit:
461d5f1b59490ce0096dfda45e10038c122a7892
PR: 264249
MFC after: 1 week
Sponsored by: NVIDIA Networking
This file is shared with Linux. Having local style patches does not
help with updating it.
This reverts commit 3ea691c2612952dc5e6963649ad64312bd6dff4f.
Replace sigframe sf_extramask by native sigset_t and use it to
store/restore the thread signal mask without conversion to/from
Linux signal mask.
Pointy hat to: dchagin
MFC after: 2 weeks
Since l_sigset_t is 64-bit unsigned on all Linuxulators, fix the type
of a constant in the signal mask manipulation macro.
The suffix L indicates type long which is 32-bit on i386, therefore,
bitwise operations between a 32-bit constant and 64-bit signal mask
lead to the wrong result.
Pointy hat to: dchagin
MFC after: 2 weeks
On amd64 Linux saves the thread signal mask in both contexts, in the machine
dependent and in the machine independent. Both contexts are user accessible.
Convert the mask once, then copy it.
MFC after: 2 weeks
... to take into account programs and libraries which might implement
some ZFS-specific features without being exclusive to ZFS.
Reviewed by: emaste
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D35337
If one boots up multiple copies of a template VM image containing a
zpool, the pool GUIDs will be identical, making it impossible to, e.g.,
share datasets between them.
This diff introduces a simple workaround for the problem: one can use
the script to, upon first boot, assign a new GUID to one or more zpools.
This will be useful when building ZFS-based VM images from release(7).
Reviewed by: mav, allanjude, asomers
Reviewed by: Pau Amma (docs)
MFC after: 1 month
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D35336
This allows building a container image with enough functionality for
downloading and installing packages without having to include the
utilities package.
Reviewed by: manu
MFC after: 2 weeks
Since version 2 Intel CPUs can freeze PMCs when intering PMI to reduce
PMI effects on collected statistics. Since version 4 hardware supports
"streamlined" mechanism, not requiring IA_GLOBAL_CTRL MSR access.
MFC after: 1 month
We could insert proxy NDP entries by the ndp command, but the host
with proxy ndp entries had not responded to Neighbor Solicitations.
Change the following points for proxy NDP to work as expected:
* join solicited-node multicast addresses for proxy NDP entries
in order to receive Neighbor Solicitations.
* look up proxy NDP entries not on the routing table but on the
link-level address table when receiving Neighbor Solicitations.
Reviewed By: melifaro
Differential Revision: https://reviews.freebsd.org/D35307
MFC after: 2 weeks
In order to decrease ifdef INET/INET6s in the lltable implementation,
introduce the llt_post_resolved callback and implement protocol-dependent
code in the protocol-dependent part.
Reviewed By: melifaro
Differential Revision: https://reviews.freebsd.org/D35322
MFC after: 2 weeks
When some APICs are disabled by tunables, some cpu groups could end up
empty. An empty cpu group causes the system to panic because not all
functions handle them correctly. Additionally, it's wasted time to
handle and inspect empty cpu groups. Therefore, just don't create them.
Reviewed by: kib, avg, cem
Sponsored by: Beckhoff Automation GmbH & Co. KG
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D24927
x86 is cache coherent. However, there are special cases where cache
coherency isn't ensured (e.g. when switching the caching mode). In these
cases, WBINVD can be used. WBINVD writes all cache lines back into main
memory and invalidates the whole cache.
Due to the invalidation of the whole cache, WBINVD is a very heavy
instruction and degrades the performance on all cores. So, we should
minimize the use of WBINVD as much as possible.
In a virtual environment, the WBINVD call is mostly useless. The guest
isn't able to break cache coherency because he can't switch the physical
cache mode. When using pci passthrough WBINVD might be useful.
Nevertheless, trapping and ignoring WBINVD is an unsafe operation. For
that reason, we implement it as tunable.
Reviewed by: jhb
Sponsored by: Beckhoff Automation GmbH & Co. KG
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D35253
Some software uses SMBIOS entries to identify the system on which it's
running. In order to make it possible to use such software inside a VM,
SMBIOS entries should be configurable. Therefore, bhyve_config can be
used. While only a few SMBIOS entries might be of interest, it makes
sense that all SMBIOS entries are configurable. This way all SMBIOS
tables are build the same way and there's no special handling for some
tables.
Reviewed by: jhb
Sponsored by: Beckhoff Automation GmbH & Co. KG
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D34465
Commit 5218d82c81f9 added a new NFSv4.1/4.2 procedure called
AppendWrite that uses a Verify to avoid a separate Getattr RPC
for the common case where the client knows the correct file
size for O_APPEND writes.
This patch modifies nfsstat so that it displays a count of
these new RPCs for the "-E -c" option.
mount_nfs creates entries in the mounttab file and umount removes
them. Entries in the mounttab file ae used by rpc.umntall to
notify the NFS server that NFSv3 entries need to be removed when
they have not been removed by umount.
Without this patch, an enty will be created in the mounttab file,
even if the nmount(2) syscall fails for the mount. This patch
modifies the code so that the mounttab entry is only created
after nmount(2) succeeds.
This change only affects NFSv3 and only affects how showmount
displays NFSv3 mounts.
MFC after: 2 weeks
Merge commit 45084eab5e63 from llvm git (by Arthur Eubanks):
[clang] Fix some clang->llvm type cache invalidation issues
Take the following as an example
struct z {
z (*p)();
};
z f();
When we attempt to get the LLVM type of f, we recurse into z. z itself
has a function pointer with the same type as f. Given the recursion,
Clang simply treats z::p as a pointer to an empty struct `{}*`. The
LLVM type of f is as expected. So we have two different potential
LLVM types for a given Clang type. If we store one of those into the
cache, when we access the cache with a different context (e.g. we
are/aren't recursing on z) we may get an incorrect result. There is some
attempt to clear the cache in these cases, but it doesn't seem to handle
all cases.
This change makes it so we only use the cache when we are not in any
sort of function context, i.e. `noRecordsBeingLaidOut() &&
FunctionsBeingProcessed.empty()`, which are the cases where we may
decide to choose a different LLVM type for a given Clang type. LLVM
types for builtin types are never recursive so they're always ok.
This allows us to clear the type cache less often (as seen with the
removal of one of the calls to `TypeCache.clear()`). We
still need to clear it when we use a placeholder type then replace it
later with the final type and other dependent types need to be
recalculated.
I've added a check that the cached type matches what we compute. It
triggered in this test case without the fix. It's currently not
check-clang clean so it's not on by default for something like expensive
checks builds.
This change uncovered another issue where the LLVM types for an argument
and its local temporary don't match. For example in type-cache-3, when
expanding z::dc's argument into a temporary alloca, we ConvertType() the
type of z::p which is `void ({}*)*`, which doesn't match the alloca GEP
type of `{}*`.
No noticeable compile time changes:
https://llvm-compile-time-tracker.com/compare.php?from=3918dd6b8acf8c5886b9921138312d1c638b2937&to=50bdec9836ed40e38ece0657f3058e730adffc4c&stat=instructionsFixes#53465.
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D118744
PR: 264318
Reported by: mandree
MFC after: 3 days
The SO_TIMESTAMPNS enables or disables the receiving of the SCM_TIMESTAMPNS
control message. The cmsg_data field is a struct timespec.
To distinguish between SO_TIMESTAMP and SO_TIMESTAMPNS in the recvmsg()
map the last one to the SO_BINTIME and convert bintime to the timespec.
In the rest, implementation is identical to the SO_TIMESTAMP.
MFC after: 2 weeks
To solve y2k38 problem in the recvmsg syscall the new SO_TIMESTAMP
constant were added on v5.1 Linux kernel. So, old 32-bit binaries
that knows only 32-bit time_t uses the old value of the constant,
and binaries that knows 64-bit time_t uses the new constant.
To determine what size of time_t type is expected by the user-space,
store requested value (SO_TIMESTAMP) in the process emuldata structure.
MFC after: 2 weeks
