emaste [Tue, 30 Jan 2018 01:13:06 +0000 (01:13 +0000)]
MFC r328305: libcxxrt: Move mangled symbols out of extern "C++" in Version.map
r260553 added a number of mangled C++ symbols to Version.map inside of
an existing `extern "C++"` block.
ld.bfd 2.17.50 treats `extern "C++"` permissively and will match both
mangled and demangled symbols against the strings in the version map
block. ld.lld interprets `extern "C++"` strictly, and matches only
demangled symbols.
I believe lld's behaviour is correct. Contemporary versions of ld.bfd
also behave as lld does, so move the mangled symbols out of the
`extern "C++"` block.
PR: 225128, 185663
Sponsored by: The FreeBSD Foundation
jhb [Tue, 30 Jan 2018 00:52:22 +0000 (00:52 +0000)]
MFC 327792: Don't store shadow copies of per-process AIO limits.
Previously the AIO subsystem would save a snapshot of the currently
configured per-process limits the first time a process used AIO. The
process would continue to use the snapshotted limits ignoring any
changes to the global limits during the rest of its lifetime. This
change removes the snapshotted values and changes the AIO code to
always check the global values which can be toggled at runtime.
This means an administrator can now change the effective limits of
existing processes. This is more consistent with how other limits
configured via sysctl work in FreeBSD.
jhb [Tue, 30 Jan 2018 00:41:54 +0000 (00:41 +0000)]
MFC 327755: Allow the fast-path for disk AIO requests to fail requests.
- If aio_qphysio() returns a non-zero error code, fail the request rather
than queueing it to the AIO kproc pool to be retried via the slow path.
Currently this means that if vm_fault_quick_hold_pages() reports an
error, EFAULT is returned from the fast-path rather than retrying the
request in the slow path where it will still fail with EFAULT.
- If aio_qphysio() wishes to use the fast path for a device that doesn't
support unmapped I/O but there are already the maximum number of
such requests in flight, fail with EAGAIN as we do for other AIO
resource limits rather than queueing the request to the AIO kproc pool.
- Move the opcode check for aio_qphysio() out of the caller and into
aio_qphysio() to simplify some logic and remove two goto's while here.
It also uses a whitelist (only supported for LIO_READ / LIO_WRITE)
rather than a blacklist (skipped for LIO_SYNC).
jhb [Mon, 29 Jan 2018 23:43:04 +0000 (23:43 +0000)]
MFC 327561:
Report offset relative to the backing object for kinfo_vmentry structures.
For the pathname reported in kinfo_vmentry structures (kve_path), the
sysctl handlers walk the object chain to find the bottom-most VM object.
This permits a COW mapping of a file with dirty pages to report the
pathname of the originally mapped file. Do the same for the object
offset (kve_offset) computing a cumulative offset during the same object
walk so that the reported offset is relative to the reported pathname.
Note that ptrace(PT_VM_ENTRY) already returns a cumulative offset
rather than the raw offset of the VM map entry.
Note also that this does not affect procstat -v output (even structured
output) since that output does not include the kve_offset field.
cognet [Sun, 28 Jan 2018 18:38:17 +0000 (18:38 +0000)]
MFC revisions r309268, r309260, r309264, r309266, r309267, r309270, r310846,
r314435, r314564, r316665, r316691, r316702.
Those import ConcurrencyKit in the FreeBSD kernel.
A few people have showed interest in this being MFC'd, so here we go.
kevans [Sat, 27 Jan 2018 23:20:01 +0000 (23:20 +0000)]
MFC r328188,r328189,r328200: Fix wrong output for multibyte corner cases
MFC r328188: od(1): Fix wrong output for corner cases in multibyte locales.
Restore the original character to print if we used the look-ahead
buffer, but that didn't help -- we either got an illegal sequence
or still can't complete.
MFC r328189: od(1): Fix mis-patch from r328188
od_test.sh got duplicated erroneously when it was added in r328188. Dedup.
MFC r328200: Silence the gcc warning: 'op' may be used uninitialized in this
function
kevans [Sat, 27 Jan 2018 23:13:34 +0000 (23:13 +0000)]
MFC (conceptually) r328107: Add /boot/overlays
This is a direct commit to stable/11, due to path changes in HEAD. Diffs
have been applied on top of stable/11, with exception to the change to
forth/loader.conf. forth/loader.conf has seen additional changes in HEAD
mthat are not being MFC'd to stable/11, so the addition of /boot/overlays to
its module_path is not necessary.
MFC r328107: stand: Add /boot/overlays for separation of overlays from DTB
This matches directory structure used commonly in Linux-land, and it's
cleaner than mixing overlays into the existing module paths. Overlays are
still mixed in by specifying fdt_overlays in loader.conf(5).
Highlights of this update:
- /__local_fixups__ is now generated to be GPL dtc and libfdt compliant
- Compiling with -@ will now cause dtc to assign phandles to all labelled
nodes
- /include/ and /incbin/ now handle absolute paths correctly
- The manpage now has information about overlays, including how to apply
them and how to generate them
- Syntactic sugar for overlays is now supported, allowing an overlay DTS
like:
dumbbell [Sat, 27 Jan 2018 16:48:29 +0000 (16:48 +0000)]
psm: Don't try to detect trackpoint packets if the Elantech device has none
This fixes a panic when `EVDEV_SUPPORT` is enabled: if a trackpoint
packet was detected but there was no trackpoint, we still tried to emit an
evdev event even though the associated relative evdev device (`evdev_r`)
was not initialized.
dumbbell [Sat, 27 Jan 2018 16:36:06 +0000 (16:36 +0000)]
psm: Skip sync check when `PSM_CONFIG_NOCHECKSYNC` is set
In psmprobe(), we set the initial `syncmask` to the vendor default value
if the `PSM_CONFIG_NOCHECKSYNC` bit is unset. However, we currently only
set it for the Elantech touchpad later in psmattach(), thus `syncmask`
is always configured.
Now, we check `PSM_CONFIG_NOCHECKSYNC` and skip sync check if it is set.
This fixes Elantech touchpad support for units which have `hascrc` set.
To clarify that, when we log the `syncmask` and `syncbits` fields, also
mention if they are actually used.
Finally, when we set `PSM_CONFIG_NOCHECKSYNC`, clear `PSM_NEED_SYNCBITS`
flag.
kevans [Sat, 27 Jan 2018 06:31:14 +0000 (06:31 +0000)]
MFC r320930,r324286: Add tests for hexdump(1)
MFC r320930:
Add some basic tests for hexdump(1)'s various output flags. Formatting
tests are omitted for this initial run as there are still some bugs to work
out there.
This covers -s flag testing on devices and non-devices that would have
caught breakage found in PR 219173 as well as other subtle breakage caused
locally.
MFC r324286: hexdump: Remove expected test failures for now succeeding tests
r323990 fixed the -s flag breakage reported by PR 219173. Mark the
corresponding hexdump tests accordingly, since they should now both succeed.
kevans [Sat, 27 Jan 2018 06:20:27 +0000 (06:20 +0000)]
MFC r327826: patch(1): Don't check for NUL bytes in Plan A
Plan A mmap()'s the entire input file and operates on it in memory. The
map(2) call succeeded, so we shouldn't need to bother checking for the NUL
byte as long as we're within our buffer space.
This was clearly intentional to match "the behavior of the original code",
but it creates a discrepancy between Plan A and Plan B that doesn't seem
sensible and it's not inherently wrong to allow a NUL byte.
This change was motivated by the gemspec in net/rubygem-grpc failing to
patch, despite the patch being generated with diff, because a NUL byte was
used as a delimiter in the header briefly in an otherwise text file.
An alternative was considered: to fallback to plan B if plan A won't process
the entire file due to a NUL byte, but I deemed this to be the better option
since plan A isn't failing due to memory limitations and will fail later on
if it's really dealing with a file it shouldn't be.
kevans [Sat, 27 Jan 2018 06:15:24 +0000 (06:15 +0000)]
MFC r326483: grep test: Fix copyright notice
The copyright notice was erroneously introduced as one from the NetBSD
foundation due to it being copied from a file in the NetBSD test suite, but
this file itself is not derived from or supplied with the NetBSD test suite.
MFC r314467 (imp): Make wsp process a single touchpad tap and interpret it
as a left-click event. It can be disabled by setting the new
hw.usb.wsp.enable_single_tap_clicks sysctl to 0.
MFC r328027: wsp(4): Update to reflect new sysctl from r314467
r314467 introduced hw.usb.wsp.enable_single_tap_clicks to enable/disable
single-tap left click behavior. Update the man page to reflect the new
sysctl.
kevans [Sat, 27 Jan 2018 05:56:16 +0000 (05:56 +0000)]
MFC (conceptually) r328106: libfdt: Update to 1.4.6, use libfdt for overlays
This is a direct commit to stable/11 due to path changes in HEAD. Diffs have
been applied on top of their previous locations, with one minor adjustment
as per the "MFC" note below: a <stdlib.h> include in libfdt_env.h h as been
wrapped in an `#ifndef _STANDALONE` block to prevent build failures when
built in the bootloader context. These issues are not present in HEAD, thus
this differs from HEAD.
libfdt highlights since 1.4.3:
- fdt_property_placeholder added to create a property without specifying its
value at creation time
- stringlist helper functions added to libfdt
- Improved overlay support
- Various internal cleanup
Also switch stand/fdt over to using libfdt for overlay support with this
update. Our current overlay implementation works only for limited use cases
with overlays generated only by some specific versions of our dtc(1). Swap
it out for the libfdt implementation, which supports any properly generated
overlay being applied to a properly generated base.
This will be followed up fairly soon with an update to dtc(1) in tree to
properly generate overlays.
MFC note: the <stdlib.h> include this update introduces in libfdt_env.h is
apparently not necessary in the context we use this in. It's not immediately
clear to me the motivation for it being introduced, but it came in with
overlay support. I've left it in for the sake of accuracy and because it's
not harmful here on HEAD, but MFC'ing this to stable/11 will require
wrapping the #include in an `#ifndef _STANDALONE` block or else it will
cause build failures.
jhb [Fri, 26 Jan 2018 23:49:31 +0000 (23:49 +0000)]
MFC 326184: Decode kevent structures logged via ktrace(2) in kdump.
- Add a new KTR_STRUCT_ARRAY ktrace record type which dumps an array of
structures.
The structure name in the record payload is preceded by a size_t
containing the size of the individual structures. Use this to
replace the previous code that dumped the kevent arrays dumped for
kevent(). kdump is now able to decode the kevent structures rather
than dumping their contents via a hexdump.
One change from before is that the 'changes' and 'events' arrays are
not marked with separate 'read' and 'write' annotations in kdump
output. Instead, the first array is the 'changes' array, and the
second array (only present if kevent doesn't fail with an error) is
the 'events' array. For kevent(), empty arrays are denoted by an
entry with an array containing zero entries rather than no record.
- Move kevent decoding tables from truss to libsysdecode.
This adds three new functions to decode members of struct kevent:
sysdecode_kevent_filter, sysdecode_kevent_flags, and
sysdecode_kevent_fflags.
kdump uses these helper functions to pretty-print kevent fields.
- Move structure definitions for freebsd11 and freebsd32 kevent
structures to <sys/event.h> so that they can be shared with userland.
The 32-bit structures are only exposed if _WANT_KEVENT32 is defined.
The freebsd11 structures are only exposed if _WANT_FREEBSD11_KEVENT is
defined. The 32-bit freebsd11 structure requires both.
- Decode freebsd11 kevent structures in truss for the compat11.kevent()
system call.
- Log 32-bit kevent structures via ktrace for 32-bit compat kevent()
system calls.
- While here, constify the 'void *data' argument to ktrstruct().
Note that this version of the change for 11.x does not include freebsd11
kevent structures or _WANT_FREEBSD11_KEVENT. It also does not include
the change to decode the compat11.kevent system call in truss.
kevans [Fri, 26 Jan 2018 22:23:24 +0000 (22:23 +0000)]
MFC (conceptually) r327991, r328009: Don't clobber FDT enroute to the kernel
This is a direct commit to stable/11 due to path changes that have occured
in HEAD. The diffs remain the same, but rebased against their old locations.
MFC r327991: stand/fdt: don't send clobbered FDT to the kernel
If fdt_overlay_apply fails at some stage to apply the overlay to the base,
both the base and overlay may be in an inconsistent state (some fixups
applied, some phandles adjusted, some symbols merged). These can be bad for
a number of reasons, to include user frustration if some fixups applied and
not others. Fail a little safer by making a clean copy of the base FDT for
every overlay that we can simply discard if things go awry.
This also allows us the luxury of simply discarding overlays if we hit some
kind of memory limit or if they're malformed and extremely large for some
reason. We'll now leave a nice error message indicating that some overlays
could not be applied due to size restrictions and we apply what we can.
I note that our overlay implementation has some flaws that might still leave
your system in an unbootable state even if an overlay applies correctly;
please exercise caution in using overlays until we can swap it out for
libfdt's implementation.
MFC r328009: stand/fdt: Don't leak next_fdtp if we fail to open overlay
gjb [Fri, 26 Jan 2018 04:32:31 +0000 (04:32 +0000)]
MFC r328283, r328284:
r328283:
When CHROOTBUILD_SKIP is set, evaluate the existence of /bin/sh
within the CHROOTDIR. If it does not exist, unset CHROOTBUILD_SKIP
to prevent build failures.
jhb [Wed, 24 Jan 2018 21:48:39 +0000 (21:48 +0000)]
MFC 325028,328344: Discard the correct thread event reported for a ptrace stop.
325028:
Discard the correct thread event reported for a ptrace stop.
When multiple threads wish to report a tracing event to a debugger,
both threads call ptracestop() and one thread will win the race to be
the reporting thread (p->p_xthread). The debugger uses PT_LWPINFO
with the process ID to determine which thread / LWP is reporting an
event and the details of that event. This event is cleared as a side
effect of the subsequent ptrace event that resumed the process
(PT_CONTINUE, PT_STEP, etc.). However, ptrace() was clearing the
event identified by the LWP ID passed to the resume request even if
that wasn't the 'p_xthread'. This could result in clearing an event
that had not yet been observed by the debugger and leaving the
existing event for 'p_thread' pending so that it was reported a second
time.
Specifically, if the debugger stopped due to a software breakpoint in
one thread, but then switched to another thread that was used to
resume (e.g. if the user switched to a different thread and issued a
step), the resume request (PT_STEP) cleared a pending event (if any)
for the thread being stepped. However, the process immediately
stopped and the first thread reported it's breakpoint event a second
time. The debugger decremented the PC for "both" breakpoint events
which resulted in the PC now pointing into the middle of an
instruction (on x86) and a SIGILL fault when the process was resumed a
second time.
To fix, always clear the pending event for 'p_xthread' when resuming a
process. ptrace() still honors the requested LWP ID when enabling
single-stepping (PT_STEP) or setting a different PC (PT_CONTINUE).
328344:
Mark the unused argument to continue_thread() as such.
clang in HEAD and 11 does not warn about this, but clang in 10 does.
emaste [Wed, 24 Jan 2018 00:52:25 +0000 (00:52 +0000)]
MFC r327770: lld: introduce basic man page
Upstream lld has no man page. Introduce a basic one for FreeBSD based on
ld.lld --help, with a brief introduction and additional detail for some
options.
We'll continue refining this in FreeBSD, and then submit it upstream once
the first round of edits are complete.
Submitted by: krion, Arshan Khanifar, emaste, bjk
Sponsored by: The FreeBSD Foundation
jhb [Wed, 24 Jan 2018 00:32:02 +0000 (00:32 +0000)]
MFC 326953:
Catch up to r325719 which makes the kern.proc.pid sysctl "work" for zombies.
Some of the ptrace tests need to wait for a child process to become a
zombie before preceding. The parent process polls the child process
via the kern.proc.pid sysctl to wait for it to become a zombie.
Previously the code polled until the sysctl failed with ESRCH. Now it
will poll until either the sysctl fails with ESRCH (for compatiblity
with older kernels) or returns a kinfo_proc structure with the ki_stat
field set to SZOMB.
pfg [Wed, 24 Jan 2018 00:11:46 +0000 (00:11 +0000)]
MFC r328221:
Define a new __alloc_size2 attribute to complement the existing support.
At least on GCC7, calling __alloc_size(x) twice is not equivalent to
calling using the attribute once with two arguments. The later is the
documented use in GCC documentation so add a new alloc_size(n, x)
alternative to cover for the few places where it is used: basically:
calloc(3), reallocarray(3) and mallocarray(9).
jhb [Tue, 23 Jan 2018 20:08:25 +0000 (20:08 +0000)]
MFC 320900,323882,324224,324226,324228,326986,326988,326989,326990,326993,
326994,326995,327004: Various fixes for pathconf(2).
The original change to use vop_stdpathconf() more widely was motivated
by a panic due to recent AIO-related changes. However, bde@ reported
that vop_stdpathconf() contained too many settings that were not
filesystem-independent. The end result of this set of patches is to
fix the AIO-related panic via use of a trimmed-down vop_stdpathconf()
while also adding support for missing pathconf variables in various
filesystems (and removing a few settings incorrectly reported as
supported).
320900:
Consistently use vop_stdpathconf() for default pathconf values.
Update filesystems not currently using vop_stdpathconf() in pathconf
VOPs to use vop_stdpathconf() for any configuration variables that do
not have filesystem-specific values. vop_stdpathconf() is used for
variables that have system-wide settings as well as providing default
values for some values based on system limits. Filesystems can still
explicitly override individual settings.
323882:
Only handle _PC_MAX_CANON, _PC_MAX_INPUT, and _PC_VDISABLE for TTY devices.
Move handling of these three pathconf() variables out of vop_stdpathconf()
and into devfs_pathconf() as TTY devices can only be devfs files. In
addition, only return settings for these three variables for devfs devices
whose device switch has the D_TTY flag set.
324224:
Handle _PC_FILESIZEBITS and _PC_SYMLINK_MAX pathconf() requests in cd9660.
cd9660 only supports symlinks with Rock Ridge extensions, so
_PC_SYMLINK_MAX is conditional on Rock Ridge.
324226:
Return 64 for pathconf(_PC_FILESIZEBITS) on tmpfs.
324228:
Flesh out pathconf() on UDF.
- Return 64 bits for _PC_FILESIZEBITS.
- Handle _PC_SYMLINK_MAX.
- Defer _PC_PATH_MAX to vop_stdpathconf().
326986:
Add a custom VOP_PATHCONF method for fdescfs.
The method handles NAME_MAX and LINK_MAX explicitly. For all other
pathconf variables, the method passes the request down to the underlying
file descriptor. This requires splitting a kern_fpathconf() syscallsubr
routine out of sys_fpathconf(). Also, to avoid lock order reversals with
vnode locks, the fdescfs vnode is unlocked around the call to
kern_fpathconf(), but with the usecount of the vnode bumped.
326988:
Add a custom VOP_PATHCONF method for fuse.
This method handles _PC_FILESIZEBITS, _PC_SYMLINK_MAX, and _PC_NO_TRUNC.
For other values it defers to vop_stdpathconf().
326989:
Support _PC_FILESIZEBITS in msdosfs' VOP_PATHCONF().
326990:
Handle _PC_FILESIZEBITS and _PC_NO_TRUNC for smbfs' VOP_PATHCONF().
326993:
Move NAME_MAX, LINK_MAX, and CHOWN_RESTRICTED out of vop_stdpathconf().
Having all filesystems fall through to default values isn't always correct
and these values can vary for different filesystem implementations. Most
of these changes just use the existing default values with a few exceptions:
- Don't report CHOWN_RESTRICTED for ZFS since it doesn't do the exact
permissions check this claims for chown().
- Use NANDFS_NAME_LEN for NAME_MAX for nandfs.
- Don't report a LINK_MAX of 0 on smbfs. Now fail with EINVAL to
indicate hard links aren't supported.
326994:
Handle _PC_FILESIZEBITS and _PC_SYMLINK_MAX for devfs' VOP_PATHCONF().
326995:
Use FUSE_LINK_MAX for LINK_MAX in fuse' VOP_PATHCONF().
Should have included this in r326993.
327004:
Rework pathconf handling for FIFOs.
On the one hand, FIFOs should respect other variables not supported by
the fifofs vnode operation (such as _PC_NAME_MAX, _PC_LINK_MAX, etc.).
These values are fs-specific and must come from a fs-specific method.
On the other hand, filesystems that support FIFOs are required to
support _PC_PIPE_BUF on directory vnodes that can contain FIFOs.
Given this latter requirement, once the fs-specific VOP_PATHCONF
method supports _PC_PIPE_BUF for directories, it is also suitable for
FIFOs permitting a single VOP_PATHCONF method to be used for both
FIFOs and non-FIFOs.
To that end, retire all of the FIFO-specific pathconf methods from
filesystems and change FIFO-specific vnode operation switches to use
the existing fs-specific VOP_PATHCONF method. For fifofs, set it's
VOP_PATHCONF to VOP_PANIC since it should no longer be used.
While here, move _PC_PIPE_BUF handling out of vop_stdpathconf() so that
only filesystems supporting FIFOs will report a value. In addition,
only report a valid _PC_PIPE_BUF for directories and FIFOs.
kp [Tue, 23 Jan 2018 04:30:46 +0000 (04:30 +0000)]
MFC r327675
pf: Avoid integer overflow issues by using mallocarray() iso. malloc()
pfioctl() handles several ioctl that takes variable length input, these
include:
- DIOCRADDTABLES
- DIOCRDELTABLES
- DIOCRGETTABLES
- DIOCRGETTSTATS
- DIOCRCLRTSTATS
- DIOCRSETTFLAGS
All of them take a pfioc_table struct as input from userland. One of
its elements (pfrio_size) is used in a buffer length calculation.
The calculation contains an integer overflow which if triggered can lead
to out of bound reads and writes later on.
Reported by: Ilja Van Sprundel <ivansprundel@ioactive.com>
cy [Tue, 23 Jan 2018 04:01:48 +0000 (04:01 +0000)]
MFC r327718:
When growing the state, also grow the seed array. Otherwise memory
that was not allocated will be accessed.
This necessitated refactoring state seed allocation from
ipf_state_soft_init() into a new common ipf_state_seed_alloc() function
as it is now also used by ipf_state_rehash() when changing the size of
the state hash table in addition to by ipf_state_soft_init() during
initialization.
According to Christos Zoulas <christos@NetBSD.org>:
The bug was encountered by a NetBSD vendor who's customer machines had
large ipfilter states. The bug was reliably triggered by resizing the
state variables using "ipf -T".
https://www.illumos.org/issues/8373
The code that writes ZIL blocks uses dmu_tx_assign(TXG_WAIT) to assign
a transaction to a transaction group. That seems to be logically
incorrect as writing of the ZIL block does not introduce any new dirty
data. Also, when there is a lot of dirty data, the call can introduce
significant delays into the ZIL commit path, thus affecting all
synchronous writes. Additionally, ARC throttling may affect the ZIL
writing.
Reviewed by: Matthew Ahrens <mahrens@delphix.com>
Reviewed by: Prakash Surya <prakash.surya@delphix.com>
Approved by: Dan McDonald <danmcd@joyent.com>
Author: Andriy Gapon <avg@FreeBSD.org>
kp [Sat, 20 Jan 2018 23:46:03 +0000 (23:46 +0000)]
MFC r327674, r327796
Introduce mallocarray() in the kernel
Similar to calloc() the mallocarray() function checks for integer
overflows before allocating memory.
It does not zero memory, unless the M_ZERO flag is set.
Additionally, move the overflow check logic out to WOULD_OVERFLOW() for
consumers to have a common means of testing for overflowing allocations.
WOULD_OVERFLOW() should be a secondary check -- on 64-bit platforms, just
because an allocation won't overflow size_t does not mean it is a sane size
to request. Callers should be imposing reasonable allocation limits far,
far, below overflow.
cy [Sat, 20 Jan 2018 18:00:42 +0000 (18:00 +0000)]
MFC r327912:
Though this block of code is not used by FreeBSD, correct a call to
sprintf() with a macro call to SNPRINTF similar to other calls to
SNPRINTF within this same block.
mav [Fri, 19 Jan 2018 16:06:52 +0000 (16:06 +0000)]
MFC r323317 (by scottl): Move the intrhook release to later in the function
so that GEOM knows to wait longer for possible root devices to come online.
This fixes a race that seems to be triggered by EARLY_AP_STARTUP.
kevans [Thu, 18 Jan 2018 22:13:31 +0000 (22:13 +0000)]
MFC r322288: regex(3): Refactor fast/slow stepping bits in matching engine
Adding features for matching is fairly straightforward, but this requires
some duplication because of this fast/slow setup. They can be fairly
trivially combined into a single walk(), so do it to make future additions
less error prone.
kevans [Thu, 18 Jan 2018 22:10:00 +0000 (22:10 +0000)]
MFC r320742, r320750, r320796: Refactor regex(3) for maintainability
MFC r320742:
The impending libregex will implement GNU extensions to bring BREs and
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.
MFC r320750: Fix sparc64 libc build after r320742.
p_branch_empty was declared but never used due to an oversight. Use it as
designed, further comment on its return value.
MFC r320796:
Correctly ignore branch operators in the top-level parser when applicable.
An oversight in r320742 caused BREs to become sensitive to the branching
operator prematurely, which caused breakage in some limited situations --
namely, those that tried to use branching in a BRE. Most of these scenarios
had already been corrected beforehand to properly use gsed or grep for GNU
extensions, so the damage is slightly mitigated.
kevans [Thu, 18 Jan 2018 21:59:13 +0000 (21:59 +0000)]
MFC r327567: hexdump(1): Speed up -s flag on devices
Using the -s flag on devices is extraordinarily slow due to using fseek(3) a
little too conservatively. Address this by using fseek on character/block
devices as well, falling back to getchar(3) only if we fail to seek or we're
operating on tape drives, where fseek may succeed while not actually being
supported.
kevans [Thu, 18 Jan 2018 21:53:07 +0000 (21:53 +0000)]
MFC r326084: patch(1): don't assume match if we run out of context to check
Patches with very little context (-U0 and -U1) could get misapplied if
the file to be patched changes and a hunk is no longer applicable. Matching
with fuzz would be attempted and default to a match when we unexpectedly ran
out of context.
This also affected patches with higher levels of context but had limited
actual context due to the hunk being located near the beginning/end of file.
kevans [Thu, 18 Jan 2018 21:46:42 +0000 (21:46 +0000)]
MFC r324431: patch(1): Don't overrun line buffer in some cases
Patches like file.txt attached to PR 190195 with a final line formed
like ">(EOL)" could cause a copy past the end of the current line buffer. In
the case of PR 191641, this caused a duplicate line to be copied into the
resulting file.
Instead of running past the end, treat it as if it were a blank line.
kevans [Thu, 18 Jan 2018 21:39:03 +0000 (21:39 +0000)]
MFC r322322: Expose device caps as libusb_bos_descriptor::dev_capability
Some libusb consumers in Linux-land (in this case, libusb4java) expect a
dev_capability member that they can use to enumerate the device
capabilities.
No particular layout is expected of this, just that it can be traversed
using the bLength member until bNumDeviceCapabilities are read and that the
consumer may then use one of the libusb_get_*_descriptor methods to extract
specific (usb 2.0 vs. ss) capability information.
kevans [Thu, 18 Jan 2018 21:29:46 +0000 (21:29 +0000)]
MFC r322177: Respect SIMPLE_BACKUP_SUFFIX environment variable in indent(1)
Instead of using a non-configurable ".BAK" suffix, respect the
SIMPLE_BACKUP_SUFFIX environment variable also used by patch(1). This
simplifies cleanup operations in some patch/indent workflows.
ed [Thu, 18 Jan 2018 13:43:09 +0000 (13:43 +0000)]
MFC r327560:
Allow timed waits with relative timeouts on locks and condvars.
Even though pthreads doesn't support this, there are various alternative
APIs that use this. For example, uv_cond_timedwait() accepts a relative
timeout. So does Rust's std::sync::Condvar::wait_timeout().
Though I personally think that relative timeouts are bad (due to
imprecision for repeated operations), it does seem that people want
this. Extend the existing futex functions to keep track of whether an
absolute timeout is used in a boolean flag.
Pull in r314838 from upstream clang trunk (by Richard Smith):
Suppress -Wmissing-braces warning when aggregate-initializing a
struct with a single field that is itself an aggregate.
In C++, such initialization of std::array<T, N> types is guaranteed
to work by the standard, is completely idiomatic, and the "suggested"
alternative from Clang was technically invalid.
Together, these suppress unneeded "suggest braces around initialization
of subobject" warnings for C++11 initializer lists.
kevans [Sun, 14 Jan 2018 05:10:02 +0000 (05:10 +0000)]
MFC (conceptually) r327377: Pull in strnlen for sys/boot environment
This is a direct commit to stable/11 due to restructuring of lib/libstand =>
stand/libsa in -HEAD. The diff remains the same and it is simply applied to
the previous location.
MFC r327377: Pull in strnlen from libc
strnlen is not used at the moment, but it will be when libfdt gets updated.
Prepare for the not-so-distant future by pulling in strnlen.
This is a direct commit to stable/11 due to restructuring of sys/boot =>
stand in -HEAD. The diff remains the same and it is simply applied to the
previous location.
MFC r327376: stand/fdt: Swap libfdt include order
libfdt.h should be included before fdt.h, as hinted at by all of libfdt/;
standard include order being libfdt.h, libfdt_env.h, fdt.h.
The current include order also causes problems when libfdt gets updated, as
fdt.h requires some definitions from libfdt.h.
MFC r327416: stand/fdt: Make fdt_overlay_apply signature-compatible with
libfdt
libfdt will assume a writable fdt overlay blob has been passed in, so make
ours compatible to allow easier review when we try to drop libfdt into
place. overlay from the calling context is writable, making it safe to
simply rip out everything related to copying the overlay blob in
fdt_overlay_apply.
I note here that we still have problems: fdt_overlay_apply, both our version
and libfdt's, may fail and have already clobbered the base fdt to some
extent. Future work will make sure we don't apply a potentially bogus fdt,
instead discarding the base fdt if we had an error.
This is a direct commit to stable/11 due to restructuring of sys/boot =>
stand in -HEAD. The diff remains the same and it is simply applied to the
previous location.
This is a direct commit to stable/11 due to restructuring of sys/boot =>
stand in -HEAD. The diff remains the same and it simply applied to the
previous location.
MFC r327298: stand/fdt: Fix loading of multiple fdt_overlays
fdt_load_dtb_overlays was written to unload previous overlay when a new
valid one is come across. fdt_apply_overlays further down is written to
iterate over all .dtbo's currently loaded and apply them one-by-one. Correct
fdt_load_dtb_overlays to stop dropping valid overlays that were previously
loaded and match expectations.
MFC r327299: stand/fdt: Avoid bailout when dtbo has no fixups
In the case of a simple dtbo where fragment uses target-path and the overlay
contains no references, /__fixups__ will not be included by either our dtc
or dtc from ports, but the file still has valid fragments to be applied.
Additional testing found that /__symbols__ might also be omitted if it's
empty, which is not necessarily an error.
projects / FreeBSD / FreeBSD.git / log