This logic is still imperfect, since it allows at most 15 bidirectional
streams out of 30 allowed by specification, but at least now those should
work better. On the other side I don't remember I ever saw controller
supporting the bidirectional streams, so this is likely a nop change.
MFC after: 1 month
- 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().
Reviewed by: kib (earlier version)
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D12470
magic number to the kernel in r7 rather than the (currently unused and
irrelevant) width of the metadata pointer, which I believe was intended
for a never-used approach to the 64-bit port. This enables the kernel,
in a future commit, to switch on the cookie to distinguish a real
metadata pointer from loader(8) from garbage left in r6 by some other
boot loader.
MFC after: 3 weeks
plain-vanilla ETH microcode. The QOS_VLAN firmware added support in microcode
for handling IEEE 802.1q tags, but the npe(4) driver did not actually
support the relevant signalling. As a result, it was impossible to use
VLANs with npe(4). Switching to the more basic microcode (same license)
removes the on-NIC promisisng and makes vlan(4) work on both NPE interfaces.
Ref: https://lists.freebsd.org/pipermail/freebsd-arm/2012-August/003826.html
This commit merges projects/bsd_rdma_4_9 to head.
List of kernel sources used:
============================
1) kernel sources were cloned from git://github.com/torvalds/linux.git
Top commit 69973b830859bc6529a7a0468ba0d80ee5117826 - tag: v4.9, linux-4.9
2) krping was cloned from https://github.com/larrystevenwise/krping
Top commit 292a2f1abf0348285e678a82264740d52e4dcfe4
List of userspace sources used:
===============================
1) rdma-core was cloned from https://github.com/linux-rdma/rdma-core.git
Top commit d65138ef93af30b3ea249f3a84aa6a24ba7f8a75
2) OpenSM was cloned from git://git.openfabrics.org/~halr/opensm.git
Top commit 85f841cf209f791c89a075048a907020e924528d
3) libibmad was cloned from git://git.openfabrics.org/~iraweiny/libibmad.git
Tag 1.3.13 with some additional patches from Mellanox.
4) infiniband-diags was cloned from git://git.openfabrics.org/~iraweiny/infiniband-diags.git
Tag 1.6.7 with some additional patches from Mellanox.
NOTES:
======
1) The mthca driver has been removed in kernel and in userspace.
2) All GPLv2 only sources have been removed and where applicable
rewritten from scratch under a BSD license.
3) List of fully supported drivers in userspace and kernel:
a) iw_cxgbe (Chelsio)
b) mlx4ib (Mellanox)
c) mlx5ib (Mellanox)
4) WITH_OFED=YES is still required by make in order to build
OFED userspace and kernel code.
5) Full support has been added for routable RoCE, RoCE v2.
Sponsored by: Mellanox Technologies
The recently imported cloudabi_vdso_armv6_on_64bit.S should be the vDSO
for 32-bit processes when being run on FreeBSD/arm64. This vDSO ensures
that all system call arguments are padded to 64 bits, so that they can
be used by the kernel to call into most of the native implementations
directly.
Binaries generated by Clang for ARMv6 may contain these instructions:
MCR p15, 0, <Rd>, c7, c10, 5
These instructions are deprecated as of ARMv7, which is why modern
processors have a way of toggling support for them. On FreeBSD/arm64 we
currently disable support for these instructions, meaning that if 32-bit
executables with these instructions are run, they would crash with
SIGILL. This is likely not what we want.
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D13145
Right now I'm using two Raspberry Pi's (2 and 3) to test CloudABI
support for armv6, armv7 and aarch64. It would be nice if I could
restrict this to just a single instance when testing smaller changes.
This is why I'd like to get COMPAT_CLOUDABI32 to work on arm64.
As COMPAT_CLOUDABI32 depends on COMPAT_FREEBSD32, at least for the ELF
loading, this change adds all of the bits necessary to at least build a
kernel with COMPAT_FREEBSD32. All of the machine dependent system calls
are still stubbed out, for the reason that implementations for these are
only useful if actual support for running FreeBSD binaries is added.
This is outside the scope of this work.
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D13144
Ensure that an opening bracket always has a matching closing one.
Ensure that there is always a new-line at the end of a report line.
Also, add a space before the printed event flag.
Reviewed by: anish
The defined bits are the lower bits, not the higher ones.
Also, the specification has been extended to define bits 0:18 and they
all could potentially be interesting to us, so extend the width of the
field accordingly.
Reviewed by: anish
Many 8-byte entries have zero at byte 4, so the second 4-byte part is
skipped as a 4-byte padding entry. But not all 8-byte entries have that
property and they get misinterpreted.
A real example:
48 00 00 00 ff 01 00 01
This an 8-byte ACPI_IVRS_TYPE_SPECIAL entry for IOAPIC with ID 255 (bogus).
It is reported as:
ivhd0: Unknown dev entry:0xff
Fortunately, it was completely harmless.
Also, bail out early if we encounter an entry of a variable length type.
We do not have proper handling for those yet.
Reviewed by: anish
SPA_MAXBLOCKSIZE is 16 MB and having such a large object on the stack is
not nice in general and it could cause some confusing failures in the
single-user mode where the default stack size of 8 MB is used.
I expect that the upstream would make the same change.
MFC after: 1 week
Upon successful completion, the execve() system call invokes
exec_setregs() to initialize the registers of the initial thread of the
newly executed process. What is weird is that when execve() returns, it
still goes through the normal system call return path, clobbering the
registers with the system call's return value (td->td_retval).
Though this doesn't seem to be problematic for x86 most of the times (as
the value of eax/rax doesn't matter upon startup), this can be pretty
frustrating for architectures where function argument and return
registers overlap (e.g., ARM). On these systems, exec_setregs() also
needs to initialize td_retval.
Even worse are architectures where cpu_set_syscall_retval() sets
registers to values not derived from td_retval. On these architectures,
there is no way cpu_set_syscall_retval() can set registers to the way it
wants them to be upon the start of execution.
To get rid of this madness, let sys_execve() return EJUSTRETURN. This
will cause cpu_set_syscall_retval() to leave registers intact. This
makes process execution easier to understand. It also eliminates the
difference between execution of the initial process and successive ones.
The initial call to sys_execve() is not performed through a system call
context.
Reviewed by: kib, jhibbits
Differential Revision: https://reviews.freebsd.org/D13180
either aborts or exits, but never returns. Tag it as a non-returning
function rather than supply a bogus return(0) at the end of main.
CID: 1382885
Sponsored by: Netflix
greater than 2^31-1, then the result will be huge. This is unlikely,
as we don't support that many sections, but out of an abundace of
caution cast to size_t so the multiplication won't overflow
mysteriously when size_t is larger than 32-bits. The resulting code
may be a smidge larger, but this isn't super-space critical code.
CID: 1194216, 1194217, 1194222, 1194223, 1265018, 1265019,1265020,
1265021
Sponsored by: Netflix
A ccu driver was added for the a83t in r326114. Add compat string to
aw_ccung and register the clocks for the a83t upon attach.
Reviewed by: manu
Approved by: emaste (mentor, implicit)
Differential Revision: https://reviews.freebsd.org/D13205
AHCI emulation is useful for testing scenarios closer to the real
hardware. For example, it allows to exercise the CAM subsystem.
There could be other uses as well.
MFC after: 2 weeks
This value may be set by userspace so we need to check it before using it.
If this is not done correctly on exception return the kernel may continue
in kernel mode with all registers set to a userspace controlled value. Fix
this by moving the check into set_mcontext, and also add the missing
sanitisation from the arm64 set_regs.
Discussed with: security-officer@
MFC after: 3 days
Sponsored by: DARPA, AFRL
From binutils commits 5a4b0ccc20ba30caef53b01bee2c0aaa5b855339 and
7e1e19887abd24aeb15066b141cdff5541e0ec8e, made available under GPLv2
by Nick Clifton.
PR: 198824
MFC after: 1 week
Security: CVE-2014-8501
Security: CVE-2014-8502
From binutils commit 0102ea8cec5fc509bba6c91df61b7ce23a799d32, made
available under GPLv2 by Nick Clifton.
PR: 198824
MFC after: 1 week
Security: CVE-2014-8503
