Very small EXAMPLES section.
While here, remove reference to nroff(1).
Approved by: manpages (bcr@)
Differential Revision: https://reviews.freebsd.org/D26947
instead of mount_nullfs(8).
Obviously you'd need to force mount(8) to not call
mount_nullfs(8) to make use of it.
Reviewed by: kib
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D26934
more readable. While here, add linux_check_errtbl() function to make
sure we don't leave holes.
No objections: emaste (earlier version)
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D26972
While here, move the date to keep 2 weeks ahead notificaion
and fix the part of speech.
Reviewed by: debdrup
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D26998
struct nameidata mixes caller arguments, internal state and output, which
can be quite error prone.
Recent addition of valdiating ni_resflags uncovered a caller which could
repeatedly call namei, effectively operating on partially populated state.
Add bare minimium validation this does not happen. The real fix would
decouple aforementioned state.
Reported by: pho
Tested by: pho (different variant)
The existing code performed a chdir() into the home directory, but the
parser fell back to using the invoking user's home directory as the base
directory for the search for an include file.
Since use of the -a option is limited to UID==0, the directory searched
was typically ~root/.calendar, not the .calendar directory of the user
whose file is being processed.
PR: 205580
Reported by: greg.bal4@gmail.com (Greg Balfour)
MFC after: 3 days
It appears that booting FreeBSD from qemu's synthesized FAT filesystem
broke somehow in a recent qemu-devel update. qemu42 works so switch to
it for now.
- Add a new send tag type for a send tag that supports both rate
limiting (packet pacing) and TLS offload (mostly similar to D22669
but adds a separate structure when allocating the new tag type).
- When allocating a send tag for TLS offload, check to see if the
connection already has a pacing rate. If so, allocate a tag that
supports both rate limiting and TLS offload rather than a plain TLS
offload tag.
- When setting an initial rate on an existing ifnet KTLS connection,
set the rate in the TCP control block inp and then reset the TLS
send tag (via ktls_output_eagain) to reallocate a TLS + ratelimit
send tag. This allocates the TLS send tag asynchronously from a
task queue, so the TLS rate limit tag alloc is always sleepable.
- When modifying a rate on a connection using KTLS, look for a TLS
send tag. If the send tag is only a plain TLS send tag, assume we
failed to allocate a TLS ratelimit tag (either during the
TCP_TXTLS_ENABLE socket option, or during the send tag reset
triggered by ktls_output_eagain) and ignore the new rate. If the
send tag is a ratelimit TLS send tag, change the rate on the TLS tag
and leave the inp tag alone.
- Lock the inp lock when setting sb_tls_info for a socket send buffer
so that the routines in tcp_ratelimit can safely dereference the
pointer without needing to grab the socket buffer lock.
- Add an IFCAP_TXTLS_RTLMT capability flag and associated
administrative controls in ifconfig(8). TLS rate limit tags are
only allocated if this capability is enabled. Note that TLS offload
(whether unlimited or rate limited) always requires IFCAP_TXTLS[46].
Reviewed by: gallatin, hselasky
Relnotes: yes
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D26691
r366981 disabled ASAN when it might not be reliable (with an external
compiler), but this test is broken without ASAN so disable it completely
in that case.
PR: 250706
Reviewed by: emaste, lwhsu
Differential Revision: https://reviews.freebsd.org/D26982
The calling process's process group can change between PROC_UNLOCK(p)
and PGRP_LOCK(pg) in tty_wait_background(), e.g. by a setpgid() call
from another process. If that happens, the signal is not sent to the
calling process, even if the prior checks determine that one should be
sent. Re-check that the process group hasn't changed after acquiring
the pgrp lock, and if it has, redo the checks.
PR: 250701
Submitted by: Jakub Piecuch <j.piecuch96@gmail.com>
MFC after: 2 weeks
We don't have NEON available in the boot loader, so we have to disable
it. OpenZFS included ZSTD which used the wrong symbol to bring in neon
support. Change to use the code that's been submitted upstream as a
pull request to both.
__ARM_NEON is the proper symbol, defined in ARM C Language Extensions
Release 2.1 (https://developer.arm.com/documentation/ihi0053/d/). Some
sources suggest __ARM_NEON__, but that's the obsolete spelling from
prior versions of the standard.
OpenZFS Pull Request: https://github.com/openzfs/zfs/pull/11055
ZSTD Pull Request: https://github.com/facebook/zstd/pull/2356
If you need / want to includerd sys/systm.h, it has to be just after
param.h/types.h. Document this existing practice. Not all kernel files
include systm.h, but when you do, it should be done out of order.
Reviewed by: vangyzen, kib, emaste
Differential Review: https://reviews.freebsd.org/D26981
Code was supposed to call callout_reset_sbt_on() rather than
callout_reset_sbt(). This resulted into passing a "cpu" value
to a "flag" argument. A recipe for subtle errors.
PR: 248652
Reported by: sg@efficientip.com
MFC with: r367093
It seems *-passthru commands were broken from the day one, since the
device path is fetched into opt.dev variable and not left in argv[optind].
The other three wrong argv[optind] instances are just in error messages.
MFC after: 1 week
Sponsored by: iXsystems, Inc.
The previous behavior was to support nested #ifdef and #ifndef, but to
return to unconditional parsing after the next #endif, independently of
the number of previously parsed conditions.
E.g. after "#ifdef A / #ifdef B / #endif" the following lines were
unconditially parsed again, independently of A and/or B being defined.
The new behavior is to count the level of false conditions and to only
restart parsing of calendar entries when the corresponding number of
#endif tokens have been seen.
In addition to the above, an #else directive has been added, to toggle
between parsing and ignoring of the following lines.
No validation of the correct use of the condition directives is made.
#endif without prior #define or #ifndef is ignored and #else toggles
between parsing and skipping of entries.
The MFC period has been set to 1 month to allow for a review of the
changes and for a discussion, whether these modifications should not
be merged at all.
No correct input file is parsed differently than before, but if calendar
data files are published that use these new features, those data files
will not parse correctly on prior versions of this program.
MFC after: 1 month
Foundation copyrights, approved by emaste@. It does not include
files which carry other people's copyrights; if you're one
of those people, feel free to make similar change.
Reviewed by: emaste, imp, gbe (manpages)
Differential Revision: https://reviews.freebsd.org/D26980
The convention in this program is to parse the line immediately starting
after the token (e.g. #defineA and #ifdefA define respectively look-up "A"),
and this commit restores this behavior instead of skipping an assumed
white-space character following #ifdef.
Reported by: kevans
MFC after: 3 days
There was code to process an #ifndef tokens, but none for #ifdef.
The #ifdef token was mentioned as unsupported in the BUGS section,
but no reason was given and I do not see why it should stay omitted.
Misleading information in The BUGS section of the man-page regarding
the maximum number of #define and #include statements supported has
been removed. These limits might have applied to a prior version of
this program, but do not seem to apply to the current implementation.
I have not tried to test for the existence of the limits, but the
include file processing just recursively calls the parser (without
counting the recursion depth) and the stringlist functions do not
impose a limit on the number of entries.
Reported by: jhs@berklix.com
MFC after: 3 days
Installing the llvm11 package instead of bootstrapping it from the source
tree reduces the build time by about 20 minutes.
The last freebsd/freebsd build that was tested (r366629) took 1h 21m 22s,
whereas my GitHub fork with this .cirrus.yml took 58m 6s.
We could probably further reduce time by using images that have LLVM
pre-installed: the pkg install step took 4 minutes 30s.
Since the bootstrap toolchain is still tested by Jenkins, this should not
reduce test coverage of the CI testing.
Reviewed By: emaste
Differential Revision: https://reviews.freebsd.org/D26747
Clang's optimizer spends a really long time on these tests at -O2, so we now
use -O0 instead. This reduces the -j32 time for lib/googletest/test from 131s
to 29s. Using -O0 also reduces the disk usage from 144MB (at -O2) / 92MB (at
-O1) to 82MB.
Reviewed By: ngie, dim
Differential Revision: https://reviews.freebsd.org/D26751
This depends on https://reviews.llvm.org/D90246 to have any effect, but once
that has landed clang-format will no longer format code like this:
```
int
myfunction(
int param1, int param2, int param2)
{
...
}
```
and instead create the following:
```
int
myfunction(int param1, int param2,
int param2)
{
...
}
```
Reviewed By: emaste, cem
Differential Revision: https://reviews.freebsd.org/D26978
It turns out that examples were incorrectly referring to Volume_Up
and Volume_Down, which are not defined at all.
PR: 250683
Reported by: corvid%openmailbox.org
MFC after: 2 weeks
The way netmap TX is handled in iflib when TX interrupts are not
used (IFC_NETMAP_TX_IRQ not set) has some issues:
- The netmap_tx_irq() function gets called by iflib_timer(), which
gets scheduled with tick granularity (hz). This is not frequent
enough for 10Gbps NICs and beyond (e.g., ixgbe or ixl). The end
result is that the transmitting netmap application is not woken
up fast enough to saturate the link with small packets.
- The iflib_timer() functions also calls isc_txd_credits_update()
to ask for more TX completion updates. However, this violates
the netmap requirement that only txsync can access the TX queue
for datapath operations. Only netmap_tx_irq() may be called out
of the txsync context.
This change introduces per-tx-queue netmap timers, using microsecond
granularity to ensure that netmap_tx_irq() can be called often enough
to allow for maximum packet rate. The timer routine simply calls
netmap_tx_irq() to wake up the netmap application. The latter will
wake up and call txsync to collect TX completion updates.
This change brings back line rate speed with small packets for ixgbe.
For the time being, timer expiration is hardcoded to 90 microseconds,
in order to avoid introducing a new sysctl.
We may eventually implement an adaptive expiration period or use another
deferred work mechanism in place of timers.
Also, fix the timers usage to make sure that each queue is serviced
by a different CPU.
PR: 248652
Reported by: sg@efficientip.com
MFC after: 2 weeks
All vnodes allocated by UMA are present on the global list used by
vnlru. getnewvnode modifies the state of the vnode (most notably
altering v_holdcnt) but never locks it. Moreover filesystems also
modify it in arbitrary manners sometimes before taking the vnode
lock or adding any other indicator that the vnode can be used.
Picking up such a vnode by vnlru would be problematic.
To that end there are 2 fixes:
- vlrureclaim, not recycling v_holdcnt == 0 vnodes, takes the
interlock and verifies that v_mount has been set. It is an
invariant that the vnode lock is held by that point, providing
the necessary serialisation against locking after vhold.
- vnlru_free_locked, only wanting to free v_holdcnt == 0 vnodes,
now makes sure to only transition the count 0->1 and newly allocated
vnodes start with v_holdcnt == VHOLD_NO_SMR. getnewvnode will only
transition VHOLD_NO_SMR->1 once more making the hold fail
Tested by: pho
function checks that the mutex lock is owned.
This fixes 'devctl disable re0' operation.
Sponsored by: Innovate DSbD
Differential Revision: https://reviews.freebsd.org/D26904
PCPU_GET(curpmap) expands to multiple instructions on arm64, and if the
current thread is migrated in between execution of those instructions, a
stale value may be used in the assertion condition.
Diagnosed by: mmel
Reported by: mmel, Bob Prohaska <fbsd@www.zefox.net>
Submitted by: alc
MFC after: 1 week
