| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
Only fetch the VFP state from the CPU if the thread whose registers are
being requested is the current thread. If a stopped thread's registers
are being fetched by a debugger, the saved state in the PCB is already
valid.
|
| |
|
|
| |
Improve i386 #UD low-level kdtrace hook.
|
| |
|
|
|
|
|
| |
We don't need a panic as a reminder that these need to be implemented.
Reported by: Shawn Webb
Sponsored by: The FreeBSD Foundation
|
| |
|
|
|
|
|
|
|
|
| |
Re-remove excess / for installing SYMLINKS
This excess / was introduced in r280129, and fixed in r295230, but got
re-introduced while merging another branch in r298107.
Approved by: gjb
Differential Revision: https://reviews.freebsd.org/D11995
|
| |
|
|
| |
Print whole machine state on double fault.
|
| |
|
|
| |
Add {rd,wr}{fs,gs}base C wrappers for instructions.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add inpcb pointer to struct ipsec_ctx_data and pass it to the pfil hook
from enc_hhook().
This should solve the problem when pf is used with if_enc(4) interface,
and outbound packet with existing PCB checked by pf, and this leads to
deadlock due to pf does its own PCB lookup and tries to take rlock when
wlock is already held.
Now we pass PCB pointer if it is known to the pfil hook, this helps to
avoid extra PCB lookup and thus rlock acquiring is not needed.
For inbound packets it is safe to pass NULL, because we do not held any
PCB locks yet.
PR: 220217
Sponsored by: Yandex LLC
|
| |
|
|
|
|
|
|
|
| |
ext2fs: be more verbose about unsupported ext2fs features.
It is useful to know exactly what features may be lacking when trying to
mount ext4 filesystems.
Submitted by: Fedor Uporov
|
| |
|
|
|
|
|
|
| |
Plug memory leak in arge_encap().
Reported by: Ilja Van Sprundel <ivansprundel ioactive.com>
Submitted by: Domagoj Stolfa <domagoj.stolfa gmail.com>
Reviewed by: adrian
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
r305626 (by oshogbo):
Move libcasper tests from regression/capsicum/libcasper/ to
lib/libcasper/service/${service_name}/tests.
r305629 (by jkim):
Add new directories added in r305626 to fix "make installworld".
r307863 (by emaste):
Set SHLIBDIR before .including src.opts.mk in libcapser services
bsd.own.mk (included from src.opts.mk) sets SHLIBDIR?=${LIBDIR}, so
SHLIBDIR must be set before including either one of them.
MFC with: 305626
r322447:
Fix result printing
- Flushing stdout prevents the buffer from being printed twice, fixing
issues with stdout printing out the testplan, etc, twice.
- Don't print out raw source/line numbers; hide them behind comments.
r322448:
Make root-privileges a requirement for the test
Some of the testcases try to manipulate sysctls that require root privileges,
e.g., "kern.sync_on_panic". Make root-privileges a hard requirement so the
tests don't raise false positives due to privilege issues when calling
sysctlbyname(3) on writable sysctls.
r322449:
Use hardcoded IPv4/IPv6 addresses for google-public-dns-a.google.com instead
of freefall.freebsd.org to unbreak the DNS tests
The address allocations for freefall.freebsd.org have changed in the past 4 years.
Use a more stable set of hardcoded addresses for now to make the tests succeed
reliably.
The hostname should be resolved dynamically instead of hardcoding the addresses in
the future. This is just a bandaid.
r322450:
Integrate the tests moved in r305626 in to the FreeBSD test suite
The reachover Kyuafiles were never added, and thus the tests were installed
as standalone tests, and not integrated into the full suite.
MFC with: r305626, 305629, r307863, r322447, r322448, r322449
r322451:
TESTSDIR isn't required; remove it
MFC with: r322450
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
ext2fs: Add uninit_bg feature support.
From the linux tune2fs(8) manpage:
"Allow the kernel to initialize bitmaps and inode tables and keep a high
watermark for the unused inodes in a filesystem, to reduce e2fsck(8) time.
This first e2fsck run after enabling this feature will take the full time,
but subsequent e2fsck runs will take only a fraction of the original time,
depending on how full the file system is."
Submitted by: Fedor Uporov
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
ext2fs: add read-write support for Extended Attributes and linux ACLs.
Extended attributes and their particular implementation in linux are
different from FreeBSD so in this case we have started diverging from
the UFS EA implementation, which would be the natural reference.
Support for linux ext2fs posix-draft ACLs.
Submitted by: Fedor Uporov
Reviewed by: pfg
Include fixes from: cem, pluknet
|
| |
|
|
| |
Improve standard compliance for memset_s() and abort_handler_s().
|
| |
|
|
|
|
| |
Annotate tests that require root privileges appropriately
This unbreaks running the tests with unprivileged users.
|
| |
|
|
|
|
| |
Require strings(1) with :o_flag_preparer and :o_flag_publisher
strings(1) might not be installed on the system, e.g., if MK_TOOLCHAIN == no
|
| |
|
|
|
|
|
| |
Sort the tests alphabetically before adding them to the Kyuafiles
This is being done to aid in debugging test runs, in the event the
output shifts due to refactored Makefiles, added tests, etc.
|
| |
|
|
|
|
|
| |
Delete comment above "__DEFAULT_DEPENDENT_OPTIONS" related to "meta mode options"
src.conf(5) should document which knobs are which and the dependency between each;
remove the comment so the variable can apply to non-"meta mode options".
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Expose the ILP32/LP64 programming environments based on
__ILP32__/__LP64__ instead of by architecture.
The list was incomplete (previous commits purged invalid architectures,
like __alpha__, but failed to add new ones). It's best to base the symbol
presence on whether or not the architecture is ILP32 / LP64 capable, per
the compiler.
This fixes the ILP32/LP64 program environments on some architectures like
arm64, and by proxy fixes the tests on those architectures.
|
| |
|
|
|
|
| |
Hide `sccsid` under #if 0, per example in style(9)
This fixes a -Wunused warning with gcc 6.3.0/7.0.0.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
r321949:
Add expected failures for ZFS
- :f_flag fails on ZFS because UF_IMMUTABLE isn't supported [1].
- :v_flag fails on ZFS because the mode for foo is [always] updated
unnecessarily.
get_filesystem(..) (supporting function that was added to the test script)
is based on equivalent logic in usr.bin/extattr/tests/extattr_test.sh .
PR: 221189 [1], 221188 [2]
r321950:
Always use first parameter passed to get_filesystem(..) instead of discarding it
and using `.` instead.
MFC with: r321949
PR: 221189 [1], 221188 [2]
r322101:
Don't check result of chflags in f_flag_cleanup()
This will prevent false positives from occurring if the test is run on
ZFS since ZFS doesn't support fflags throbbing like UFS.
PR: 221189
MFC with: r321949
|
| |
|
|
| |
Micro-optimize kmem_unback().
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
------------------------------------------------------------------------
r321502 | scottl | 2017-07-25 19:48:13 -0600 (Tue, 25 Jul 2017) | 2 lines
Quiet a message that sounds far more dire than it really is.
------------------------------------------------------------------------
r321714 | scottl | 2017-07-30 00:53:58 -0600 (Sun, 30 Jul 2017) | 13 lines
Split the interrupt setup code into two parts: allocation and configuration.
Do the allocation before requesting the IOCFacts message. This triggers
the LSI firmware to recognize the multiqueue should be enabled if available.
Multiqueue isn't used by the driver yet, but this also fixes a problem with
the cached IOCFacts not matching latter checks, leading to potential problems
with error recovery.
As a side-effect, fetch the driver tunables as early as possible.
Reviewed by: slm
Obtained from: Netflix
Differential Revision: D9243
------------------------------------------------------------------------
r321733 | scottl | 2017-07-30 16:34:24 -0600 (Sun, 30 Jul 2017) | 5 lines
Change from using underbar function names to normal function names for
the informational print functions. Collapse the debug API a bit to be
more generic and not require as much code duplication. While here, fix
a bug in MPS that was already fixed in MPR.
------------------------------------------------------------------------
r321737 | scottl | 2017-07-30 18:05:49 -0600 (Sun, 30 Jul 2017) | 3 lines
Don't re-parse PCI IDs in order to set card-specific flags, use
the flags field in the PCIID table.
------------------------------------------------------------------------
r321799 | scottl | 2017-07-31 10:55:56 -0600 (Mon, 31 Jul 2017) | 4 lines
Fix a logic bug in the split PCI interrupt code that slipped through
Reported by: Harry Schmalzbauer
------------------------------------------------------------------------
r322364 | ken | 2017-08-10 08:59:17 -0600 (Thu, 10 Aug 2017) | 39 lines
Changes to make mps(4) and mpr(4) handle reinit with reallocation.
When the mps(4) and mpr(4) drivers need to reinitialize the
firmware, they sometimes need to reallocate all of the memory
allocated by the driver. The reallocation happens whenever the IOC
Facts change. That should only happen after a firmware upgrade.
If the reinitialization happens as a result of a timed out command
sent to the card, the command that timed out and triggered the
reinit may have been freed if iocfacts_allocate() reallocated all
memory. If the caller attempts to access the command after that,
the kernel will panic because the caller will be dereferencing
freed memory.
The solution is to set a flag in the softc when we reallocate,
and avoid dereferencing the command strucure if we've reallocated.
The changes are largely the same in both drivers, since mpr(4) is a
derivative of mps(4).
o In iocfacts_allocate(), if the IOC Facts have changed and we
need to reallocate, set the REALLOCATED flag in the softc.
o Change wait_command() to take a struct mps_command ** instead of
a struct mps_command *. This allows us to NULL out the caller's
command pointer if we have to reinit the controller and the data
structures get reallocated. (The REALLOCATED flag will be set
in the softc if that has happened.)
o In every place that calls wait_command(), make sure we handle
the case where the command is NULL after the call.
o The mpr(4) driver has mpr_request_polled() which can also
reinitialize the card. Also check for reallocation there.
Reviewed by: scottl, slm
Sponsored by: Spectra Logic
------------------------------------------------------------------------
|
| |
|
|
| |
Typo, the '-6' option selects inet6.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
MFC r319132: bsdgrep: bump version number and add Kyle Evans copyright
The following changes have been made over the last couple of months:
Features:
- With bsdgrep -r, the working directory is implied if no directory is
specified
- bsdgrep will now behave as bsdgrep -r does when it's named rgrep
- bsdgrep now understands -z/--null-data to use \0 as EOL
- GNU regex compatibility is now indicated with a "GNU compatible" in
the version string
Fixes:
- --mmap no longer hangs when coming across an EOF without an
accompanying EOL
- -o/--color matching generally improved, now produces earliest /
longest matches
- Context output now more closely aligns with GNU grep
- Zero-length matches no longer exhibit broken behavior
- Every output line now honors -b/-H/-n flags
Tests have been added for previous regressions as well as other
previously untested behaviors.
Various other fixes have been commited, and refactoring for further /
later improvements has taken place.
(The original submission changed the version string to 2.5.2, but I
decided to use 2.6.0 to reflect the addition of new features.)
MFC r320754: Update copyright e-mail address to @FreeBSD.org address
Approved by: emaste (mentor, blanket MFC)
|
| |
|
|
| |
Approved by: emaste (mentor, blanket MFC)
|
| |
|
|
| |
Make vm_page_sunbusy() assert that the page is unlocked.
|
| |
|
|
|
|
|
| |
Correct a couple of minor BSD grep assumptions that are valid for line
processing but not future chunk-based processing.
Approved by: emaste (mentor, blanket MFC)
|
| |
|
|
|
|
|
| |
MFC r322618: bsdgrep: cast pmatch.rm_so to fix build when linking against
libgnuregex
Approved by: emaste (mentor)
|
| |
|
|
| |
Style.
|
| |
|
|
|
| |
Remove confusion in the line explaining syntax of the msr read.
Specify words order in the display.
|
| |
|
|
|
|
|
| |
hyperv: Update copyright for the files changed in 2017
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D11982
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
Approved by: emaste (mentor, blanket MFC)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
Approved by: emaste (mentor, blanket MFC)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
MFC r318565: bsdgrep: fix segfault with --mmap
r313948 partially fixed --mmap behavior but was incomplete. This commit
generally reverts it and does it the more correct way- by just consuming
the rest of the buffer and moving on.
MFC r318908: bsdgrep: add --mmap tests
Basic sanity tests as well as coverage for the bug fixed in r318565.
PR: 219402
Approved by: emaste (mentor, blanket MFC)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
MFC r318302: bsdgrep: don't allow negative -A / -B / -C
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.
MFC r318317: bsdgrep: add more tests for different binary flags
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.
Approved by: emaste (mentor, blanket MFC)
|
| |
|
|
|
|
| |
grep in base
Approved by: emaste (mentor, blanket MFC)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
322483
hyperv/hn: Update VF's ibytes properly under transparent VF mode.
While, I'm here add comment about why updating VF's imcast stat is
not necessary.
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D11948
322485
hyperv/hn: Fix/enhance receiving path when VF is activated.
- Update hn(4)'s stats properly for non-transparent mode VF.
- Allow BPF tapping to hn(4) for non-transparent mode VF.
- Don't setup mbuf hash, if 'options RSS' is set.
In Azure, when VF is activated, TCP SYN and SYN|ACK go through hn(4)
while the rest of segments and ACKs belonging to the same TCP 4-tuple
go through the VF. So don't setup mbuf hash, if a VF is activated
and 'options RSS' is not enabled. hn(4) and the VF may use neither
the same RSS hash key nor the same RSS hash function, so the hash
value for packets belonging to the same flow could be different!
- Disable LRO.
hn(4) will only receive broadcast packets, multicast packets, TCP
SYN and SYN|ACK (in Azure), LRO is useless for these packet types.
For non-transparent, we definitely _cannot_ enable LRO at all, since
the LRO flush will use hn(4) as the receiving interface; i.e.
hn_ifp->if_input(hn_ifp, m).
While I'm here, remove unapplied comment and minor style change.
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D11978
322486
hyperv/hn: Minor cleanup
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D11979
322487
hyperv/hn: Re-set datapath after synthetic parts reattached.
Do this even for non-transparent mode VF. Better safe than sorry.
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D11981
|
| |
|
|
|
|
| |
The assembly in sys/mips/include/profile.h will only work for o32 ABI.
Submitted by: Alexander Richardson
|
| |
|
|
| |
Approved by: emaste (mentor, blanket MFC)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
pf_get_sport(): Prevent possible endless loop when searching for an unused nat port
This is an import of Alexander Bluhm's OpenBSD commit r1.60,
the first chunk had to be modified because on OpenBSD the
'cut' declaration is located elsewhere.
Upstream report by Jingmin Zhou:
https://marc.info/?l=openbsd-pf&m=150020133510896&w=2
OpenBSD commit message:
Use a 32 bit variable to detect integer overflow when searching for
an unused nat port. Prevents a possible endless loop if high port
is 65535 or low port is 0.
report and analysis Jingmin Zhou; OK sashan@ visa@
Quoted from: https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/net/pf_lb.c
PR: 221201
Submitted by: Fabian Keil <fk@fabiankeil.de>
Obtained from: OpenBSD via ElectroBSD
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
MFC r317703: bsdgrep: fix -w flag matching with an empty pattern
-w flag matching with an empty pattern was generally 'broken', allowing
matches to occur on any line whether or not it actually matches -w
criteria.
This fix required a good amount of refactoring to address. procline()
is altered to *only* process the line and return whether it was a match
or not, necessary to be able to short-circuit the whole function in case
of this matchall flag. -m flag handling is moved out as well because it
suffers from the same fate as context handling if we bypass any actual
pattern matching.
The matching context (matches, mostly) didn't previously exist outside
of procline(), so we go ahead and create context object for file
processing bits to pass around. grep_printline() was created due to
this, for the scenarios where the matches don't actually matter and we
just want to print a line or two, a la flushing the context queue and
no -o or --color specified.
Damage from this broken behavior would have been mitigated by the fact
that it is unlikely users would invoke grep -w with an empty pattern.
This was identified while checking PR 105221 for problems it this may
cause in BSD grep, but PR 105221 is *not* a report of this behavior.
MFC r317741: bsdgrep: correct uninitialized variable introduced in r317703
MFC r317842: bsdgrep: don't ouptut matches with -c, -l, -L
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
Approved by: emaste (mentor, blanket MFC)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
MFC r317700: bsdgrep: use calloc where appropriate in grep's tre-fastmatch
Also apply style(9) to a related NULL check.
MFC r317701: bsdgrep: correct test sense from r317700
Kyle's change in review D10098 was correct. I introduced the error when
extracting a portion of that change.
MFC r317704: bsdgrep: fix escape map building for multibyte strings
In BSD grep, fix escape map building in the regex parser. It was
previously using memory not explicitly initialized, and the MBS escape
map was being built based on a version of the pattern with escapes
already parsed out.
This is Kyle's change, but I restored the broken style that already
exists in this file.
Approved by: emaste (mentor, blanket MFC)
|
| |
|
|
|
|
|
| |
As reported in r218614 it's useful to have an indication of whether or not
BSD grep was built with GNU_GREP_COMPAT.
Approved by: emaste (mentor, blanket MFC)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-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
Approved by: emaste (mentor, blanket MFC)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bugs have been found in the fastmatch implementation as used in bsdgrep.
Some have been fixed (r316495) while fixes for others are in review
(D10098).
In comparison with the fastmatch implementation, Kyle Evans found that:
- regex(3)'s performance with literal expressions offers a speed
improvement over fastmatch
- regex(3)'s performance, both with simple BREs and EREs, seems to be
comparable
The regex implementation was imported in r226035, and the commit message
reports:
This is a temporary solution until the whole regex library is
not replaced so that BSD grep development can continue and the
backported code gets some review and testing. This change only
improves scalability slightly, there is no big performance boost
yet but several minor bugs have been found and fixed.
Introduce a WITH_/WITHOUT_BSD_GREP_FASTMATCH knob to support testing
of both approaches.
Regenerate src.conf(5) as per the original commit
PR: 175314, 194823
Approved by: emaste (mentor, blanket MFC)
|
| |
|
|
|
|
|
|
| |
Pull a copy of the filename string before calling basename(). Change the
loop to not return on its own, so we can put a free() statement at the
bottom.
Approved by: emaste (mentor, blanket MFC)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Make user supplied data checks a bit stricter.
key_msg2sp() is used for parsing data from setsockopt(IP[V6]_IPSEC_POLICY)
call. This socket option is usually used to configure IPsec bypass for
socket. Only privileged user can set this socket option.
The message syntax is described here
http://www.kame.net/newsletter/20021210/
and our libipsec is usually used to create the correct request.
Add additional checks:
* that sadb_x_ipsecrequest_len is not out of bounds of user supplied buffer
* that src/dst's sa_len is the same
* that 2*sa_len is not out of bounds of user supplied buffer
* that 2*sa_len fits into bounds of sadb_x_ipsecrequest
Reported by: Ilja van Sprundel
|
| |
|
|
|
|
| |
Use "Ibex Peak" codename for "5 Series/3400 Series" chipsets.
This is shorter and unifies naming with later chipsets.
|
| |
|
|
| |
While there, polish some old AHCI ones, since they are still reused.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Lower the amd64 shared page, which contains the signal trampoline,
from the top of user memory to one page lower on machines with the
Ryzen (AMD Family 17h) CPU. This pushes ps_strings and the stack
down by one page as well. On Ryzen there is some sort of interaction
between code running at the top of user memory address space and
interrupts that can cause FreeBSD to either hang or silently reset.
This sounds similar to the problem found with DragonFly BSD that
was fixed with this commit:
https://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/b48dd28447fc8ef62fbc963accd301557fd9ac20
but our signal trampoline location was already lower than the address
that DragonFly moved their signal trampoline to. It also does not
appear to be related to SMT as described here:
https://www.phoronix.com/forums/forum/hardware/processors-memory/955368-some-ryzen-linux-users-are-facing-issues-with-heavy-compilation-loads?p=955498#post955498
"Hi, Matt Dillon here. Yes, I did find what I believe to be a
hardware issue with Ryzen related to concurrent operations. In a
nutshell, for any given hyperthread pair, if one hyperthread is
in a cpu-bound loop of any kind (can be in user mode), and the
other hyperthread is returning from an interrupt via IRETQ, the
hyperthread issuing the IRETQ can stall indefinitely until the
other hyperthread with the cpu-bound loop pauses (aka HLT until
next interrupt). After this situation occurs, the system appears
to destabilize. The situation does not occur if the cpu-bound
loop is on a different core than the core doing the IRETQ. The
%rip the IRETQ returns to (e.g. userland %rip address) matters a
*LOT*. The problem occurs more often with high %rip addresses
such as near the top of the user stack, which is where DragonFly's
signal trampoline traditionally resides. So a user program taking
a signal on one thread while another thread is cpu-bound can cause
this behavior. Changing the location of the signal trampoline
makes it more difficult to reproduce the problem. I have not
been because the able to completely mitigate it. When a cpu-thread
stalls in this manner it appears to stall INSIDE the microcode
for IRETQ. It doesn't make it to the return pc, and the cpu thread
cannot take any IPIs or other hardware interrupts while in this
state."
since the system instability has been observed on FreeBSD with SMT
disabled. Interrupts to appear to play a factor since running a
signal-intensive process on the first CPU core, which handles most
of the interrupts on my machine, is far more likely to trigger the
problem than running such a process on any other core.
Also lower sv_maxuser to prevent a malicious user from using mmap()
to load and execute code in the top page of user memory that was made
available when the shared page was moved down.
Make the same changes to the 64-bit Linux emulator.
PR: 219399
Reported by: nbe@renzel.net
Reviewed by: kib
Reviewed by: dchagin (previous version)
Tested by: nbe@renzel.net (earlier version)
Differential Revision: https://reviews.freebsd.org/D11780
|
