These scripts predate /etc/rc.diskless* and use a different scheme. A
comment was added to them back in 2002 noting they were 3 years old at
that point.
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D41951
The following sysctl variables are actually loader tunables. Add sysctl
flag CTLFLAG_TUN to them so that `sysctl -T` will report them correctly.
1. net.inet.ip.fw.enable
2. net.inet6.ip6.fw.enable
3. net.link.ether.ipfw
No functional change intended.
Reviewed by: glebius
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D41928
The following sysctl variables are actually loader tunables. Add sysctl
flag CTLFLAG_TUN to them so that `sysctl -T` will report them correctly.
1. net.inet6.ip6.auto_linklocal
2. net.inet6.ip6.accept_rtadv
3. net.inet6.ip6.no_radr
No functional change intended.
Reviewed by: glebius
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D41928
The sysctl variable `net.route.netisr_maxqlen` is actually a loader
tunable. Add sysctl flag CTLFLAG_TUN to it so that `sysctl -T` will
report it correctly.
No functional change intended.
Reviewed by: glebius
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D41928
Since 13.1, /etc/rc.d/jail has looked for a per-jail config file in
/etc/jail.conf.d. For RELENG 14, the ".include" directive was added to
jail(8), with a sample line in the jail.conf(5) man page that includes
"/etc/jail.conf.d/*.conf".
These two use cases don't work together. When the jail.conf.d files
are included from a master jail.conf, the files in jail.conf.d are
likely to hold only partial configurations, and shouldn't be directly
loaded by rc.d/jail. But there are existing configurations that depend
on the current rc.d behavior. While users could be advised not to
include from /etc/jail.conf.d, it's the natural choice even if not
mentioned in jail.conf.5.
The workaround is for rc.d/jail to continue to load the individual
files, but only when /etc/jail.conf doesn't include from that
directory (via a simple grep test), This allows the current use
while not breaking the previous use.
Reported by: antranigv at freebsd.am
Differential Revision: https://reviews.freebsd.org/D41962
getdirentires last argument "off_t *basep" is an optional output
argument. It returns the value only when the passed-in value(pointer)
is non-NULL.
This is a part of the research work at RCSLab, University of Waterloo.
Reviewed by: imp, emaste
Differential Revision: https://reviews.freebsd.org/D41969
Currently, when we suspend, we need to tear down all the qpairs. We call
nvme_admin_qpair_abort_aers with the admin qpair lock held, but the
tracker it will call for the pending AER also locks it (recursively)
hitting an assert. This routine is called without the qpair lock held
when we destroy the device entirely in a number of places. Add an assert
to this effect and drop the qpair lock before calling it.
nvme_admin_qpair_abort_aers then locks the qpair lock to traverse the
list, dropping it around calls to nvme_qpair_complete_tracker, and
restarting the list scan after picking it back up.
Note: If interrupts are still running, there's a tiny window for these
AERs: If one fires just an instant after we manually complete it, then
we'll be fine: we set the state of the queue to 'waiting' and we ignore
interrupts while 'waiting'. We know we'll destroy all the queue state
with these pending interrupts before looking at them again and we know
all the TRs will have been completed or rescheduled. So either way we're
covered.
Also, tidy up the failure case as well: failing a queue is a superset of
disabling it, so no need to call disable first. This solves solves some
locking issues with recursion since we don't need to recurse.. Set the
qpair state of failed queues to RECOVERY_FAILED and stop scheduling the
watchdog. Assert we're not failed when we're enabling a qpair, since
failure currently is one-way. Make failure a little less verbose.
Next, kill the pre/post reset stuff. It's completely bogus since we
disable the qparis, we don't need to also hold the lock through the
reset: disabling will cause the ISR to return early. This keeps us from
recursing on the recovery lock when resuming. We only need the recovery
lock to avoid a specific race between the timer and the ISR.
Finally, kill NVME_RESET_2X. It'S been a major release since we put it
in and nobody has used it as far as I can tell. And it was a motivator
for the pre/post uglification.
These are all interrelated, so need to be done at the same time.
Sponsored by: Netflix
Reviewed by: jhb
Tested by: jhb (made sure suspend / resume worked)
MFC After: 3 days
Differential Revision: https://reviews.freebsd.org/D41866
Until a better arrangment is worked out, guard the setting of
CROSS_TARGET_FLAGS in local.sys.mk with check for DIRDEPS_BUILD.
Using a separate flag for CROSS_TARGET that can be reset by
bsd.compat.mk is probably the right thing.
\D{format} yields the result of calling strftime(3) with the provided
format and the current time.
When PS4 can use this, it will enable us to easily generate timestamps
when tracing script execution.
Differential Revision: https://reviews.freebsd.org/D35840
It is not the first time I see it panicking while trying to modify
const memory. Lets make it safer and easier to use. While there,
mark few functions using it also const.
MFC after: 10 days
A ng_eiface instance may be on lease to a different vnet while
remaining tied to its parent vnet. In such circumstances, before
injecting mbufs into netgraph, curvnet must be set to that of the
ng_eiface's netgraph node. Mark the vnet transition as QUIET,
since otherwise it would be recorded as a curvnet recursion when
ng_eiface's ifnet resides in the same (parent) vnet as its
netgraph node.
PR: 274028
Reported by: Dancho Penev <dpslavov@hotmail.com>
MFC after: 1 week
Allow building 32bit libs for host.
Move CFLAGS additions from local.sys.dirdeps.mk (which is too early
and impacts CFLAGS defaults) to local.sys.mk
Reviewed by: stevek
Sponsored by: Juniper Networks, Inc.
Differential Revision: https://reviews.freebsd.org/D41946
The problem that was occurring is basically that a device was removed
by ztest and replaced with another device. It was then reguided. The
import then failed because there were two possible imports with the
same name; one with the new guid, and one with the old. This can
happen because the label writes from the device removal/replacement
can be subject to ztest's error injection.
The other ways to fix this would be to change the error injection to
not trigger on removals (which may not be technically feasible), or
to change the import code to not report configurations that are so
short on devices (which would potentially have unpleasant end-user
effects when trying to recover from data losses/device configuration
issues).
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Matthew Ahrens <mahrens@delphix.com>
Reviewed-by: George Melikov <mail@gmelikov.ru>
Signed-off-by: Paul Dagnelie <pcd@delphix.com>
Closes#15298
'ncnegminpct' is to be passed always, so just drop the unneeded parameter.
Sponsored by: The FreeBSD Foundation
Reviewed by: mjg
Differential Revision: https://reviews.freebsd.org/D41763
Factoring out this code unfortunately introduced reference and lock leaks in
case of failure in the lock upgrade path under VV_CROSSLOCK. In terms of
practical use, this impacts unionfs (and nullfs in a corner case).
Fixes: 80bd5ef070 ("vfs: factor out mount point traversal to a dedicated routine")
MFC after: 3 days
MFC to: stable/14 releng/14.0
Sponsored by: The FreeBSD Foundation
Reviewed by: mjg
[mjg: massaged the commit message a little bit]
Differential Revision: https://reviews.freebsd.org/D41731
We could hit these when executing code marked as using BTI but jumps
to a non-branch target instruction.
Sponsored by: Arm Ltd
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D39450
We have export the CPUID registers since 2018 but never set the
HWCAP_CPUID flag to tell userspace it could use them. Fix this by
setting it.
Sponsored by: Arm Ltd
It may be needed when it's updated so is best to keep in sync with the
assembly files.
Reviewed by: emaste
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D41938
Adjust the lastcomm command to output timestamps with a precision of
seconds.
Reported by: Dr. Andreas Longwitz
Reviewed by: emaste
Relnotes: Yes
Sponsored by: DSS Gmbh
Pull Request: https://github.com/freebsd/freebsd-src/pull/802
For protocols that use netlink (generic and route for now), the unint
handler seems to have forgotten to call unregister, which will cause
the assertion the next time the module is loaded.
This patch adds unregister call to netlink_unregister_proto() for those
handlers to avoid bad things happen.
Reviewed-by: melifaro
Fixes: 7e5bf68495 ("netlink: add netlink support")
Pull-request: https://github.com/freebsd/freebsd-src/pull/781
Signed-off-by: Lin Ma <linma@zju.edu.cn>
7f7ef494f1 introduced a compile time option PF_DEFAULT_TO_DROP to make
the pf(4) default rule to drop. While this change exposes a vnet loader
tunable 'net.pf.default_to_drop' so that users can change the default
rule without re-compiling the pf(4) module.
This change is similiar to that for IPFW [1].
1. 5f17ebf94d Convert IPFW_DEFAULT_TO_ACCEPT into a loader tunable 'net.inet.ip.fw.default_to_accept'
Reviewed by: #network, kp
MFC after: 2 weeks
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D39866
