similar to "if (ticks > localvar+interval) {localvar=ticks; ...}" where
localvar is initialized to zero. Ticks is initialized to a negative value
since r278230, and that leads to these if statements never being true.
EREs closer together. Prepare for this and reduce the diff of libregex changes by
refactoring and combining the top-level parsers for EREs/BREs ahead of time.
Branching functionality has been split out to make it easier to follow the combined
version of the top-level parser. It may also be enabled in the parsing context to make
it easier when libregex enables branching for BREs.
A branching context was also added for the various branching functions and so that
BREs, for instance, can determine if they're the first expression in a chain of expressions
within the current branch and treat '*' as ordinary if so.
This should have no functional impact and negligible performance impact.
Reviewed by: cem, emaste, pfg
Approved by: emaste (mentor)
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D10920
Uiomove can only block when the segflag is UIO_USERSPACE,
otherwise we end up just doing a bcopy (or nothing) and
moving cursors. So only emit witness warnings and
set deadlock thread flags in the UIO_USERSPACE case.
Reviewed by: kib
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D11489
ATF cleanup routines run in separate processes from the tests themselves, so
they can't share global variables.
Also, setdomainname_test needs to be is_exclusive because the test cases
access a global resource.
PR: 219967
Reviewed by: ngie
MFC after: 3 weeks
Sponsored by: Spectra Logic Corp
Differential Revision: https://reviews.freebsd.org/D11188
the limit to 32MB instead.
Require user=root and memory=64MB+ first so one can be reasonably sure that
the test will function appropriately.
MFC after: 1 month
MFC with: r320726
PR: 220502
Remove any chipset specific usage of Rx descriptor structure / bits
from common code to prevent misuse of fields that may differ
between various chipsets.
Checked with: RTL8821AU in STA mode.
Save output from ls -ldT and stat -l, then normalize all repeating whitespace using
sed to single column spaces.
This makes the test flexible with single-digit days, etc, similar to r320723. This
approach is just a bit more of a hammer approach because of how the columns are
ordered/spaced in both ls and stat.
MFC after: 1 week
MFC with: r319841
gcc produces a "variably modified X at file scope" warning for
structures that use these size definitions.
PR: 211540
Reviewed by: markj
Approved by: markj (mentor)
Sponsored by: Dell EMC Isilon
Differential revision: https://reviews.freebsd.org/D11416
`MK_ZONEINFO_LEAPSECONDS_SUPPORT == yes` and
`MK_ZONEINFO_OLD_TIMEZONES_SUPPORT == yes`.
Keep `LEAPSECONDS` and `OLDTIMEZONES` for backwards compatibility,
but print out a warning notifying users that they should use the new
variables, in an effort to migrate them to the variables. This is being
done mostly for automated build tools, etc, that might rely on these
variables being set. The variables will be removed in the future on
^/head, e.g., after ^/stable/12 is cut.
MFC after: 1 month
Relnotes: yes
Reviewed by: bdrewery
Differential Revision: D11376
After the addition of SUBDIR.yes, uniquifying/ordering the SUBDIRs doesn't
make a whole lot of sense, and it's in effect a half measure.
Ordering SUBDIR (after adding SUBDIR.yes to it) in bsd.subdir.mk is a
separate change that warrants more discussion/testing, because while
the SUBDIR_PARALLEL work largely fixed dependency ordering for SUBDIRs,
there might be downstream FreeBSD consumers that rely on the SUBDIR
ordering.
MFC after: 2 months
Reviewed by: bdrewery
Differential Revision: D11398
This patch adds support for AF_LOCAL socket upcalls to an nfsuserd daemon
that supports them. A future patch to the nfsuserd daemon will use AF_LOCAL
sockets to avoid a problem when using upcalls to 127.0.0.1 if jails are
in use.
Suggested by: dfr
PR: 205193
This addresses a deadlock during boot when EARLY_AP_STARTUP is configured:
a taskqueue thread may call pause() with an ACPI mutex held, and thread0
may block on this mutex before configuring the eventtimer. In this case
the taskqueue thread will sleep forever waiting for its callout to fire.
PR: 220277
Submitted by: jhb
MFC after: 3 days
Includes:
- Support for X550EM devices.
- Support for Bypass adapters.
- Flow Director code moved to separate files
- SR-IOV code moved to separate files
- Netmap code moved to separate files
Differential Revision: https://reviews.freebsd.org/D11232
Submitted by: Jeb Cramer <cramerj@intel.com>
Reviewed by: erj@
Tested by: Jeff Pieper <jeffrey.e.pieper@intel.com>
Sponsored by: Intel Corporation
ZFS SLOGs have very specific access pattern with many cache flushes,
which none of benchmarks I know can simulate. Since SSD vendors rarely
specify cache flush time, this measurement can be useful to explain why
some ZFS pools are slower then expected. This test writes data chunks
of different size followed by cache flush, alike to what ZFS SLOG does,
and measures average time.
To illustrate, here is result for 6 years old SATA Intel 710 Series SSD:
Synchronous random writes:
0.5 kbytes: 138.3 usec/IO = 3.5 Mbytes/s
1 kbytes: 137.7 usec/IO = 7.1 Mbytes/s
2 kbytes: 151.1 usec/IO = 12.9 Mbytes/s
4 kbytes: 158.2 usec/IO = 24.7 Mbytes/s
8 kbytes: 175.6 usec/IO = 44.5 Mbytes/s
16 kbytes: 210.1 usec/IO = 74.4 Mbytes/s
32 kbytes: 274.2 usec/IO = 114.0 Mbytes/s
64 kbytes: 416.5 usec/IO = 150.1 Mbytes/s
128 kbytes: 776.6 usec/IO = 161.0 Mbytes/s
256 kbytes: 1503.1 usec/IO = 166.3 Mbytes/s
512 kbytes: 2968.7 usec/IO = 168.4 Mbytes/s
1024 kbytes: 5866.8 usec/IO = 170.5 Mbytes/s
2048 kbytes: 11696.6 usec/IO = 171.0 Mbytes/s
4096 kbytes: 23329.6 usec/IO = 171.5 Mbytes/s
8192 kbytes: 46779.5 usec/IO = 171.0 Mbytes/s
, and much newer and supposedly much faster NVMe Samsung 950 PRO SSD:
Synchronous random writes:
0.5 kbytes: 2092.9 usec/IO = 0.2 Mbytes/s
1 kbytes: 2013.1 usec/IO = 0.5 Mbytes/s
2 kbytes: 2014.8 usec/IO = 1.0 Mbytes/s
4 kbytes: 2090.7 usec/IO = 1.9 Mbytes/s
8 kbytes: 2044.5 usec/IO = 3.8 Mbytes/s
16 kbytes: 2084.8 usec/IO = 7.5 Mbytes/s
32 kbytes: 2137.1 usec/IO = 14.6 Mbytes/s
64 kbytes: 2173.4 usec/IO = 28.8 Mbytes/s
128 kbytes: 2923.9 usec/IO = 42.8 Mbytes/s
256 kbytes: 3085.3 usec/IO = 81.0 Mbytes/s
512 kbytes: 3112.2 usec/IO = 160.7 Mbytes/s
1024 kbytes: 2430.6 usec/IO = 411.4 Mbytes/s
2048 kbytes: 3788.9 usec/IO = 527.9 Mbytes/s
4096 kbytes: 6198.0 usec/IO = 645.4 Mbytes/s
8192 kbytes: 10764.9 usec/IO = 743.2 Mbytes/s
While the first one obviously has maximal throughput limitations, the
second one has so high cache flush latency (about 2 millisecond), that
it makes one almost useless in SLOG role, despite of its good throughput
numbers. Power loss protection is out of scope of this test, but I
suspect it can be related.
MFC after: 2 weeks
Sponsored by: iXsystems, Inc.
sbavail() returns u_int and sendwin is a uint32_t. Therefore, min() (which
operates on two u_int values) is able to correctly calculate the minimum
of these two arguments.
Reported by: rrs
MFC after: 1 week
Sponsored by: Netflix
Even though gdb and kgdb may not be removed for 12.0 on some architectures,
the notice is unconditional as these tools will likely be removed at some
point in the future when adequate replacements are available (gdb in ports
or lldb in base).
Reviewed by: emaste
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D11477
This patch adds new bsdinstall option to hardening section that allows users
to change this behaviour to secure one and updates stack guard option so it
would set the value of relevant sysctl to 512 (2MB)
Submitted by: Bartek Rutkowski
Reviewed by: adrian, bapt, emaste
Approved by: bapt, emaste
MFC after: 1 day
Sponsored by: Pixeware LTD
Differential Revision: https://reviews.freebsd.org/D9700
the terminal work properly out of the box when logging over a serial
line, which is quite important for the user experience on boards like
Raspberry Pi. It doesn't affect cases where the terminal size is
already non-zero, such as SSH or vt(4) sessions.
Note that this doesn't handle a scenario pointed out by rgrimes@:
when the terminal is resized after login, the terminal size won't
get updated even after logging out and back in.
Reviewed by: imp
Obtained from: CheriBSD
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D10642
