This is addressing cases such as fts_read(3) encountering an [EIO]
from fchdir(2) when FTS_NOCHDIR is not set. That would otherwise be
seen as a successful traversal in some of these cases while silently
discarding expected work.
As noted in r264201, fts_read() does not set errno to 0 on a successful
EOF so it needs to be set before calling it. Otherwise we might see
a random error from one of the iterations.
gzip is ignoring most errors and could be improved separately.
Reviewed by: vangyzen
Sponsored by: Dell EMC
Differential Revision: https://reviews.freebsd.org/D27184
cpuset_modify() would not currently catch this, because it only checks that
the new mask is a subset of the root set and circumvents the EDEADLK check
in cpuset_testupdate().
This change both directly validates the mask coming in since we can
trivially detect an empty mask, and it updates cpuset_testupdate to catch
stuff like this going forward by always ensuring we don't end up with an
empty mask.
The check_mask argument has been renamed because the 'check' verbiage does
not imply to me that it's actually doing a different operation. We're either
augmenting the existing mask, or we are replacing it entirely.
Reported by: syzbot+4e3b1009de98d2fabcda@syzkaller.appspotmail.com
Discussed with: andrew
Reviewed by: andrew, markj
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D27511
The race plays out like so between threads A and B:
1. A ref's cpuset 10
2. B does a lookup of cpuset 10, grabs the cpuset lock and searches
cpuset_ids
3. A rel's cpuset 10 and observes the last ref, waits on the cpuset lock
while B is still searching and not yet ref'd
4. B ref's cpuset 10 and drops the cpuset lock
5. A proceeds to free the cpuset out from underneath B
Resolve the race by only releasing the last reference under the cpuset lock.
Thread A now picks up the spinlock and observes that the cpuset has been
revived, returning immediately for B to deal with later.
Reported by: syzbot+92dff413e201164c796b@syzkaller.appspotmail.com
Reviewed by: markj
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D27498
cpuset_rel_defer() is supposed to be functionally equivalent to
cpuset_rel() but with anything that might sleep deferred until
cpuset_rel_complete -- this setup is used specifically for cpuset_setproc.
Add in the missing unr free to match cpuset_rel. This fixes a leak that
was observed when I wrote a small userland application to try and debug
another issue, which effectively did:
cpuset(&newid);
cpuset(&scratch);
newid gets leaked when scratch is created; it's off the list, so there's
no mechanism for anything else to relinquish it. A more realistic reproducer
would likely be a process that inherits some cpuset that it's the only ref
for, but it creates a new one to modify. Alternatively, administratively
reassigning a process' cpuset that it's the last ref for will have the same
effect.
Discovered through D27498.
MFC after: 1 week
The definition was copied from amd64, but the layout of the struct
differs slightly between these platforms. This fixes spurious
`unsupported sigaction flag 0xXXXXXXXX` messages when executing some
Linux binaries on arm64.
Reviewed by: emaste
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D27460
This same check is used on other architectures. Previously this would
permit a stack frame to unwind into any arbitrary kernel address
(including unmapped addresses).
Reviewed by: andrew, markj
Obtained from: CheriBSD
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D27362
- Push the kstack_contains check down into unwind_frame() so that it
is honored by DDB and DTrace.
- Check that the trapframe for an exception frame is contained in the
traced thread's kernel stack for DDB traces.
Reviewed by: markj
Obtained from: CheriBSD
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D27357
New Netgraph module ng_macfilter:
Macfilter to route packets through different hooks based on sender MAC address.
Based on ng_macfilter written by Pekka Nikander
Sponsered by Retina b.v.
Reviewed by: afedorov
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D27268
Replace some hard-coded magic values in the ioctl stats struct with
#defines. I'm going to follow up with some more sanity checking in
the receive path that also use these values so we don't do bad
things if the hardware is (more) confused.
OpenSSL commit 3db2c9f3:
Complain if we are attempting to encode with an invalid ASN.1 template
OpenSSL commit 43a7033:
Check that multi-strings/CHOICE types don't use implicit tagging
OpenSSL commit f960d812:
Correctly compare EdiPartyName in GENERAL_NAME_cmp()
Obtained from: OpenSSL 3db2c9f3, 43a7033, f960d812
Security: CVE-2020-1971
Macfilter to route packets through different hooks based on sender MAC address.
Based on ng_macfilter written by Pekka Nikander
Sponsered by Retina b.v.
Reviewed by: afedorov
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D27268
As discussed on -current, -stable, -toolchain, and with jhb@ and imp@,
disable the obsolete in-tree GDB 6.1.1 by default. This was kept only
to provide kgdb for the crashinfo tool, but is long-obsolete, does not
support all architectures that FreeBSD does, and held back other work
(such as forcing the use of DWARF2 for kernel debug).
Crashinfo will use kgdb from the gdb package or devel/gdb port, and will
privde a message referencing those if no kgdb is found.
Relnotes: Yes
Sponsored by: The FreeBSD Foundation
This has been years in the making, and we all knew it was bound to happen
some day. Switch to the BSDL grep implementation now that it's been a
little more thoroughly tested and theoretically supports all of the
extensions that gnugrep in base had with our libregex(3).
Folks shouldn't really notice much from this update; bsdgrep is slower than
gnugrep, but this is currently the price to pay for fewer bugs. Those
dissatisfied with the speed of grep and in need of a faster implementation
should check out what textproc/ripgrep and textproc/the_silver_searcher
can do for them.
I have some WIP to make bsdgrep faster, but do not consider it a blocker
when compared to the pros of switching now (aforementioned bugs, licensing).
PR: 228798 (exp-run)
PR: 128645, 156704, 166842, 166862, 180937, 193835, 201650
PR: 232565, 242308, 246000, 251081, 191086, 194397
Relnotes: yes, please
This is being done for the formatting and context changes. While the net content
hasn't been changed, the content/context changes were sufficient to warrant the
date bump.
MFC after: 1 week
MFC with: r368431, r368433, r368434, r368435
Sponsored by: DellEMC Isilon
While some of the syscalls' behavior were documented and implied in the
RETURN VALUES section by earlier, e.g., the DESCRIPTION sections, as having
behavior of the other calls (`*_fd` vs `*_file` vs `*_link`), there was a lot
of implied return value behavior in the section prior to this change.
Explicitly document the syscall behavior per the current implementation in
sys/kern/vfs_extattr.c so others can better develop based on its explicit
documented behavior instead of having to digest the context of the manpage to
understand the appropriate behavior.
MFC after: 1 week
MFC with: r368431, r368433, r368434
Sponsored by: DellEMC Isilon
- Remove an unnecessary trailing comma separating a two-item clause.
- Sort more function calls alphabetically (in the same vein as r368433).
MFC after: 1 week
Sponsored by: DellEMC Isilon
Although some sections of the manpage sort the syscalls alphabetically, many
core areas of the manpage do not. Sort the syscalls so it is easier to pick out
functional changes and to improve manpage readability.
This formatting change is also being done to make future functional changes
easier to spot.
MFC after: 1 week
Sponsored by: DellEMC Isilon
The date with .Dd prior to this change isn't canonically spelled out: it
should have been "December", not "Dec".
MFC after: 1 week
Sponsored by: DellEMC Isilon
- The CAVEATS section was misspelled as "CAVEAT".
- The CAVEATS section should come before the "BUGS" section and after
other existing sections by convention.
MFC after: 1 week
Reported by: make manlint
Sponsored by: DellEMC Isilon
For platforms that don't have any of the memstick, cdrom, or dvdrom
release images (i.e. riscv64), the release-install target will trip up
when invoking md5(1) on the non-existent image files. Skipping this
allows the install to complete successfully.
Add two release flavors for RISC-V. First, the traditional "big-iron"
images, capable of generating distribution sets and VM images. Installer
images won't be built yet, but can be trivially enabled in the future
with the addition of riscv/make-memstick.sh.
Second, a GENERICSD embedded image. I've opted for this instead of
board-specific SD card images as it allows users to just dd the u-boot
they want. The RISC-V hardware ecosystem is still young, so a
configuration for e.g. the new PolarFire SoC Icicle Kit would likely see
very few users.
Reviewed by: gjb
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D27045
RISC-V has the same booting requirements as arm64 (loader.efi, no legacy
boot options), so generated images for both architectures have the same
partition layout.
Reviewed by: gjb
Differential Revision: https://reviews.freebsd.org/D27044
Since the few existing RISC-V hardware platforms are single board
computers, we can piggyback off of arm/arm64's embedded build support
for generating SD card images.
I don't see a pressing need to change the naming in this file at this
time.
Reviewed by: gjb, manu
Differential Revision: https://reviews.freebsd.org/D27043
We assume the boot CPU is always CPU 0 on arm64. To allow for this reserve
cpuid 0 for the boot CPU in the ACPI and FDT cases but otherwise start the
CPU as normal. We then check for the boot CPU in start_cpu and return as if
it was started.
While here extract the FDT CPU init code into a new function to simplify
cpu_mp_start and return FALSE from start_cpu when the CPU fails to start.
Reviewed by: mmel
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D27497
This can be handy if gdb's stack unwinder fails, for example because of
a bug in kgdb's trap frame unwinder.
PR: 251463
Submitted by: Dmitry Salychev <dsl@mcusim.org>
MFC after: 1 week
In some error paths we would fail to detach from the iflib taskqueue
groups. Also move the detach code into its own subroutine instead of
duplicating it.
Submitted by: Sai Rajesh Tallamraju <stallamr@netapp.com>
MFC after: 2 weeks
Sponsored by: NetApp, Inc.
Differential Revision: https://reviews.freebsd.org/D27342
The integer arrays are encoded in nvlist as counted array <count, i0, i1...>,
loader xdr_array() is missing the count. This will affect the pool import when
there are hole devices in pool.
Also fix the new data add and print functions.
in the LinuxKPI. Linux defines min() to be a macro, while in FreeBSD
min() is a static inline function clamping its arguments to
"unsigned int".
MFC after: 1 week
Sponsored by: Mellanox Technologies // NVIDIA Networking
The old implementation chose the largest bucket zone such that if the
per-CPU caches are fully populated, the total number of items cached is
no larger than the specified limit. If no such zone existed, UMA would
not do any caching.
We can now use uz_bucket_size_max to set a precise limit on the number
of items in a zone's bucket, so the total size of per-CPU caches can be
bounded more easily. Implement a new policy in uma_zone_set_maxcache():
choose a bucket size such that up to half of the limit can be cached in
per-CPU caches, with the rest going to the full bucket cache. This
fixes a problem with the kstack_cache zone: the limit of 4 * mp_ncpus
items meant that the zone would not do any caching, defeating the whole
purpose of the zone. That's because the smallest bucket size holds up
to 2 items and we may cache up to 3 full buckets per CPU, and
2 * 3 * mp_ncpus > 4 * mp_ncpus.
Reported by: mjg
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D27168
uz_bucket_size_max is the maximum permitted bucket size. When filling a
new bucket to satisfy uma_zalloc(), the bucket is populated with at most
uz_bucket_size_max items. The maximum number of entries in the bucket
may be larger. When freeing items, however, we will fill per-CPPU
buckets up to their maximum number of entries, potentially exceeding
uz_bucket_size_max. This makes it difficult to precisely limit the
number of items that may be cached in a zone. For example, if one wants
to limit buckets to 1 entry for a particular zone, that's not possible
since the smallest bucket holds up to 2 entries.
Try to solve the problem by using uz_bucket_size_max to limit the number
of entries in a bucket. Note that the ub_entries field is initialized
upon every bucket allocation. Most zones are not affected since they do
not impose any specific limit on the maximum bucket size.
While here, remove the UMA_ZONE_MINBUCKET flag. It was unused and we
now have uma_zone_set_maxcache() to control the zone's cache size more
precisely.
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D27167
