[PowerPC] Fix libllvmminimal build when building from powerpc64 ELFv1.
When bootstrapping on powerpc64 ELFv1, it is necessary to use binutils
ld.bfd from ports for the bootstrap, as this is the only modern linker for
ELFv1 host tools.
As binutils ld.bfd is rather strict in its handling of undefined symbols,
it is necessary to pull in Support/Atomic.cpp to avoid an undefined symbol.
Add one additional file to libllvmminimal, to help the ppc64 bootstrap.
Reported by: bdragon
PR: 244251
MFC r358857:
Move another file in libllvm from sources required for world, to sources
required for bootstrap, as the PowerPC builds need this.
Reported by: bdragon
PR: 244251
MFC r358907:
Allow -DNO_CLEAN build across r358851.
The openmp 10.0.0 import renamed one .c file to .cpp, and this is
something our dependency system does not handle correctly. Add another
ad-hoc cleanup to get rid of the stale dependency.
PR: 244251
MFC r358909 (by emaste):
Extend r358907 to explicitly remove stale lib32 dependency
After r325072 stale lib32 dependencies were not remooved. A more
holistic approach is needed to address this but for the immediate issue
(-DNO_CLEAN builds across r358851) just readd the explicit lib32 path.
Reported by: dim
Sponsored by: The FreeBSD Foundation
MFC r358910 (by emaste):
Makefile.inc1: move dependency hack comment to the block it applies to
MFC r359035 (by emaste):
Makefile.inc1: add a note when deleting stale dependencies
We have ad-hoc stale dependency handling in Makefile.inc1 to handle the
cases where file extensions change, but it appears that some cases are
not functional. Add a note when about to clean stale deps to help
when investigating failure reports.
Sponsored by: The FreeBSD Foundation
MFC r359082:
Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp llvmorg-10.0.0-rc4-5-g52c365aa9ca. The actual release should follow Real
Soon Now.
PR: 244251
MFC after: 6 weeks
MFC r359083 (by emaste):
invoke _cleanobj_fast_depend_hack unconditionally
Apparently make ${CLEANDIR} is leaving stale entries in .depend files;
for now invoke the hacky cleanup in both the -DNO_CLEAN and normal
(no -DNO_CLEAN) cases.
In collaboration with: dim
Sponsored by: The FreeBSD Foundation
MFC r359084:
Merge commit 00925aadb from llvm git (by Fangrui Song):
[ELF][PPC32] Fix canonical PLTs when the order does not match the PLT order
Merge commit b8ebc11f0 from llvm git (by Sanjay Patel):
[EarlyCSE] avoid crashing when detecting min/max/abs patterns (PR41083)
As discussed in PR41083:
https://bugs.llvm.org/show_bug.cgi?id=41083
...we can assert/crash in EarlyCSE using the current hashing scheme
and instructions with flags.
ValueTracking's matchSelectPattern() may rely on overflow (nsw, etc)
or other flags when detecting patterns such as min/max/abs composed
of compare+select. But the value numbering / hashing mechanism used
by EarlyCSE intersects those flags to allow more CSE.
Several alternatives to solve this are discussed in the bug report.
This patch avoids the issue by doing simple matching of min/max/abs
patterns that never requires instruction flags. We give up some CSE
power because of that, but that is not expected to result in much
actual performance difference because InstCombine will canonicalize
these patterns when possible. It even has this comment for abs/nabs:
/// Canonicalize all these variants to 1 pattern.
/// This makes CSE more likely.
(And this patch adds PhaseOrdering tests to verify that the expected
transforms are still happening in the standard optimization
pipelines.
I left this code to use ValueTracking's "flavor" enum values, so we
don't have to change the callers' code. If we decide to go back to
using the ValueTracking call (by changing the hashing algorithm
instead), it should be obvious how to replace this chunk.
Fix -Wdeprecated-copy-dtor and -Wdeprecated-dynamic-exception-spec
warnings.
Summary:
The former are like:
libcxx/include/typeinfo:322:11: warning: definition of implicit copy
constructor for 'bad_cast' is deprecated because it has a
user-declared destructor [-Wdeprecated-copy-dtor]
virtual ~bad_cast() _NOEXCEPT;
^
libcxx/include/typeinfo:344:11: note: in implicit copy constructor
for 'std::bad_cast' first required here
throw bad_cast();
^
Fix these by adding an explicitly defaulted copy constructor.
The latter are like:
libcxx/include/codecvt:105:37: warning: dynamic exception
specifications are deprecated [-Wdeprecated-dynamic-exception-spec]
virtual int do_encoding() const throw();
^~~~~~~
This is because we use -Wsystem-headers during buildworld, and the two
warnings above are now triggered by default with clang 10, preventing
most C++ code from compiling without NO_WERROR.
r359083 introduced a workaround for stale libomp dependencies during a
regular (no -DNO_CLEAN) buildworld. r359088 addressed the reason the
clean step missed libomp, so revert the workaround.
Sponsored by: The FreeBSD Foundation
MFC r359333:
Merge commit f0990e104 from llvm git (by Justin Hibbits):
[PowerPC]: e500 target can't use lwsync, use msync instead
The e500 core has a silicon bug that triggers an illegal instruction
program trap on any sync other than msync. Other cores will typically
ignore illegal sync types, and the documentation even implies that
the 'illegal' bits are ignored.
Address this hardware deficiency by only using msync, like the PPC440.
Merge commit 459e8e948 from llvm git (by Justin Hibbits):
[PowerPC]: Don't allow r0 as a target for LD_GOT_TPREL_L/32
Summary:
The linker is free to relax this (relocation R_PPC_GOT_TPREL16)
against R_PPC_TLS, if it sees fit (initial exec to local exec). If r0
is used, this can generate execution-invalid code (converts to 'addi
%rX, %r0, FOO, which translates in PPC-lingo to li %rX, FOO). Forbid
this instead.
This fixes static binaries using locales on FreeBSD/powerpc (tested
on FreeBSD/powerpcspe).
With liblua in the tree we should be able to enable lldb's lua
scripting. We'll need the files in bindings/, so start by allowing them
to come in with the next import.
Approved by: dim
Sponsored by: The FreeBSD Foundation
MFC r359578:
Merge once more from ^/vendor/llvm-project/release-10.x, to get the
lldb/bindings directory, which will be used to provide lua bindings for
lldb.
Requested by: emaste
MFC r359826:
Merge commit 30588a739 from llvm git (by Erich Keane):
Make target features check work with ctor and dtor-
The problem was reported in PR45468, applying target features to an
always_inline constructor/destructor runs afoul of GlobalDecl
construction assert when checking for target-feature compatibility.
The core problem is fixed by using the version of the check that
takes a FunctionDecl rather than the GlobalDecl. However, while
writing the test, I discovered that source locations weren't properly
set for this check on ctors/dtors. This patch also fixes constructors
and CALLED destructors.
Unfortunately, it doesn't seem too possible to get a meaningful
source location for a 'cleanup' destructor, so those are still
'frontend' level errors unfortunately. A fixme was added to the test
to cover that situation.
This should fix 'Assertion failed: (!isa<CXXConstructorDecl>(D) && "Use
other ctor with ctor decls!"), function Init, file
/usr/src/contrib/llvm-project/clang/include/clang/AST/GlobalDecl.h, line
45' when compiling the security/botan2 port.
PR: 245550
MFC r359981:
Revert commit a9ad65a2b from llvm git (by Nemanja Ivanovic):
[PowerPC] Change default for unaligned FP access for older subtargets
This is a fix for https://bugs.llvm.org/show_bug.cgi?id=40554
Some CPU's trap to the kernel on unaligned floating point access and
there are kernels that do not handle the interrupt. The program then
fails with a SIGBUS according to the PR. This just switches the
default for unaligned access to only allow it on recent server CPUs
that are known to allow this.
This upstream commit causes a compiler hang when building certain ports
(e.g. security/nss, multimedia/x264) for powerpc64. The hang has been
reported in https://bugs.llvm.org/show_bug.cgi?id=45186, but in the mean
time it is more convenient to revert the commit.
In the last commit, I neglected to initialize the new subtarget
feature I added which caused failures on a few bots. This should fix
that.
This unbreaks the build after r359981, which reverted upstream commit a9ad65a2b34f.
Reported by: jhibbits (and jenkins :)
MFC r360129:
Merge commit ce5173c0e from llvm git (by Reid Kleckner):
Use FinishThunk to finish musttail thunks
FinishThunk, and the invariant of setting and then unsetting
CurCodeDecl, was added in 7f416cc42638 (2015). The invariant didn't
exist when I added this musttail codepath in ab2090d10765 (2014).
Recently in 28328c3771, I started using this codepath on non-Windows
platforms, and users reported problems during release testing
(PR44987).
The issue was already present for users of EH on i686-windows-msvc,
so I added a test for that case as well.
This should fix 'Assertion failed: (!empty() && "popping exception stack
when not empty"), function popTerminate, file
/usr/src/contrib/llvm-project/clang/lib/CodeGen/CGCleanup.h, line 583'
when building the net-p2p/libtorrent-rasterbar
PR: 244830
Reported by: jbeich, yuri
MFC r360134:
Merge commit 64b31d96d from llvm git (by Nemanja Ivanovic):
[PowerPC] Do not attempt to reuse load for 64-bit FP_TO_UINT without
FPCVT
We call the function that attempts to reuse the conversion without
checking whether the target matches the constraints that the callee
expects. This patch adds the check prior to the call.
This should fix 'Assertion failed: ((Op.getOpcode() == ISD::FP_TO_SINT
|| Subtarget.hasFPCVT()) && "i64 FP_TO_UINT is supported only with
FPCVT"), function LowerFP_TO_INTForReuse, file
/usr/src/contrib/llvm/lib/Target/PowerPC/PPCISelLowering.cpp, line 7276'
when building the devel/libslang2 port (and a few others) for PowerPC64.
Requested by: pkubaj
MFC r360350:
Tentatively apply https://reviews.llvm.org/D78877 (by Dave Green):
[ARM] Only produce qadd8b under hasV6Ops
When compiling for a arm5te cpu from clang, the +dsp attribute is
set. This meant we could try and generate qadd8 instructions where we
would end up having no pattern. I've changed the condition here to be
hasV6Ops && hasDSP, which is what other parts of ARMISelLowering seem
to use for similar instructions.
Fixed PR45677.
This fixes "fatal error: error in backend: Cannot select: t37: i32 =
ARMISD::QADD8b t43, t44" when compiling sys/dev/sound/pcm/feeder_mixer.c
for armv5. For some reason we do not encounter this on head, but this
error popped up while building universes for stable/12.
Dimitry Andric [Fri, 1 May 2020 18:27:14 +0000 (18:27 +0000)]
MFC r360322:
Fix race between prebuilding libsbuf and libgeom
The latter needs the former, but with a multi-job build on a fast
machine, the race is sometimes lost. This leads to "ld: error: unable to
find library -lsbuf", when linking libgeom.so.
MFC r360196:
Factor code in LinuxKPI to allow attach and detach using any BSD device.
This allows non-LinuxKPI based infiniband device drivers to attach
correctly to ibcore.
MFC r355423: UPDATING: Add [less] long-belated note about certs in base
While the interaction between this and the ETCSYMLINK option of
security/ca_root_nss isn't necessarily fatal, one should be aware and
attempt to understand the ramifications of mixing the two.
ports-secteam will be contacted to discuss the default option for branches
where certs are being included in base.
John Baldwin [Wed, 29 Apr 2020 16:04:59 +0000 (16:04 +0000)]
MFC 350069: Use PT_GET_SC_ARGS and PT_GET_SC_RET in truss.
This removes all of the architecture-specific functions from truss.
A per-ABI structure is still needed to map syscall numbers to names
and FreeBSD errno values to ABI error values as well as hold syscall
counters. However, the linker set of ABI structures is now replaced
with a simple table mapping ABI names to structures. This approach
permits sharing the same ABI structure among separate names such as
i386 a.out and ELF binaries as well as ELF v1 vs ELF v2 for powerpc64.
A few differences are visible due to using PT_GET_SC_RET to fetch the
error value of a system call. Note that ktrace/kdump have had the
"new" behaviors for a long time already:
- System calls that return with EJUSTRETURN or ERESTART will now be
noticed and logged as such. Previously sigreturn (which uses
EJUSTRETURN) would report whatever random value was in the register
holding errno from the previous system call for example. Now it
reports EJUSTRETURN.
- System calls that return errno as their error value such as
posix_fallocate() and posix_fadvise() now report non-zero return
values as errors instead of success with a non-zero return value.
Brooks Davis [Tue, 28 Apr 2020 17:59:37 +0000 (17:59 +0000)]
MFC r359937:
Centralize compatability translation macros.
Copy the CP, PTRIN, etc macros from freebsd32.h into a sys/abi_compat.h
and replace existing definitation with includes where required. This
eliminates duplicate code and allows Linux and FreeBSD compatability
headers to be included in the same files.
John Baldwin [Tue, 28 Apr 2020 15:44:39 +0000 (15:44 +0000)]
MFC 350017: Add ptrace op PT_GET_SC_RET.
This ptrace operation returns a structure containing the error and
return values from the current system call. It is only valid when a
thread is stopped during a system call exit (PL_FLAG_SCX is set).
The sr_error member holds the error value from the system call. Note
that this error value is the native FreeBSD error value that has _not_
been translated to an ABI-specific error value similar to the values
logged to ktrace.
If sr_error is zero, then the return values of the system call will be
set in sr_retval[0] and sr_retval[1].
Brooks Davis [Mon, 27 Apr 2020 23:47:40 +0000 (23:47 +0000)]
MFC r359978:
Fix -Wvoid-pointer-to-enum-cast warnings.
This pattern is used in callbacks with void * data arguments and seems
both relatively uncommon and relatively harmless. Silence the warning
by casting through uintptr_t.
MFC r357875: diff: fix segfault with --tabsize and no/malformed argument
--tabsize was previously listed as optional_argument, but didn't account for
the optionality of it in the argument handling. This is irrelevant -- the
manpage doesn't indicate that the argument is optional, and indeed there's
no clear interpretation of omitting the argument because there's no other
side effect of --tabsize.
The "malformed" argument part of the header on this message is simply
referring to usage like this:
% diff --tabsize 4 A B
With an optional_argument, the argument must be attached to the parameter
directly (e.g. --tabsize=4), so the argument is effectively NULL with the
above invocation as if no argument had been passed.
MFC r360182-r360183: kqueue(2): add note about EV_RECEIPT
r360182:
kqueue(2): add a note about EV_RECEIPT
In the below-referenced PR, a case is attached of a simple reproducer that
exhibits suboptimal behavior: EVFILT_READ and EVFILT_WRITE being set in the
same kevent(2) call will only honor the first one. This is, in-fact, how
it's supposed to work.
A read of the manpage leads me to believe we could be more clear about this;
right now there's a logical leap to make in the relevant statement: "When
passed as input, it forces EV_ERROR to always be returned." -- the logical
leap being that this indicates the caller should have allocated space for
the change to be returned with EV_ERROR indicated in the events, or
subsequent filters will get dropped on the floor.
Another possible workaround that accomplishes similar effect without needing
space for all events is just setting EV_RECEIPT on the final change being
passed in; if any errored before it, the kqueue would not be drained. If we
made it to the final change with EV_RECEIPT set, then we would return that
one with EV_ERROR and still not drain the kqueue. This would seem to not be
all that advisable.
r360183:
kqueue(2): de-vandalize the random sentence in the middle
A last minute change appears to have inadvertently vandalized unrelated
parts of the manpage with the date. =-(
r356724:
asprintf returns -1, not an arbitrary value < 0. Also upon error the
(very sloppy specification) leaves an undefined value in *ret, so it is
wrong to inspect it, the error condition is enough.
r356725:
When system calls indicate an error they return -1, not some arbitrary
value < 0. errno is only updated in this case.
r357649:
Update diff(1) TODO removing what has been implemented
This matches GNU diff(1) behavior and, more importantly, eliminates any
source of confusion if multiple formatting options are specified.
Note that the committed diff differs slightly from the submitted: I've
modified it so that we initialize diff_format to something that isn't an
accepted format option so that we can also reject --normal -c and -c
--normal, which would've otherwise been accepted because the default was
--normal. After option parsing we default it to D_NORMAL if it's still
unset.
r359953:
kern uuid: break format validation out into a separate KPI
This new KPI, validate_uuid, strictly validates the formatting of the input
UUID and, optionally, populates a given struct uuid.
As noted in the header, the key differences are that the new KPI won't
recognize an empty string as a nil UUID and it won't do any kind of semantic
validation on it. Also key is that populating a struct uuid is optional, so
the caller doesn't necessarily need to allocate a bogus one on the stack
just to validate the string.
This KPI has specifically been broken out in support of D24288, which will
preload /etc/hostid in loader so that early boot hostuuid users (e.g.
anything that calls ether_gen_addr) can have a valid hostuuid to work with
once it's been stashed in /etc/hostid.
r359980:
validate_uuid: absorb the rest of parse_uuid with a flags arg
This makes the naming annoyance (validate_uuid vs. parse_uuid) less of an
issue and centralizes all of the functionality into the new KPI while still
making the extra validation optional. The end-result is all the same as far
as hostuuid validation-only goes.
r359999:
Preload hostuuid for early-boot use
prison0's hostuuid will get set by the hostid rc script, either after
generating it and saving it to /etc/hostid or by simply reading /etc/hostid.
Some things (e.g. arbitrary MAC address generation) may use the hostuuid as
a factor in early boot, so providing a way to read /etc/hostid (if it's
available) and using it before userland starts up is desirable. The code is
written such that the preload doesn't *have* to be /etc/hostid, thus not
assuming that there will be newline at the end of the buffer or even the
exact shape of the newline. White trailing whitespace/non-printables
trimmed, the result will be validated as a valid uuid before it's used for
early boot purposes.
The preload can be turned off with hostuuid_load="NO" in /boot/loader.conf,
just as other preloads; it's worth noting that this is a 37-byte file, the
overhead is believed to be generally minimal.
It doesn't seem necessary at this time to be concerned with kern.hostid.
One does wonder if we should consider validating hostuuids coming in
via jail_set(2); some bits seem to care about uuid form and we bother
validating format of smbios-provided uuid and in-fact whatever uuid comes
from /etc/hostid.
Certs can be easily examined after installation with `certctl list`, and
certctl blacklist will accept the hashed filename as output by list or as
seen in /etc/ssl/certs
r355376:
caroot update to latest tip: one (1) addition, none (0) removed
With the inclusion of caroot bits, we'll need to also rehash on update as we
do in mergemaster/etcupdate.
If certctl's installed on the system, just unconditionally rehash. This
isn't an expensive operation, and we can refine it to compare
INDEX-{OLD,NEW} later if we really want to.
John Baldwin [Mon, 27 Apr 2020 20:37:11 +0000 (20:37 +0000)]
MFC 350013: Don't pass error from syscallenter() to syscallret().
syscallret() doesn't use error anymore. Fix a few other places to permit
removing the return value from syscallenter() entirely.
- Remove a duplicated assertion from arm's syscall().
- Use td_errno for amd64_syscall_ret_flush_l1d.
MFC r359702, r359774: enforce -fno-common for userland/kernel src builds
r359702:
Add -fno-common to all userland/kernel src builds
-fno-common will become the default in GCC10/LLVM11. Plenty of work has been
put in to make sure our world builds are no -fno-common clean, so let's slap
the build with this until it becomes the compiler default to ensure we don't
regress.
At this time, we will not be enforcing -fno-common on ports builds. I
suspect most ports will be or quickly become -fno-common clean as they're
naturally built against compilers that default to it, so this will hopefully
become a non-issue in due time. The exception to this, which is actually the
status quo, is that kmods built from ports will continue to build with
-fno-common.
As of the time of writing, I intend to also make stable/12 -fno-common
clean. What's been done will be MFC'd to stable/11 if it's easily applicable
and/or not much work to massage it into being functional, but I anticipate
adding -fcommon to stable/11 builds to maintain its ability to be built with
newer compilers for the rest of its lifetime instead of putting in a third
branch's worth of effort.
r359774:
userland build: replace -fno-common with ${CFCOMMONFLAG}
This change allows any downstream or otherwise consumer to easily override
the new -fno-common default on a temporary basis without having to hack into
src.sys.mk, and also makes it a bit easier to search for these specific
cases where -fno-common must be overridden with -fcommon or else the build
will fail.
The gdb build, the only program requiring -fcommon on head/, is switched
over as an example usage. It will need it on all branches, so this does not
harm future mergability.
MFC r359642: adduser: allow standard IFS characters in passwords
Notably, the default IFS contains space/tab, thus any leading/trailing
whitespace characters tend to be removed.
Set IFS= for just the read lines to mitigate this, allowing the user to be
less surprised when their leading/trailing spaces weren't actually captured
in the password as they are with other means of setting a user's password.
[Neither of these originally mine, but the latter commit referenced
fixes an -fno-common issue and the former is a bugfix]
r340361:
Fix printing of 64-bit counters on 32-bit ppc platforms.
Several statistic counters are uint64_t values and are printed by systat
using %lu. This results in displaying wrong numbers. Use PRIu64 instead.
While there, print variables of size_t using %zd.
r345804:
systat -zarc to display disk activities like -vm
Alexander Motin [Mon, 27 Apr 2020 14:03:24 +0000 (14:03 +0000)]
MFC r360123: Allow namespace-id specification where it makes sense.
It makes tool more convenient to not require user to explicitly convert
namespace device name into controller device name. There should be no
changes to already existing syntaxes.
John Baldwin [Mon, 27 Apr 2020 04:47:02 +0000 (04:47 +0000)]
MFC 350012: Always set td_errno to the error value of a system call.
Early errors prior to a system call did not set td_errno. This commit
sets td_errno for all errors during syscallenter(). As a result,
syscallret() can now always use td_errno without checking TDP_NERRNO.
Compared to the original commit, this change preserves the ABI of
struct thread and instead adds explicit zero'ing of td_errno.
Both DIOCCHANGEADDR and DIOCADDADDR take a struct pf_pooladdr from
userspace. They failed to validate the dyn pointer contained in its
struct pf_addr_wrap member structure.
This triggered assertion failures under fuzz testing in
pfi_dynaddr_setup(). Happily the dyn variable was overruled there, but
we should verify that it's set to NULL anyway.
Add casts to work around harmless -Werror warnings from clang 10.0.0,
such as:
usr.sbin/timed/timed/networkdelta.c:160:13: error: implicit conversion from 'long' to 'float' changes value from 9223372036854775807 to 9223372036854775808
[-Werror,-Wimplicit-int-float-conversion]
float ap = LONG_MAX; /* bounds on the median */
~~ ^~~~~~~~
Direct commit to stable/{10,11,12}, since timed has been removed from
FreeBSD 13.
The MIPS bug was introduced by upstream commit 7403cb630, which failed
to account for the additional indirection introduced and also dropped
one of the checks; change it to the standard "NULL-or-empty" check as
used elsewhere in BFD, which is also what upstream now has.
Ed Maste [Sat, 25 Apr 2020 15:29:06 +0000 (15:29 +0000)]
MFC r359777: hdac: show which command timed out
There are several reports of "hdac0: Command timeout on address 2"
messages emitted during playback on a variety of contemporary machines.
Show the command that timed out in case it might provide a clue in
finding the cause.
Fix some misleading indentation warnings reported by recent clang.
These should not be any functional change. While the change in
emul10kx-pcm.c looks like a real bug fix (as opposed to inconsistent
whitespace), the extra statements were not harmful.
g++9 now warns about having defined an assignment operator but using the
default copy constructor, or vice versa. Avoid the issue in libdevdctl
by just using the default assignment operator too.
MIPS64 has 64-bit longs, so use uint64_t for it, otherwise uint32_t.
sizeof(long) == sizeof(ptr) for all platforms, so define
atomic_swap_ptr in terms of atomic_swap_long.
ethersubr: Make the mac address generation more robust
If we create two (vnet) jails and create a bridge interface in each we end up
with the same mac address on both bridge interfaces.
These very often conflicts, resulting in same mac address in both jails.
Mitigate this problem by including the jail name in the mac address.
According to my tests and errata to several generations of Intel CPUs,
PCIe hot-plug command completion reporting is not very reliable thing.
At least on my Supermicro X11DPi-NT board I never saw it reported.
Before this change timeout code detached devices and tried to disable
the slot, that in my case resulted in hot-plugged device being detached
just a second after it was successfully detected and attached. This
change removes that, so in case of timeout it just prints the error and
continue operation. Linux does the same.
Userspace may pass a negative ps_len value to us, which causes an
assertion failure in malloc().
Treat negative values as zero, i.e. return the required size.
Alexander Motin [Fri, 24 Apr 2020 15:02:05 +0000 (15:02 +0000)]
MFC r359667 (by mw): Add hwpmc support for Intel Atom Goldmont microarchitecture
Recognize new micro-architecture in hwpmc_intel driver. Based on Intel
document 325462-071US. Tested with tools/test/hwpmc/pmctest.py
on Atom E3930 SoC.
- amd_intr() does not account for the offset (0x200) in the counter
MSR address and ends up accessing invalid regions while reading
counter value after the 4th counter (0xC001000[8,9,..]) and
erroneously updates the counter values for counters [1-4].
- amd_intr() should only check core pmcs for interrupts since
other types of pmcs (L3,DF) cannot generate interrupts.
- fix pmc NMI's being ignored due to NMI latency on newer AMD processors
Note that this fixes a kernel panic due to GPFs accessing MSRs on
higher core count AMD cpus (seen on both Rome 7502P, and
Threadripper 2990WX 32-core CPUs)
MFC r360051: tty: convert tty_lock_assert to tty_assert_locked
A later change, currently being iterated on in D24459, will in-fact change
the lock type to an sx so that TTY drivers can sleep on it if they need to.
Committing this ahead of time to make the review in question a little more
palatable.
tty_lock_assert() is unfortunately still needed for now in two places to
make sure that the tty lock has not been recursed upon, for those scenarios
where it's supplied by the TTY driver and possibly a mutex that is allowed
to recurse.
MFC r360033, r360108: better precision in kqueue timer tests
r360033:
tests: kqueue: use a more precise timer for the NOTE_ABSTIME test
Originally noticed while attempting to run the kqueue tests under
qemu-user-static, this apparently just happens sometimes when running in a
jail in general -- the timer will fire off "too early," but it's really just
the result of imprecise measurements (noted by cem).
Kicking this over to NOTE_USECONDS still tests the correct thing while
allowing it to work more consistently; a basic sanity test reveals that we
often end up coming in just less than 200 microseconds after the timer
fired off.
r360108:
tests: kqueue: fix some issues with now() on ILP32 platforms
There were ultimately two separate problems here:
- a 32-bit long cannot represent microseconds since 1970 (noted by ian)
- time_t is 32-bit on i386, so now() was wrong anyways even with the correct
return type.
For the first, just explicitly use a uint64_t for now() and all of the
callers. For the second, we need to explicitly cast tv_sec to uint64_t
before it gets multiplied in the SEC_TO_US macro. Casting this instance
rather than generally in the macro was arbitrarily chosen simply because all
other uses are converting small relative time values.
The tests now pass on i386, at least; presumably other ILP32 will be fine
now as well.
r360140:
kqueue: fix conversion of timer data to sbintime
This unbreaks the i386 kqueue timer tests after a recent change switched
NOTE_ABSTIME over to using microseconds. Notably, the data argument (which
holds useconds) is an int64_t, but we were passing it to timer2sbintime
which takes an intptr_t. Perhaps in a previous incarnation, intptr_t would
have made sense, but now it just leads to the timestamp getting truncated
and subsequently rejected when it no longer fits in an intptr_t.
r360155:
kevent32: fix the split of data into data1/data2
The current situation results in intermittent breakage if data gets split up
with the sign bit set on the data1 half of it, as PAIR32TO64 will then:
data1 | (data2 << 32) -> resulting in data1 getting sign-extended when it's
implicitly widened and clobbering the result. AFAICT, there's no compelling
reason for these to be signed.
This was most exposed by flakiness in the kqueue timer tests under compat32
after the ABSTIME test got switched over to using a better clock and
microseconds.
Rick Macklem [Wed, 22 Apr 2020 21:08:08 +0000 (21:08 +0000)]
MFC: r359720
Fix an interoperability issue w.r.t. the Linux client and the NFSv4 server.
Luoqi Chen reported a problem on freebsd-fs@ where a Linux NFSv4 client
was able to open and write to a file when the file's permissions were
not set to allow the owner write access.
Since NFS servers check file permissions on every write RPC, it is standard
practice to allow the owner of the file to do writes, regardless of
file permissions. This provides POSIX like behaviour, since POSIX only
checks permissions upon open(2).
The traditional way NFS clients handle this is to check access via the
Access operation/RPC and use that to determine if an open(2) on the
client is allowed.
It appears that, for NFSv4, the Linux client expects the NFSv4 Open (not a
POSIX open) operation to fail with NFSERR_ACCES if the file is not being
created and file permissions do not allow owner access, unlike NFSv3.
Since both the Linux and OpenSolaris NFSv4 servers seem to exhibit this
behaviour, this patch changes the FreeBSD NFSv4 server to do the same.
A sysctl called vfs.nfsd.v4openaccess can be set to 0 to return the
NFSv4 server to its previous behaviour.
Since both the Linux and FreeBSD NFSv4 clients seem to exhibit correct
behaviour with the access check for file owner in Open enabled, it is enabled
by default.
projects / FreeBSD / FreeBSD.git / log