This may be refined upstream.
Reviewed by: dim
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D11034
The problem is that when the parameter 'pat' is null, the function locally
allocates a NULL string but never frees it.
Instead of tracking the local alloc, it is noted that the while(*pat) never
enters when there is a local alloc.
So instead of doing the local alloc, check that 'pat' is null before the
while(*pat) loop.
Found using clang's static analyzer - scan-build
Submitted by: Thomas Rix <trix@juniper.net>
Reviewed by: markm
Approved by: sjg (mentor)
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D9689
Basic sanity tests as well as coverage for the bug fixed in r318565.
Submitted by: Kyle Evans <kevans91@ksu.edu>
Reviewed by: bapt, ngie
Differential Revision: https://reviews.freebsd.org/D10827
[PPC] Properly update register save area offsets
The variables MinGPR/MinG8R were not updated properly when resetting the
offsets, which in the included testcase lead to saving the CR register
in the same location as R30.
This fixes another issue reported in PR26519.
Differential Revision: https://reviews.llvm.org/D33017
Reported by: Mark Millard
PR: 206990
MFC after: 3 days
In the absense of a more specific handler for TRAP_CAP (generated by
ENOTCAPABLE or ECAPMODE while in capability mode) treat it as a trace
trap.
Example usage (testing the bug in PR219173):
% proccontrol -m trapcap lldb usr.bin/hexdump/obj/hexdump -- -Cv -s 1 /bin/ls
...
(lldb) run
Process 12980 launching
Process 12980 launched: '.../usr.bin/hexdump/obj/hexdump' (x86_64)
Process 12980 stopped
* thread #1, stop reason = trace
frame #0: 0x0000004b80c65f1a libc.so.7`__sys_lseek + 10
...
In the future we should have LLDB control the trapcap procctl itself
(as it does with ASLR), as well as report a specific stop reason.
This change eliminates an assertion failure from LLDB for now.
The original blacklist library supported two notification types:
- failed auth attempt, which incremented the failed login count
by one for the remote address
- successful auth attempt, which reset the failed login count
to zero for that remote address
When the failed login count reached the limit in the configuration
file, the remote address would be blocked by a packet filter.
This patch implements a new notification type, "abusive behavior",
and accepts, but does not act on an additional type, "bad username".
It is envisioned that a system administrator will configure a small
list of "known bad usernames" that should be blocked immediately.
Reviewed by: emaste
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D10604
This is no-op and only for reference: the S/390 port seems to be elusive
in the BSDs so it is convenient to keep some trace from past efforts.
It is likely newer attempts will focus on a newer toolchain using clang
instead.
Obtained from: Perforce depot/projects/s390
Extend the ino_t, dev_t, nlink_t types to 64-bit ints. Modify
struct dirent layout to add d_off, increase the size of d_fileno
to 64-bits, increase the size of d_namlen to 16-bits, and change
the required alignment. Increase struct statfs f_mntfromname[] and
f_mntonname[] array length MNAMELEN to 1024.
ABI breakage is mitigated by providing compatibility using versioned
symbols, ingenious use of the existing padding in structures, and
by employing other tricks. Unfortunately, not everything can be
fixed, especially outside the base system. For instance, third-party
APIs which pass struct stat around are broken in backward and
forward incompatible ways.
Kinfo sysctl MIBs ABI is changed in backward-compatible way, but
there is no general mechanism to handle other sysctl MIBS which
return structures where the layout has changed. It was considered
that the breakage is either in the management interfaces, where we
usually allow ABI slip, or is not important.
Struct xvnode changed layout, no compat shims are provided.
For struct xtty, dev_t tty device member was reduced to uint32_t.
It was decided that keeping ABI compat in this case is more useful
than reporting 64-bit dev_t, for the sake of pstat.
Update note: strictly follow the instructions in UPDATING. Build
and install the new kernel with COMPAT_FREEBSD11 option enabled,
then reboot, and only then install new world.
Credits: The 64-bit inode project, also known as ino64, started life
many years ago as a project by Gleb Kurtsou (gleb). Kirk McKusick
(mckusick) then picked up and updated the patch, and acted as a
flag-waver. Feedback, suggestions, and discussions were carried
by Ed Maste (emaste), John Baldwin (jhb), Jilles Tjoelker (jilles),
and Rick Macklem (rmacklem). Kris Moore (kris) performed an initial
ports investigation followed by an exp-run by Antoine Brodin (antoine).
Essential and all-embracing testing was done by Peter Holm (pho).
The heavy lifting of coordinating all these efforts and bringing the
project to completion were done by Konstantin Belousov (kib).
Sponsored by: The FreeBSD Foundation (emaste, kib)
Differential revision: https://reviews.freebsd.org/D10439
[ARM] Clear the constant pool cache on explicit .ltorg directives
Multiple ldr pseudoinstructions with the same constant value will
reuse the same constant pool entry. However, if the constant pool is
explicitly flushed with a .ltorg directive, we should not try to
reference constants in the previous pool any longer, since they may
be out of range.
This fixes assembling hand-written assembler source which repeatedly
loads the same constant value, across a binary size larger than the
pc-relative fixup range for ldr instructions (4096 bytes). Such
assembler source already uses explicit .ltorg instructions to emit
constant pools with regular intervals. However if we try to reuse
constants emitted in earlier pools, they end up out of range.
This makes the output of the testcase match what binutils gas does
(prior to this patch, it would fail to assemble).
Differential Revision: https://reviews.llvm.org/D32847
This should fix "out of range pc-relative fixup value" errors, when
compiling certain ARM inline assembly for www/webkit-gtk[23].
Reported by: mmel
MFC after: 3 days
This is required for mips gcc 6.3 userland to build/run.
Reviewed by: emaste, dim
Approved by: emaste
Differential Revision: https://reviews.freebsd.org/D10838
dma.8:77:contraction:Queue the mail, but [don't] attempt to deliver it.
dma.8:85:repeated:s [are are] ignored.
dma.8:87:contraction:[Don't] run in the background.
dma.8:201:contraction:Use the catch-all alias only if you [don't] want any local mail to be
mandoc: dma.8:308:5: WARNING: macro neither callable nor escaped: Sm
MFC after: 3 days
Metadata printing with -b, -H, or -n flags suffered from a few flaws:
1) -b/offset printing was broken when used in conjunction with -o
2) With -o, bsdgrep did not print metadata for every match/line, just
the first match of a line
3) There were no tests for this
Address these issues by outputting this data per-match if the -o flag is
specified, and prior to outputting any matches if -o but not --color,
since --color alone will not generate a new line of output for every
iteration over the matches.
To correct -b output, fudge the line offset as we're printing matches.
While here, make sure we're using grep_printline in -A context. Context
printing should *never* look at the parsing context, just the line.
The tests included do not pass with gnugrep in base due to it exhibiting
similar quirky behavior that bsdgrep previously exhibited.
Submitted by: Kyle Evans <kevans91@ksu.edu>
Reviewed by: cem
Differential Revision: https://reviews.freebsd.org/D10580
We should not set an arbitrary cap on the number of matches on a line,
and in any case MAX_LINE_MATCHES of 32 is much too low. Instead, if we
match more than MAX_LINE_MATCHES, keep processing and matching from the
last match until all are found.
For the regression test, we produce 4096 matches (larger than we expect
we'll ever set MAX_LINE_MATCHES) and make sure we actually get 4096
lines of output with the -o flag.
We'll also make sure that every distinct line is getting its own line
number to detect line metadata not being printed as appropriate along
the way.
PR: 218811
Submitted by: Kyle Evans <kevans91@ksu.edu>
Reported by: jbeich
Reviewed by: cem
Differential Revision: https://reviews.freebsd.org/D10577
The previous logic was flawed in the sense that it assumed that /dev/md3
was always available. This was a caveat I noted in r306038, that I hadn't
gotten around to solving before now.
Cache the device for the mountpoint after executing mdmfs, then use the
cached value in basic_cleanup(..) when unmounting/disconnecting the md(4)
device.
Apply sed expressions to use reuse logic in the NetBSD code that could
also be applied to FreeBSD, just with different tools.
Differential Revision: D10766
MFC after: 1 week
Reviewed by: bdrewery
Sponsored by: Dell EMC Isilon
The kern.coredump sysctl can be set to 0 to disable coredumps. Skip the
'status_coredump' and 'wait6_coredumped' tests if this sysctl is set to 0
rather than reporting a failure.
Submitted by: brooks
Reviewed by: ngie
Obtained from: CheriBSD
Sponsored by: DARPA / AFRL
Differential Revision: https://reviews.freebsd.org/D10665
The existing 'binary' test in netbsd-tests/ does a basic check of the
default treatment for binary behavior, but not much more than that.
Given some opportunity for breakage recently that did not trigger any
failures, add some tests to cover the three different binary file
behaviors (a, -I, -U) and their --binary-files= equivalent values.
Submitted by: Kyle Evans <kevans91@ksu.edu>
Reviewed by: cem, ngie
Differential Revision: https://reviews.freebsd.org/D10620
This is being done to avoid dereferencing a NULL pointer via strlcat,
obscuring the underlying issue with the getcwd(3) call.
MFC after: 2 weeks
Sponsored by: Dell EMC Isilon
Previously, when given a negative -A/-B/-C argument bsdgrep would
overflow the respective context flag(s) and exhibited surprising
behavior.
Fix this by removing unsignedness of Aflag/Bflag and erroring out if
we're given a value < 0. Also adjust the type used to track 'tail'
context in procfile() so that it accurately reflects the Aflag value
rather than overflowing and losing trailing context.
This also fixes an inconsistency previously existing between -n and
-C "n" behavior. They are now both limited to LLONG_MAX, to be
consistent.
Add some test cases to make sure grep errors out properly for both
negative context values as well as non-numeric context values rather
than giving bogus matches.
Submitted by: Kyle Evans <kevans91@ksu.edu>
Reviewed by: cem
Differential Revision: https://reviews.freebsd.org/D10675
pools, implement outputting of IPv6 addresses in the ippool debug list
of hash type pools (ippool -l -d -t hash). Currently IPv6 in ippool tree
type pool handling is mostly implemented.
This continues theseries of commits to remediate ippool.
This will be MFCed with a yet to be committed series of fixes to ippool
after it has been fully remediated.
PR: 218433
- Apply the logic to the FreeBSD block
- Fix a typo with the getconf(1) call that I would have caught, were
it not for the fact that I got the blocks wrong.
- Consolidate the hardcoded buffer sizes to the NetBSD block.
This would have been discovered had I run the test on a system where
PATH_MAX != 1024 (I don't have that at my disposal right at this moment).
MFC after: 3 weeks
MFC with: r318210
Sponsored by: Dell EMC Isilon
In the event the value of PATH_MAX was changed, the assumption that
MAXPATHLEN is 1024 (and hence the buffer length required to trigger
SSP to fail for read(2)) would be invalidated. Query getconf(1) for
the actual value of MAXPATHLEN via _XOPEN_PATH_MAX instead, and
increment the value by 1 to ensure that the SSP support tests the
stack smashing support properly.
MFC after: 3 weeks
Sponsored by: Dell EMC Isilon
type pools (ippool -l -d -t tree). Currently IPv6 in ippool tree type
pool handling is partially implemented (meaning it doesn't work).
This is the first of a series of commits to remediate ippool.
This will be MFCed with a yet to be committed series of fixes to ippool
after it has been fully remediated.
PR: 218433
parse_qfloat_immediate() accidentaly parses register with size
qualifier as immediate constant (It takes '<n>.' substring as
valid floating point constant).
Due to this, slightly reorder cases in parse_neon_mov() and move parsing of
vmov with immediate constant to last place.
MFC after: 2 weeks
In real GNU libgcc, _Unwind_Backtrace is published with GCC_3.3 version
for all architectures but ARM. For ARM it's publishes with GCC_4.3.0
version.
This exception is not implement in your version of libggc, thus we
export _Unwind_Backtrace with bad version. To maintain backward
compatibility, publish _Unwind_Backtrace twice, once as compatible
symbol with GCC_3.3 version, and once as default symbol with
GCC_4.3.0 version.
While I'm in, fix typo in GCC_4.2.0 to GCC_4.3.0 inheritance declaration.
MFC after: 2 weeks
Ensure showbase does not overflow do_put buffers
Summary:
In https://bugs.freebsd.org/207918, Daniel McRobb describes how using
std::showbase with ostreams can cause truncation of unsigned long long
when output format is octal. In fact, this can even happen with
unsigned int and unsigned long.
To ensure this does not happen, add one additional character to the
do_put buffers if std::showbase is on. Also add a test case.
Reviewers: EricWF, mclow.lists
Reviewed By: EricWF
Subscribers: cfe-commits, emaste
Differential Revision: https://reviews.llvm.org/D32670
PR: 207918
MFC after: 3 days
Among new things it is now threaded by default, use zstd -T# to chose the
number of threads not that -T0 will automatically determine the number of
threads based on the number of CPU online.
Refactoring done in r317703 broke -c, -l, and -L flags implying
suppression of match printing. Fortunately this is just a matter of not
doing any printing of the resulting matches and context printing was not
broken in this refactoring.
Add some regression tests since this area may still see further
refactoring, include different context flags as well even though they
were not broken in this case.
PR: 219077
Submitted by: Kyle kevans91@ksu.edu
Reported by: markj
Reviewed by: cem, ngie
Differential Revision: https://reviews.freebsd.org/D10607
[PPC] When restoring R30 (PIC base pointer), mark it as <def>
This happened on the PPC32/SVR4 path and was discovered when building
FreeBSD on PPC32. It was a typo-class error in the frame lowering
code.
This fixes PR26519.
Reported by: Mark Millard
PR: 206990
MFC after: 3 days
