r317049 added -z/--null-data to BSD grep but missed the update to nls
catalogs.
Submitted by: Kyle Evans <kevans91 at ksu.edu>
Differential Revision: https://reviews.freebsd.org/D10456
As reported in r218614 it's useful to have an indication of whether or not
BSD grep was built with GNU_GREP_COMPAT.
Submitted by: Kyle Evans <kevans91 at ksu.edu>
Reported by: mandree
Differential Revision: https://reviews.freebsd.org/D10451
-w and -v flag matching was mostly functional but had some minor
problems:
1. -w flag processing only allowed one iteration through pattern
matching on a line. This was problematic if one pattern could match
more than once, or if there were multiple patterns and the earliest/
longest match was not the most ideal, and
2. Previous work "fixed" things to not further process a line if the
first iteration through patterns produced no matches. This is clearly
wrong if we're dealing with the more restrictive -w matching.
#2 breakage could have also occurred before recent broad rewrites, but
it would be more arbitrary based on input patterns as to whether or not
it actually affected things.
Fix both of these by forcing a retry of the patterns after advancing
just past the start of the first match if we're doing more restrictive
-w matching and we didn't get any hits to start with. Also move -v flag
processing outside of the loop so that we have a greater change to match
in the more restrictive cases. This wasn't strictly wrong, but it could
be a little more error prone.
While here, introduce some regressions tests for this behavior and fix
some excessive wrapping nearby that hindered readability. GNU grep
passes these new tests.
PR: 218467, 218811
Submitted by: Kyle Evans <kevans91 at ksu.edu>
Reviewed by: cem, ngie
Differential Revision: https://reviews.freebsd.org/D10329
Accomplish this by allocating space for it in __svc_xports and allowing
it to be registered. The failure to allocate space was causing an
out-of-bounds read in svc_getreq_common(). The failure to register
caused PR 211804.
The bug was found with CHERI bounds checking.
PR: 211804
Obtained from: CheriBSD
Sponsored by: DARPA, AFRL
Reviewed by: ngie
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D10528
At least with Tx FIFO enabled it shows me ~10% reduction of verbose boot
time with serial console at 115200 baud.
Reviewed by: marcel
MFC after: 2 weeks
These are only built as part of the top-level 'build-tools' call for
'make buildworld'. They still need to be cleaned during the 'make clean'
treewalks though.
Reported by: markj
MFC after: 2 weeks
Sponsored by: Dell EMC Isilon
camcontrol timestamp -s would somtimes fail due to stack garbage. Zero out
the timestamp parameters to fix it.
Fix another nearby bug, and update the man page.
sbin/camcontrol/timestamp.c:
In set_timestamp(), bzero ts_p prior to creating the timestamp.
Previously stack garbage could cause some tape drives to reject the
timestamp.
In set_timestamp(), check for failures from strptime().
sbin/camcontrol/camcontrol.8:
Add the time argument to the -T option to camcontrol timestamp -s
in the long description.
Change the time/date format used in the camcontrol timestamp
example to RFC 2822 format. This fixes a time zone issue with the
original example by specifying the time zone as -0600. Otherwise,
the time zone seems to default to standard time in the current
locale, which makes the time, when reported back from the drive,
1 hour off from the intended setting. This also fixes a duplicate
day of the week ("Wednesday Wed") in the previous example.
Submitted by: Sam Klopsch
MFC after: 3 days
Sponsored by: Spectra Logic
The current reboot command in efi/loader/main.c is passing extra data with
ResetSystem, however, UEFI spec 2.6, page 265 does state:
"ResetData is only valid if ResetStatus is something other than EFI_SUCCESS
unless the ResetType is EfiResetPlatformSpecific where a minimum amount of
ResetData is always required."
Therefore we should use DataSize 0 and ResetData NULL - those are two last
arguments for the call.
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D10562
The mutex is used in sem_open() and sem_close(), which cannot
recurse. The atfork handlers cannot collide with the open and close
code.
Reviewed by: vangyzen
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D10545
Do not retest for the found semaphore after the loop to look it up.
Instead, handle both cases of last and non-last close simultaneously,
which allows to consolidate the list unlock and successful return.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
r316647 corrected the build of tblgen and libllvm as dependencies for
LLD so undo the temporary seat-belt.
We still want to extend the build infrastructure to automatically detect
the case where the host LLD can be used instead of building a bootstrap
LLD, and likely extend libllvmminimal to meet LLD's needs for cases
where the build includes LLD but not Clang.
Sponsored by: The FreeBSD Foundation
cannot access the GLOBAL2 register directly.
Despite the comment in code (which was misleading), the indirect access is
only used to read the switch CONFIG data from the scrap register and not
for the GLOBAL2 access.
Use the dsa data to define when the switch is in the Multi Chip Addressing
Mode (a even address different than zero).
While here fix a typo.
Sponsored by: Rubicon Communications, LLC (Netgate)
Long ago, sh used to have its own optimized and restricted string formatting
implementation, which the printf builtin had to bypass via asprintf() to a
temporary buffer. Since sh has used libc's string formatting implementation
for a long time, remove the workaround.
Add a check to keep printf %c '' working the same way (output nothing);
POSIX allows both outputting nothing and outputting a NUL byte.
Also, this change avoids silently discarding format directives for whose
output asprintf() cannot allocate memory.
This patch allows the MTU stored in the hostcache to be used as an
initial value for SCTP paths. When an ICMP PTB message is received,
store the MTU in the hostcache.
MFC after: 1 week
1. Wrap at <80 columns for readability when editing. Rewrap some lines
prematurely wrapped to better fit in <80 columns and not waste
vertical space.
2. Fix SEE ALSO sorting (sort by section first, then manpage name).
3. Tweak the compound device description slightly by adding soft stops
via commas.
MFC after: 1 week
Reported by: igor [3], manlint [2]
Sponsored by Dell EMC Isilon
determining the softc of the bridge in psycho_route_interrupt(). [1]
While at it, update the corresponding comment that the code in
question is also necessary for U30s in addition to E450s (a fact
that has been known for ages).
PR: 218478
Submitted by: Yoshihiko Iwama
The code specified the length of a layout as INT64_MAX instead of
UINT64_MAX. This could result in getting a layout for less than the
full file for extremely large files. Although having little practical
effect, this patch corrects this in the code.
Detected during recent testing of the pNFS server.
MFC after: 2 weeks
The H_SET operation of the history() function takes an int argument which is
the position of the item to which the cursor should be moved to.
Submitted by: Abhinav Upadhyay <abhinav@NetBSD.org>
In exceptional circumstances, an MCA exception will trigger when the
freelist is exhausted. In such a case, no error will be logged on the list
and 'mca_count' will not be incremented.
Prior to this patch, all CPUs that received the exception would spin
forever.
With this change, the CPU that detects the error but finds the freelist
empty will proceed to panic the machine, ending the deadlock.
A follow-up to r260457.
Reported by: Ryan Libby <rlibby at gmail.com>
Reviewed by: jhb@
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D10536
These command take an int. The tests work by accident on little-endian,
64-bit systems.
PR: 218919
Tested with: qemu-cheri and CheriBSD built for mips64
Reviewed by: asomers, ngie
Obtained from: CheriBSD
MFC after: 1 week
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D10518
