When checking the length of the mutual secret password the variable for
the secret password was used by mistake. This resulted in ctld never
warning about the length of the mutual secret being wrong even if it was.
MFC after: 3 days
Sponsored by: iXsystems
When following symlinks, fts returned FTS_SLNONE when fstatat(flag=0)
failed, but a subsequent fstatat(flag=AT_SYMLINK_NOFOLLOW) succeeded. This
incorrectly triggered if a filename existed to be read from the directory,
was deleted before the fstatat(flag=0) and created again after the
fstatat(flag=0).
Fix this by only returning FTS_SLNONE if the result from
fstatat(flag=AT_SYMLINK_NOFOLLOW) is actually a symlink. If it is not a
symlink, treat it as if fstatat(flag=0) succeeded.
PR: 196724
Reported and tested by: pho
MFC after: 1 week
that performs the equivalent of an automatic madvise(..., MADV_DONTNEED).
The current heuristic, even with the improvements that I made a few years
ago, is a good example of making the wrong trade-off, or optimizing for
the infrequent case. The infrequent case being reading a single file that
is much larger than memory using mmap(2). And, in this case, the page
daemon isn't the bottleneck; it's the I/O.
In all other cases, the current heuristic has too many false positives,
i.e., it caches too many pages that are later reused. To give one
example, thousands of pages are cached by the current heuristic during a
buildworld and all of them are reactivated before the buildworld
completes. In particular, clang reads source files using mmap(2) and
there are some relatively large source files in our source tree, e.g.,
sqlite, that are read multiple times. With the new heuristic, I see fewer
false positives and they have a much lower cost.
I actually tried something like this more than two years ago and it
didn't perform as well as the cache behind heuristic. However, that was
before the changes to the page daemon in late summer of 2013 and the
existence of pmap_advise(). In particular, with the page daemon doing
its work more frequently and in smaller batches, it now completes its
work while the application accessing the file is blocked on I/O.
Whereas previously, the page daemon appeared to hog the CPU for so long
that it caused "hiccups" in the application's execution.
Finally, I'll add that the elimination of cache pages is a prerequisite
for NUMA support.
Reviewed by: jeff, kib
Sponsored by: EMC / Isilon Storage Division
- Add macros to handle the differences in accessing these registers on arm
and arm64.
- Use the fdt data to detect if we are on an ARMv7 or ARMv8.
- Use the virtual timer by default on arm64, we may not have access to
the physical timer.
Differential Revision: https://reviews.freebsd.org/D2208
Reviewed by: emaste
Sponsored by: The FreeBSD Foundation
Previously, the driver was trying to blink the LED in the newstate
function, but that only gets called once (unlike OpenBSD's net80211
stack). Move the LED blinking to set_channel().
While there, don't try to set the channel when we switch to the SCAN
state. This is already accomplished by the set_channel() function.
MFC after: 1 week
It's necessary to reset the screen to make sure any vendor pixels are
gone when we start boot1. In the Lenovo X1 (3rd gen), this is the
only way to clear the screen. Previously, the Lenovo logo would only
disappear after the kernel started scrolling the display.
After resetting the screen, EFI could put us in the worst LCD mode
(oversized characters), so we now find the largest mode we can use and
hope it's the most appropriate one (it's not trivial to tell what's
the correct LCD resolution at this point). It's worth noting that the
final stage loader has a 'mode' command that can be used to switch
text modes.
While there, enable the software cursor, just like in the legacy boot
mode.
MFC after: 1 week
to include the Unaligned Access and Floating-point Half-precision
attributes. the former marks ELF objects that may access ARMv6 style
unaligned data, the latter that the binary uses the VFPv3/Advanced SIMD
half-precision extension.
These may be emmitted by clang so it's best to print a warning when the
linker hits one of them.
Differential Revision: http://reviews.freebsd.org/D2194
Submitted by: Michal Meloun <meloun@miracle.cz>
MFC after: 1 week
Fix assert instantiating string init of static variable
... when the variable's type is a typedef of a ConstantArrayType. Just
look through the typedef (and any other sugar). We only use the
constant array type here to get the element count.
This fixes an assertion failure when building the games/redeclipse port.
Reported by: amdmi3
Even on Illumos, with its much larger KVA, ZFS ARC steps back if KVA usage
reaches certain threshold (3/4 on i386 or 16/17 otherwise). FreeBSD has
even less KVA, but had no such limit on archs with direct map as amd64.
As result, on machines with a lot of RAM, during load with very small user-
space memory pressure, such as `zfs send`, it was possible to reach state,
when there is enough both physical RAM and KVA (I've seen up to 25-30%),
but no continuous KVA range to allocate even single 128KB I/O request.
Address this situation from two sides:
- restore KVA usage limitations in a way the most close to Illumos;
- introduce new requirement for KVA fragmentation, specifying that we
should have at least one sequential KVA range of zfs_max_recordsize bytes.
Experiments show that first limitation done alone is not sufficient. On
machine with 64GB of RAM it is sometimes needed to drop up to half of ARC
size to get at leats one 1MB KVA chunk. Statically limiting ARC to half
of KVA/RAM is too strict, so second limitation makes it to work in cycles:
accumulate trash up to certain critical mass, do massive spring-cleaning,
and then start littering again. :)
MFC after: 1 month
ABI specifies that, for R_AARCH64_TLSDESC relocations, we use the symbol
value, addend, and object tls offset to calculate the offset from the tls
base. We then cache this value for future reference.
Differential Revision: https://reviews.freebsd.org/D2183
Reviewed by: kib
Sponsored by: The FreeBSD Foundation
work stack and is reused again on the receive ring. Remaining received packets in the ring are not processed in that
invocation of bxe_rxeof() and defered to the task thread.
MFC after: 5 days
