- :f_flag fails on ZFS because UF_IMMUTABLE isn't supported [1].
- :v_flag fails on ZFS because the mode for foo is [always] updated
unnecessarily.
get_filesystem(..) (supporting function that was added to the test script)
is based on equivalent logic in usr.bin/extattr/tests/extattr_test.sh .
MFC after: 1 week
PR: 221189 [1], 221188 [2]
"br" or "bridge" where - according to the terminology outlined in
comments of bridge.h and mmcbr_if.m around since their addition in
r163516 - the bus is meant and used instead. Some of these instances
are also rather old, while those in e. g. mmc_subr.c are as new as
r315430 and were caused by choosing mmc_wait_for_request(), i. e. the
one pre-r315430 outliner existing in mmc.c, as template for function
parameters in mmc_subr.c inadvertently. This correction translates to
renaming "brdev" to "busdev" and "mmcbr" to "mmcbus" respectively as
appropriate.
While at it, also rename "reqdev" to just "dev" in mmc_subr.[c,h]
for consistency with was already used in mmm.c pre-r315430, again
modulo mmc_wait_for_request() that is.
- Remove comment lines from bridge.h incorrectly suggesting that there
would be a MMC bridge base class driver.
- Update comments in bridge.h regarding the star topology of SD and SDIO;
since version 3.00 of the SDHCI specification, for eSD and eSDIO bus
topologies are actually possible in form of so called "shared buses"
(in some subcontext later on renamed to "embedded" buses).
as taking a register number, and that would get multiplied by 4 to make
a register address. But the header file that consumers have to reference
this stuff publishes register addresses, not numbers. So now everything
works in terms of register addresses.
Note that the HDMI init code was writing into the wrong register before
this change. Apparently whatever it wrote to was harmless, and apparently
HDMI was working because uboot had set up the right bits.
wide enough to hold the full 64-bit dev_t. Instead use the "dev" field in
the "linux_cdev" structure to store and lookup this value.
While at it remove superfluous use of parenthesis inside the
MAJOR(), MINOR() and MKDEV() macros in the LinuxKPI.
MFC after: 1 week
Sponsored by: Mellanox Technologies
and arm64 so move any truncation to the caller.
Submitted by: Mihai Carabas <mihai.carabas@gmail.com>
X-Differential Revision: https://reviews.freebsd.org/D10213
Similar to r321899, reduce sv_maxuser by one page inside of CloudABI.
This ensures that the stack, the vDSO and any allocations cannot touch
the top page of user virtual memory.
Considering that CloudABI userspace is completely oblivious to virtual
memory layout, don't bother making this conditional based on the CPU of
the running system.
Reviewed by: kib, truckman
Differential Revision: https://reviews.freebsd.org/D11808
Since traditional types for the macros values are int, remove the
cookie trick and just split the dev_t at the word boundary.
Reported by: Victor Stinner <victor.stinner@gmail.com>
PR: 221048
Sponsored by: The FreeBSD Foundation
when a signal is not intended to be sent.
The variable holding the signal number to send is left uninitialized,
which sometimes triggers invalid signal checks.
For NMI, a return to usermode without ast processing is done. On the
other hand, for spurious dtrace probe interrupt it is usermode which
triggered the interrupt, so handle it through userret() as any other
fault.
Reported by: Nils Beyer <nbe@renzel.net>
PR: 221151
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
directories to SUBDIR.${MK_TESTS} idiom
This is being done to pave the way for future work (and homogenity) in
^/projects/make-check-sandbox .
No functional change intended.
MFC after: 1 weeks
from the top of user memory to one page lower on machines with the
Ryzen (AMD Family 17h) CPU. This pushes ps_strings and the stack
down by one page as well. On Ryzen there is some sort of interaction
between code running at the top of user memory address space and
interrupts that can cause FreeBSD to either hang or silently reset.
This sounds similar to the problem found with DragonFly BSD that
was fixed with this commit:
https://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/b48dd28447fc8ef62fbc963accd301557fd9ac20
but our signal trampoline location was already lower than the address
that DragonFly moved their signal trampoline to. It also does not
appear to be related to SMT as described here:
https://www.phoronix.com/forums/forum/hardware/processors-memory/955368-some-ryzen-linux-users-are-facing-issues-with-heavy-compilation-loads?p=955498#post955498
"Hi, Matt Dillon here. Yes, I did find what I believe to be a
hardware issue with Ryzen related to concurrent operations. In a
nutshell, for any given hyperthread pair, if one hyperthread is
in a cpu-bound loop of any kind (can be in user mode), and the
other hyperthread is returning from an interrupt via IRETQ, the
hyperthread issuing the IRETQ can stall indefinitely until the
other hyperthread with the cpu-bound loop pauses (aka HLT until
next interrupt). After this situation occurs, the system appears
to destabilize. The situation does not occur if the cpu-bound
loop is on a different core than the core doing the IRETQ. The
%rip the IRETQ returns to (e.g. userland %rip address) matters a
*LOT*. The problem occurs more often with high %rip addresses
such as near the top of the user stack, which is where DragonFly's
signal trampoline traditionally resides. So a user program taking
a signal on one thread while another thread is cpu-bound can cause
this behavior. Changing the location of the signal trampoline
makes it more difficult to reproduce the problem. I have not
been because the able to completely mitigate it. When a cpu-thread
stalls in this manner it appears to stall INSIDE the microcode
for IRETQ. It doesn't make it to the return pc, and the cpu thread
cannot take any IPIs or other hardware interrupts while in this
state."
since the system instability has been observed on FreeBSD with SMT
disabled. Interrupts to appear to play a factor since running a
signal-intensive process on the first CPU core, which handles most
of the interrupts on my machine, is far more likely to trigger the
problem than running such a process on any other core.
Also lower sv_maxuser to prevent a malicious user from using mmap()
to load and execute code in the top page of user memory that was made
available when the shared page was moved down.
Make the same changes to the 64-bit Linux emulator.
PR: 219399
Reported by: nbe@renzel.net
Reviewed by: kib
Reviewed by: dchagin (previous version)
Tested by: nbe@renzel.net (earlier version)
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D11780
- bsd.compiler.mk: Must ensure that the CCACHE_WRAPPER_PATH comes first
in PATH.
- Makefile.inc1: Must prepend the CCACHE_WRAPPER_PATH into BPATH as it
overrides the PATH set in bsd.compiler.mk in sub-makes. The PATH
set in bsd.compiler.mk is not exported and doing so would cause it to
then override the BPATH set from environment. The only sane solution
is to prepend into BPATH as needed.
CCACHE_PATH could possibly be used for some of this as well.
Sponsored by: Dell EMC Isilon
When all instances of a lock type are destroyed (for example, after a
module unload), the corresponding witness entry remains associated with
that lock type. In this case, we shouldn't panic if a new instance of the
lock type is created and its lock class does not match that recorded in the
witness entry.
Reviewed by: jhb
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D11788
service.
For tcp-client & udp-client, use the same port in configuration snippet as used
in the comment prior to remove any ambiguity on the port number which needs to
be specified.
Reviewed by: bcr (mentor) wblock (mentor)
Approved by: gavin
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D9830
This uses the /usr/local/libexec/ccache/<cc,c++> wrappers rather than
modifying CC to be '/usr/local/bin/ccache cc'. Some forms of compilation
do not support the 'command' type.
Sponsored by: Dell EMC Isilon
This method is required for querying file / disk sizes which is needed
at least for finding all copies of ZFS VDEV labels.
Reported by: ngie
MFC after: 1 week
According to the PCI Local Specification rev. 3.0 in case of a 64-bit
BAR both the low and the high parts of the register should be set to
~0 before attempting to read back the size.
So far I have found no single device that has problems with the
previous approach, but I think it's better to stay on the safe size.
This commit should not introduce any functional change.
MFC after: 3 weeks
Sponsored by: Citrix Systems R&D
Reviewed by: jhb
Differential revision: https://reviews.freebsd.org/D11750
