r368355 removed the GNU_GREP_COMPAT knob (off by default) and forgot that
bsdgrep may be built/used for bootstrap on some systems.
All base uses should strive to use only POSIX-compliant expressions anyways
and we haven't had libregex by default here up to this point, so just don't
do that if we're bootstrapping.
Note that the resulting binary has the wrong `grep -V` information as it
falsely claims to be GNU compatible, but it is only for bootstrap.
Reported by: GitHub cross-builds via yuripv
Character width data being out of date is a constant source
of weird rendering issues and wasted time trying to diagnose
those, e.g. as reported by Jeremy Chadwick:
https://gitlab.com/muttmua/mutt/-/issues/67
Sadly, there is no real ("standard") wcwidth data source, so
this tries to rectify the problem using the utf8proc one (through
its C API) which would hopefully benefeat both FreeBSD and
utf8proc through bug reports (if any).
Reviewed by: bapt
Differential Revision: https://reviews.freebsd.org/D27259
This has already confused me once (and I'm pretty sure I wrote it), so let's
clarify: unjailing after the command has completed will only happen if we're
interactive and -U has not been specified.
This just folds two conditionals together to make it obvious how -b/-U
interact with each other.
MFC after: 3 days
linux_common.c to linux_util.c so they become available on i386.
linux_common.c defines the linux_common kernel module but this module does
not exist on i386 and linux_common.c is not included in the linux module.
linux_util.c is included in the linux_common module on amd64 and the linux
module on i386.
Remove linux_common.c from files.i386 again. It was added recently in
r367433 when the DTrace provider definitions were moved.
The V4L feature declarations were moved to linux_common in r283423.
In r367395 parts of machine dependent linux_dummy.c were moved to a new
machine independent file sys/compat/linux/linux_dummy.c and the existing
linux_dummy.c was renamed to linux_dummy_machdep.c.
Add linux_dummy_machdep.c to the linux module for i386.
Rename sys/amd64/linux32/linux_dummy.c for consistency.
Add the new linux_dummy.c to the linux module for i386.
Part of the libregex functionality leaked into the tests it shares with
the standard regex(3). Introduce a P flag to set the REG_POSIX cflag to
indicate that libc regex should effectively do nothing while libregex should
specifically run it in non-extended mode.
This unbreaks the libc/regex test run.
Reported by: Jenkins
- record MPIDR for all started cores in pcpu, they will be used as link
between physical locality of given core, ID in external description
(FDT or ACPI) and cupid.
- because of above, cpuid can (and should) be freely assigned, only boot
CPU must have cpuid 0. Simplify startup code according this.
Please note that pure cpuid is not sufficient instrument to hold any
information about core or cluster topology, nor to determistically iterate
over subpart of cores in CPU (iterate over all cores in single cluster for
example). Situation is more complicated by fact that PSCI can reject start
of core without reporting error (because power budget for example), or by
fact that is possible that we booted on non-first core in cluster (thus with
cpuid 0 assigned to random core).
Given cores topology should be exhibited to other parts of system
(for example to scheduler for big.little or multicluster systems) by using
smp_topo interface.
Differential Revision: https://reviews.freebsd.org/D13863
They were only modified to accomodate a redundant assertion.
This runs into problems as lockless lookup can still try to use the vnode
and crash instead of getting an error.
The bug was only present in kernels with INVARIANTS.
Reported by: kevans
It was realized just a little too late that this was a hack that belonged in
individual regex(3)-using applications. It was surrounded in NOTYET and not
implemented in the engine, so remove it.
This is the last of the needed GNU expressions before we can unleash bsdgrep
by default. \b is effectively an agnostic equivalent of \< and \>, while
\B will match every space that isn't making a transition from
nonchar -> char or char -> nonchar.
These are GNU extensions, generally equivalent to ^ and $ except that the
new syntax will not match beginning of line after the first in a multi-line
expression or the end of line before absolute last in a multi-line
expression.
This was introduced and then disabled by default primarily to avoid dealing
with bugs in libgnuregex. rS363823 switched to using libregex for it, so
let's just rip the option out now so we can make sure we're getting tested
with libregex via bsdgrep.
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D27476
Follow-up to r353959 and r368070: do the same for other architectures.
arm32 already seems to use its own .fnstart/.fnend directives, which
appear to be ARM-specific variants of the same thing. Likewise, MIPS
uses .frame directives.
Reviewed by: arichardson
Differential Revision: https://reviews.freebsd.org/D27387
bus_dmamap_sync() ensures that memory that's prepared for PREWRITE can
be DMA'd immediately after it returns. The details differ, but this
mirrors atomic thread release semantics, at least for the buffers
synced.
For non-x86 platforms, bus_dmamap_sync() has the right syncing and
fences. So in the past, wmb() had been omitted for them.
For x86 platforms, the memory ordering is already strong enough to
ensure DMA to the device sees the current contents. As such, we don't
need the wmb() here. It translates to an sfence which is only needed
for writes to regions that have the write combining attribute set or
when some exotic opcodes are used. The nvme driver does neither of
these. Since bus_dmamap_sync() includes atomic_thread_fence_rel, we
can be assured any optimizer won't reorder the bus_dmamap_sync and the
bus_space_write operations. The wmb() was a vestiage of the pre-busdma
version initially committed to the tree.
Reviewed by: kib@, gallatin@, chuck@, mav@
Differential Revision: https://reviews.freebsd.org/D27448
Add an explicit thread fence release before returning from
bus_dmamap_sync. This should be a no-op in practice, but makes
explicit that all ordinary stores will be completed before subsequent
reads/writes to ordinary device memory. On x86, normal memory ordering
is strong enough to generally guarantee this. The fence keeps the
optimizer (likely LTO) from reordering other calls around this.
The other architectures already have calls, as appropriate, that
are equivalent.
Note: On x86, there is one exception to this rule. If you've mapped
memory as write combining, then you will need to add a sfence or
similar. Normally, though, busdma doesn't operate on such memory, and
drivers that do already cope appropriately.
Reviewed by: kib@, gallatin@, chuck@, mav@
Differential Revision: https://reviews.freebsd.org/D27448
Enable in-kernel acceleration of SHA1 and SHA2 operations on arm64 by adding
support for the ossl(4) crypto driver. This uses OpenSSL's assembly routines
under the hood, which will detect and use SHA intrinsics if they are
supported by the CPU.
Reviewed by: jhb
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D27390
Make room for adding arm64 support to this driver by moving the
x86-specific feature parsing to a separate file.
Reviewed by: jhb
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D27388
- Fix kernel stack unwinding end-of-function false-positive
The kernel stack unwinder assumes that any jr $ra indicates the end
of the current function. However, modern compilers generate code
that contains jr $ra at various places inside the function.
- Handle LLD inter-function padding when looking for the start of a
function.
- Use call site for symbol name/offset when unwinding
Currently we use the return address, which will normally just give
an output that's off by 8 from the actual call site. However, for
tail calls, this is particularly bad, as we end up printing the
symbol name for the function that comes after the one that made the
call. Instead we should go back two instructions from the return
address for the unwound program counter.
Submitted by: arichardson (1, 2), jrtc27 (3)
Reviewed by: arichardson
Obtained from: CheriBSD
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D27363
r366857 created a number of problems, tearing down interfaces too
early in shutdown. This resulted in:
- hung ssh sessions when shutting down or rebooting remotely using
shutdown (I've used exec shutdown, for years, as apposed to simply
shutdown).
- NFS mounted filesystems "disappear" prior to unmount.
- dhclient attached to a VLAN on an interface who's parent interface
has already shut down prints errors.
The path forward is to teach lagg(4) and vlan(4) about WOL.
PR: 251531, 251540
PR: 158734, 109980 are broken again
Reported by: jhb, emaste, jtl, Helge Oldach<freebsd_oldach.net>
Martin Birgmeier <d8zNeCFG_aon.at>
MFC after: Immediately
Discussion at: https://reviews.freebsd.org/D27459
struct timex is not 32-bit safe, it uses longs for members.
Provide translation.
Reviewed by: brooks, cy
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D27471
While porting over the local changes from CheriBSD for upstreaming, I
accidentally committed a broken version of find_entry_point(): we have to
return NULL if the value is not found instead of a value with
ep->name == NULL, since the checks in main were changed to check ep instead
of ep->name for NULL.
This only matters if the crunched tool cannot be found using normal lookup
and one of the fallback paths is used, so it's unlikely to be triggered
in rescue. However, I noticed that one of our CheriBSD test scripts was
failing to run commands under `su` on minimal disk images where all
binaries are hardlinks to a `cheribsdbox` tool generated with crunchgen.
This also updates the bootstrapping check in Makefile.inc1 to bootstrap
crunchgen up to the next version bump.
Reviewed By: kevans
Differential Revision: https://reviews.freebsd.org/D27474
bsdgrep switched over to libregex back in r363823 to fill
WITH_GNU_GREP_COMPAT, since libgnuregex in base is quite buggy and libregex
is somewhat functional. Don't build libgnuregex on our account, please.
