cem [Tue, 6 Oct 2015 18:07:00 +0000 (18:07 +0000)]
Fix core corruption caused by race in note_procstat_vmmap
This fix is spiritually similar to r287442 and was discovered thanks to
the KASSERT added in that revision.
NT_PROCSTAT_VMMAP output length, when packing kinfo structs, is tied to
the length of filenames corresponding to vnodes in the process' vm map
via vn_fullpath. As vnodes may move during coredump, this is racy.
We do not remove the race, only prevent it from causing coredump
corruption.
- Add a sysctl, kern.coredump_pack_vmmapinfo, to allow users to disable
kinfo packing for PROCSTAT_VMMAP notes. This avoids VMMAP corruption
and truncation, even if names change, at the cost of up to PATH_MAX
bytes per mapped object. The new sysctl is documented in core.5.
- Fix note_procstat_vmmap to self-limit in the second pass. This
addresses corruption, at the cost of sometimes producing a truncated
result.
- Fix PROCSTAT_VMMAP consumers libutil (and libprocstat, via copy-paste)
to grok the new zero padding.
dim [Tue, 6 Oct 2015 17:53:29 +0000 (17:53 +0000)]
Upgrade our copies of clang, llvm, lldb, compiler-rt and libc++ to 3.7.0
release.
Please note that from 3.5.0 onwards, clang, llvm and lldb require C++11
support to build; see UPDATING for more information.
Release notes for llvm and clang can be found here:
<http://llvm.org/releases/3.7.0/docs/ReleaseNotes.html>
<http://llvm.org/releases/3.7.0/tools/clang/docs/ReleaseNotes.html>
Thanks to Ed Maste, Andrew Turner and Antoine Brodin for their help.
ngie [Tue, 6 Oct 2015 16:58:47 +0000 (16:58 +0000)]
Integrate the tests from libxo into the FreeBSD test suite
The functional_test.sh harness for each test subdir was inspired
by the version in bin/sh/tests/functional_test.sh
Some gymnastics were required to deal with implicit rules for
.c / .o -> .out as the suffix transformation rules were
incorrectly trying to create the test outputs from some of the
source files
royger [Tue, 6 Oct 2015 11:29:44 +0000 (11:29 +0000)]
Update Xen headers from 4.2 to 4.6
Pull the latest headers for Xen which allow us to add support for ARM and
use new features in FreeBSD.
This is a verbatim copy of the xen/include/public so every headers which
don't exits anymore in the Xen repositories have been dropped.
Note the interface version hasn't been bumped, it will be done in a
follow-up. Although, it requires fix in the code to get it compiled:
- sys/xen/xen_intr.h: evtchn_port_t is already defined in the headers so
drop it.
- {amd64,i386}/include/intr_machdep.h: NR_EVENT_CHANNELS now depends on
xen/interface/event_channel.h, so include it.
- {amd64,i386}/{amd64,i386}/support.S: It's not neccessary to include
machine/intr_machdep.h. This is also fixing build compilation with the
new headers.
- dev/xen/blkfront/blkfront.c: The typedef for blkif_request_segmenthas
been dropped. So directly use struct blkif_request_segment
Finally, modify xen/interface/xen-compat.h to throw a preprocessing error if
__XEN_INTERFACE_VERSION__ is not set. This is allow us to catch any file
where xen/xen-os.h is not correctly included.
hrs [Tue, 6 Oct 2015 08:43:48 +0000 (08:43 +0000)]
Reallocate a maxlen-long buffer only when the current maxlen is
shorter than the required length. Note that it rarely happens
because maxlen is almost always 128 which covers struct sockaddr_storage.
alc [Tue, 6 Oct 2015 05:49:00 +0000 (05:49 +0000)]
Exploit r288122 to address a cosmetic issue. Pages belonging to either
the kernel or kmem object can't be paged out. Since they can't be paged
out, they are never enqueued in a paging queue. Nonetheless, passing
PQ_INACTIVE to vm_page_unwire() in kmem_unback() creates the appearance
that these pages are being enqueued in the inactive queue. As of r288122,
we can avoid giving this false impression by passing PQ_NONE.
imp [Tue, 6 Oct 2015 04:18:48 +0000 (04:18 +0000)]
Previous versions of bsd.own.mk included bsd.compiler.mk
only when _WITHOUT_SRCCONF wasn't defined. Restore this
behavior because bsd.ports.mk depends on this in subtle
ways. The compat include of bsd.compiler.mk should
be removed in 12 anyway.
imp [Mon, 5 Oct 2015 21:41:55 +0000 (21:41 +0000)]
Start using the fact that SUBDIR.yes is added to SUBDIR
and move from the pattern of:
.if ${MK_FOO} != "no"
SUBDIR+= bar
.endif
to
SUBDIR.${MK_FOO}+= bar
since we know that MK_FOO is always either yes or no and the latter
form is easier to follow and much shorter. Various exception to this
pattern dealt with on an ah-hoc basis.
jhb [Mon, 5 Oct 2015 21:36:53 +0000 (21:36 +0000)]
Include additional info in ptrace(2) KTR traces:
- The new PC value and signal passed to PT_CONTINUE, PT_DETACH, PT_SYSCALL,
and PT_TO_SC[EX].
- The system call code returned via PT_LWPINFO.
ian [Mon, 5 Oct 2015 17:45:13 +0000 (17:45 +0000)]
The latest version of lex requires the latest m4 to build, add a dependency
when running the build-tools stage.
The requirement is due to the -P flag used when running m4 from usr.bin/lex
Makefile to generate skel.c. With the old m4 that fails and the failure is
ignored, resulting in an empty(-ish) skel.c, which leads to later build
failures when the misconfigured new lex tool is run.
This enables building -current (and 10-stable after MFC) on a stable-8
system again.
grehan [Mon, 5 Oct 2015 14:57:45 +0000 (14:57 +0000)]
Clean up some harmless unimplemented-command warning messages.
- Don't advertize trusted-computing capability in the Identify page.
This prevents Windows from issuing a TRUSTED_RECEIVE_DMA command.
- Windows will send down SMART and SECURITY_FREEZE_LOCK
even though smart and security capabilities were not advertized.
Send back a silent abort.
markm [Mon, 5 Oct 2015 07:41:12 +0000 (07:41 +0000)]
It appears that under some circumstances, like virtualisiation, the
'rdrand' instruction may occasionally not return random numbers, in
spite of looping attempts to do so. The reusult is a KASSERT/panic.
Reluctantly accept this state-of-affairs, but make a noise about it.
if this 'noise' spams the console, it may be time to discontinue
using that source.
This is written in a general way to account for /any/ source that
might not supply random numbers when required.
Submitted by: jkh (report and slightly different fix)
Approved by: so (/dev/random blanket)
ngie [Mon, 5 Oct 2015 00:33:57 +0000 (00:33 +0000)]
Merge additional testcases and improvements to bin/ls/ls_tests from
^/user/ngie/more-tests.
- Additional testcases added:
-- ls -D
-- ls -F
-- ls -H
-- ls -L
-- ls -R
-- ls -S
-- ls -T
-- ls -b
-- ls -d
-- ls -f
-- ls -g
-- ls -h
-- ls -i
-- ls -k
-- ls -l
-- ls -m
-- ls -n
-- ls -o
-- ls -p
-- ls -q/ls -w
-- ls -r
-- ls -s
-- ls -t
-- ls -u
-- ls -y
- Socket file creation is limited to the ls -F testcase, greatly speeding up
the test process
- The ls -C testcase was made more robust by limiting the number of columns
via COLUMNS and by dynamically formulating the columns/lines.
- Add `atf_test_case` before all testcase `head` functions.
pfg [Sun, 4 Oct 2015 18:54:02 +0000 (18:54 +0000)]
Bump the stack protector to level "strong".
The general stack protector is known to be weak and has pretty small
coverage. While setting stack-protector-all would give better protection
it would come with a performance cost: for this reason Google's Chrome OS
team developed a new stack-protector-strong variant.
In addition to the protections offered by -fstack-protector, the new option
will guard any function that declares any type or length of local array,
even those in structs or unions. It will also protect functions that use a
local variable's address in a function argument or on the right-hand side
of an assignment.
The option was introduced in GCC-4.9, but support for it has been
back-ported to our base GCC (r286074) and is also available in clang.
The change was tested with dbench and doesn't introduce performance
regressions. An exp-run over the ports tree revealed no failures when
using the stricter stack-protector-all. Thanks to all testers involved.
projects / FreeBSD / FreeBSD.git / log