oshogbo [Wed, 7 Nov 2018 20:31:36 +0000 (20:31 +0000)]
MFC r335844:
core(5): overwrite the oldest core dump
The '%I' format in the kern.corefile sysctl limits the number of
core files that a process can generate to the number stored in the
debug.ncores sysctl. The '%I' format is replaced by the single digit
index. Previously, if all indexes were taken the kernel would overwrite
only a core file with the highest index in a filename.
Currently the system will create a new core file if there is a free
index or if all slots are taken it will overwrite the oldest one.
emaste [Wed, 7 Nov 2018 18:12:18 +0000 (18:12 +0000)]
MFC r340137: rtld: move relro enforcement after ifunc processing
Previously the combination of relro (implicit), -z now and ifunc use
resulted in a segfault when applying ifuncs after relro (test binary
here just calls amd64_get_fsbase()):
As a follow-up to r339930 and various reports implement logging in case
we fail during module load because the pcpu or vnet module sections are
full. We did return a proper error but not leaving any indication to
the user as to what the actual problem was.
In r78161 the lookup_set linker method was introduced which optionally
returns the section start and stop locations as well as a count if the
caller asks for them.
There was only one out-of-file consumer of count which did not actually
use it and hence was eliminated in r339407.
In r194784 parse_dpcpu(), and in r195699 parse_vnet() (a copy of the
former) started to use the link_elf_lookup_set() interface internally
also asking for the count.
count is computed as the difference of the void **stop - void **start
locations and as such, if the absoulte numbers
(stop - start) % sizeof(void *) != 0
a round-down happens, e.g., **stop 0x1003 - **start 0x1000 => count 0.
To get the section size instead of "count is the number of pointer
elements in the section", the parse_*() functions do a
count *= sizeof(void *).
They use the result to allocate memory and copy the section data
into the "master" and per-instance memory regions with a size of
count.
As a result of count possibly round-down this can miss the last
bytes of the section. The good news is that we do not touch
out of bounds memory during these operations (we may at a later stage
if the last bytes would overflow the master sections).
Given relocation in elf_relocaddr() works based on the absolute
numbers of start and stop, this means that we can possibly try to
access relocated data which was never copied and hence we get
random garbage or at best zeroed memory.
Stop the two (last) consumers of count (the parse_*() functions)
from using count as well, and calculate the section size based on
the absolute numbers of stop and start and use the proper size for
the memory allocation and data copies. This will make the symbols
in the last bytes of the pcpu or vnet sections be presented as
expected.
The countp argument passed to linker_file_lookup_set() in
linker_load_dependencies() is unused, so no need to ask for the
value in first place. Remove the unused "count" variable.
With more excessive use of modules, more kernel parts working with
VIMAGE, and feature richness and global state increasing the 8k of
vnet module space are no longer sufficient for people and loading
multiple modules, e.g., pf(4) and ipl(4) or ipsec(4) will fail on
the second module.
Increase the module space to 8 * PAGE_SIZE which should be enough
to hold multiple firewalls, ipsec, multicast (as in the old days was
a problem), epair, carp, and any kind of other vnet enabled modules.
Sadly this is a global byte array part of the vnet_set, so we cannot
dynamically change its size; otherwise a TUNABLE would have been
a better solution.
jhb [Thu, 1 Nov 2018 20:42:54 +0000 (20:42 +0000)]
MFC 338813: Clear all of the VFP state in fill_fpregs().
Zero the entire FP register set structure returned for ptrace() if a
thread hasn't used FP registers rather than leaking garbage in the
fp_sr and fp_cr fields.
jhb [Thu, 1 Nov 2018 18:34:26 +0000 (18:34 +0000)]
MFC 338360,338415,338624,338630,338631,338725: Dynamic x86 IRQ layout.
338360:
Dynamically allocate IRQ ranges on x86.
Previously, x86 used static ranges of IRQ values for different types
of I/O interrupts. Interrupt pins on I/O APICs and 8259A PICs used
IRQ values from 0 to 254. MSI interrupts used a compile-time-defined
range starting at 256, and Xen event channels used a
compile-time-defined range after MSI. Some recent systems have more
than 255 I/O APIC interrupt pins which resulted in those IRQ values
overflowing into the MSI range triggering an assertion failure.
Replace statically assigned ranges with dynamic ranges. Do a single
pass computing the sizes of the IRQ ranges (PICs, MSI, Xen) to
determine the total number of IRQs required. Allocate the interrupt
source and interrupt count arrays dynamically once this pass has
completed. To minimize runtime complexity these arrays are only sized
once during bootup. The PIC range is determined by the PICs present
in the system. The MSI and Xen ranges continue to use a fixed size,
though this does make it possible to turn the MSI range size into a
tunable in the future.
As a result, various places are updated to use dynamic limits instead
of constants. In addition, the vmstat(8) utility has been taught to
understand that some kernels may treat 'intrcnt' and 'intrnames' as
pointers rather than arrays when extracting interrupt stats from a
crashdump. This is determined by the presence (vs absence) of a
global 'nintrcnt' symbol.
This change reverts r189404 which worked around a buggy BIOS which
enumerated an I/O APIC twice (using the same memory mapped address for
both entries but using an IRQ base of 256 for one entry and a valid
IRQ base for the second entry). Making the "base" of MSI IRQ values
dynamic avoids the panic that r189404 worked around, and there may now
be valid I/O APICs with an IRQ base above 256 which this workaround
would incorrectly skip.
If in the future the issue reported in PR 130483 reoccurs, we will
have to add a pass over the I/O APIC entries in the MADT to detect
duplicates using the memory mapped address and use some strategy to
choose the "correct" one.
While here, reserve room in intrcnts for the Hyper-V counters.
338415:
Fix build of x86 UP kernels after dynamic IRQ changes in r338360.
338624:
msi: remove the check that interrupt sources have been added
When running as a specific type of Xen guest the hypervisor won't
provide any emulated IO-APICs or legacy PICs at all, thus hitting the
following assert in the MSI code:
panic: Assertion num_io_irqs > 0 failed at /usr/src/sys/x86/x86/msi.c:334
cpuid = 0
time = 1
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xffffffff826ffa70
vpanic() at vpanic+0x1a3/frame 0xffffffff826ffad0
panic() at panic+0x43/frame 0xffffffff826ffb30
msi_init() at msi_init+0xed/frame 0xffffffff826ffb40
apic_setup_io() at apic_setup_io+0x72/frame 0xffffffff826ffb50
mi_startup() at mi_startup+0x118/frame 0xffffffff826ffb70
start_kernel() at start_kernel+0x10
Fix this by removing the assert in the MSI code, since it's possible
to get to the MSI initialization without having registered any other
interrupt sources.
338630:
lapic: skip setting intrcnt if lapic is not present
Instead of panicking. Legacy PVH mode doesn't provide a lapic, and
since native_lapic_intrcnt is called unconditionally this would cause
the assert to trigger. Change the assert into a continue in order to
take into account the possibility of systems without a lapic.
338631:
xen: legacy PVH fixes for the new interrupt count
Register interrupts using the PIC pic_register_sources method instead
of doing it in apic_setup_io. This is now required, since the internal
interrupt structures are not yet setup when calling apic_setup_io.
338725:
Fix a regression in r338360 when booting an x86 machine without APIC.
The atpic_register_sources callback tries to avoid registering interrupt
sources that would collide with an I/O APIC. However, the previous
implementation was failing to register IRQs 8-15 since the slave PIC
saw valid IRQs from the master and assumed an I/O APIC was present. To
fix, go back to registering all 8259A interrupt sources in one loop when
the master's register_sources method is invoked.
bz [Wed, 31 Oct 2018 11:37:05 +0000 (11:37 +0000)]
MFC r339586:
In bhyve's fbuf emulation improve the overall "usage" message and
for the vga option, rather than printing the entire option string,
only print vga (as we do for everything else).
MFC r339681:
Allow the bhyve VNC server to listen on IPv6 for incoming connections.
Alternatively to IPv4 address:port this will allow to listen on IPv6
link-local (incl. scope), a specific address, or ::. Addresses have
to be given in RFC2732 format so that [::]:port parsing will work.
This patch also starts to introduce WITH_INET/INET6_SUPPORT to bhyve.
PR: 232018
Submitted by: Dave Rush (northwoodlogic.free gmail.com) (original)
Reviewed by: Dave Rush (updated verison)
jhb [Tue, 30 Oct 2018 21:31:32 +0000 (21:31 +0000)]
MFC 338408: Don't directly dereference a user pointer in the VPD ioctl.
The PCIOCLISTVPD ioctl on /dev/pci is used to fetch a list of VPD
key-value pairs for a specific PCI function. It is used by
'pciconf -l -V'. The list is stored in a userland-supplied buffer as
an array of variable-length structures where the key and data length
are stored in a fixed-size header followed by the variable-length
value as a byte array. To facilitate walking this array in userland,
<sys/pciio.h> provides a PVE_NEXT() helper macro to return a pointer
to the next array element by reading the the length out of the current
header and using it to compute the address of the next header.
To simplify the implementation, the ioctl handler was also using
PVE_NEXT() when on the user address of the user buffer to compute the
user address of the next array element. However, the PVE_NEXT() macro
when used with a user address was reading the value's length by
indirecting the user pointer. The value was ready after the current
record had been copied out to the user buffer, so it appeared to work
on architectures where user addresses are directly dereferencable from
the kernel (all but powerpc and i386 after the 4:4 split). The recent
enablement of SMAP on amd64 caught this violation however. To fix,
add a variant of PVE_NEXT() for use in the ioctl handler that takes an
explicit value length.
jhb [Tue, 30 Oct 2018 19:10:41 +0000 (19:10 +0000)]
MFC 338148: Remove 'imen' global variable from atpic(4).
In pre-SMPng, the global 'imen' was used to track mask state of the
hardware interrupts and was aligned to the masks used by spl*().
When the atpic code was converted to using the x86 interrupt source
abstraction, the global 'imen' was preserved by having each PIC
instance point to an individual byte in the global 'imen' to hold its
8-bit interrupt mask. The global 'imen' is no longer used for
anything however, so rather than storing pointers in 'struct atpic',
just store the individual 8-bit mask for each PIC as a char.
While here, convert the ATPIC macro to using C99 initializers.
hselasky [Mon, 29 Oct 2018 12:10:06 +0000 (12:10 +0000)]
MFC r339587:
Added support for formula-based arbitrary baud rates, in contrast to
the current fixed values, which enables use of rates above 1 Mbps.
Improved the detection of HXD chips, and the status flag handling as
well.
tijl [Thu, 25 Oct 2018 16:01:19 +0000 (16:01 +0000)]
MFC r339618:
Define linuxkpi readq for 64-bit architectures. It is used by drm-kmod.
Currently the compiler picks up the definition in machine/cpufunc.h.
Add compiler memory barriers to read* and write*. The Linux x86
implementation of these functions uses inline asm with "memory" clobber.
The Linux x86 implementation of read_relaxed* and write_relaxed* uses the
same inline asm without "memory" clobber.
Implement ioread* and iowrite* in terms of read* and write* so they also
have memory barriers.
Qualify the addr parameter in write* as volatile.
Like Linux, define macros with the same name as the inline functions.
Only define 64-bit versions on 64-bit architectures because generally
32-bit architectures can't do atomic 64-bit loads and stores.
Regroup the functions a bit and add brief comments explaining what they do:
- __raw_read*, __raw_write*: atomic, no barriers, no byte swapping
- read_relaxed*, write_relaxed*: atomic, no barriers, little-endian
- read*, write*: atomic, with barriers, little-endian
Add a comment that says our implementation of ioread* and iowrite*
only handles MMIO and does not support port IO.
emaste [Thu, 25 Oct 2018 13:46:28 +0000 (13:46 +0000)]
elfcopy: avoid stripping relocations from static binaries
MFC r339350: elfcopy: delete filter_reloc, it is broken and unnecessary
elfcopy contained logic to filter individual relocations in STRIP_ALL
mode. However, this is not valid; relocations emitted by the linker are
required, unless they apply to an entire section being removed (which is
handled by other logic in elfcopy).
Note that filter_reloc was also buggy: for RELA relocation sections it
operated on uninitialized rel.r_info resulting in invalid operation.
The logic most likely needs to be inverted: instead of removing
relocations because their associated symbols are being removed, we must
keep symbols referenced by relocations. That said, in practice we do
not encounter this code path today: objects being stripped are either
dynamically linked binaries which retain .dynsym, or static binaries
with no relocations.
Just remove filter_reloc. This fixes certain cases including statically
linked binaries containing ifuncs. Stripping binaries with relocations
referencing removed symbols was already broken, and after this change
may still be broken in a different way.
MFC r339451: objcopy: restore behaviour required by GCC's build
In r339350 filter_reloc() was removed, to fix the case of stripping
statically linked binaries with relocations (which may come from ifunc
use, for example). As a side effect this changed the behaviour when
stripping object files - the output was broken both before and after
r339350, in different ways. Unfortunately GCC's build process relies
on the previous behaviour, so:
- Revert r339350, restoring filter_reloc().
- Fix an unitialized variable use (commited as r3638 in ELF Tool Chain).
- Change filter_reloc() to omit relocations referencing removed
symbols, while retaining relocations with no symbol reference.
- Retain the entire relocation section if it references the dynamic
symbol table (fix from kaiw in D17596).
kp [Wed, 24 Oct 2018 18:19:32 +0000 (18:19 +0000)]
MFC r339547:
vlan: Fix panic with lagg and vlan
vlan_lladdr_fn() is called from taskqueue, which means there's no vnet context
set. We can end up trying to send ARP messages (through the iflladdr_event
event), which requires a vnet context.
kp [Tue, 23 Oct 2018 07:24:03 +0000 (07:24 +0000)]
MFC r338698:
Significantly improve pf purge cpu usage by only taking locks
when there is work to do. This reduces CPU consumption to one
third on systems. This will help keep the thread CPU usage under
control now that the default hash size has increased.
jamie [Sat, 20 Oct 2018 16:20:36 +0000 (16:20 +0000)]
MFC r339409, r339420:
Add a new jail permission, allow.read_msgbuf. When true, jailed processes
can see the dmesg buffer (this is the current behavior). When false (the
new default), dmesg will be unavailable to jailed users, whether root or
not.
The security.bsd.unprivileged_read_msgbuf sysctl still works as before,
controlling system-wide whether non-root users can see the buffer.
hselasky [Fri, 19 Oct 2018 08:38:34 +0000 (08:38 +0000)]
MFC r339388:
Fix for reception of large full speed isochronous frames via the transaction
translator, when using the DWC OTG USB controller driver. Make sure to re-try
getting the complete split packets until a DATA0 packet is received. Larger
isochronous frames may be split into multiple MDATA packets terminated
by a single DATA0 packet.
mav [Fri, 19 Oct 2018 04:37:27 +0000 (04:37 +0000)]
MFC r339372: Skip VDEV_IO_DONE stage only for ZIO_TYPE_FREE.
Device removal code uses zio_vdev_child_io() with ZIO_TYPE_NULL parent,
that never happened before. It confused FreeBSD-specific TRIM code,
which does not use VDEV_IO_DONE for logical ZIO_TYPE_FREE ZIOs. As
result of that stage being skipped device removal ZIOs leaked references
and memory that supposed to be freed by VDEV_IO_DONE, making it stuck.
It is a quick patch rather then a nice fix, but hopefully we'll be able
to drop it all together when alternative TRIM implementation finally get
landed.
mav [Fri, 19 Oct 2018 04:30:25 +0000 (04:30 +0000)]
MFC r339329: Add ZIO_TYPE_FREE support for indirect vdevs.
Upstream code expects only ZIO_TYPE_READ and some ZIO_TYPE_WRITE
requests to removed (indirect) vdevs, while on FreeBSD there is also
ZIO_TYPE_FREE (TRIM). ZIO_TYPE_FREE requests do not have the data
buffers, so don't need the pointer adjustment.
mav [Fri, 19 Oct 2018 04:28:30 +0000 (04:28 +0000)]
MFC r339335: Avoid zero-sized kmem_alloc() in vdev_compact_children().
The device evacuation code adds a dependency that
vdev_compact_children() be able to properly empty the vdev_child
array by setting it to NULL and zeroing vdev_children. Under Linux,
kmem_alloc() and related functions return a sentinel pointer rather
than NULL for zero-sized allocations.
This is a part of ZoL port of device removal patch:
This fixes a regression in lld that made it stop emitting STT_FILE
symbols, which ctfmerge relies upon to uniquify function table entries
that reference STB_LOCAL symbols. Consequently, ctfmerge stopped
emitting entries for static functions into the function table, and
dtrace no longer gets type info for them.
gjb [Thu, 18 Oct 2018 17:33:30 +0000 (17:33 +0000)]
Document the krpc module requirement in 11.x that was not present
in 10.x if the system has a custom kernel configuration that excludes
NFS and, for example, uses MODULES_OVERRIDE="zfs opensolaris".
Reported by: eugen (via -stable)
Sponsored by: The FreeBSD Foundation
kp [Thu, 18 Oct 2018 04:36:25 +0000 (04:36 +0000)]
MFC r334375, r334379:
pf: Replace rwlock on PF_RULES_LOCK with rmlock
Given that PF_RULES_LOCK is a mostly read lock, replace the rwlock with rmlock.
This change improves packet processing rate in high pps environments.
Benchmarking by olivier@ shows a 65% improvement in pps.
While here, also eliminate all appearances of "sys/rwlock.h" includes since it
is not used anymore.
jamie [Wed, 17 Oct 2018 16:17:57 +0000 (16:17 +0000)]
MFC r339211:
Fix the test prohibiting jails from sharing IP addresses.
It's not supposed to be legal for two jails to contain the same IP address,
unless both jails contain only that one address. This is the behavior
documented in jail(8), and is there to prevent confusion when multiple
jails are listening on IADDR_ANY.
VIMAGE jails (now the default for GENERIC kernels) test this correctly,
but non-VIMAGE jails have been performing an incomplete test when nested
jails are used.
imp [Wed, 17 Oct 2018 04:10:23 +0000 (04:10 +0000)]
Direct commit since these files have gone away in head
Move pc98's biosdisk.c to the new style disk access. This is missing
support in common/part.c, however, for pc98 partitions, so it's
unlikely to actually work. Lack of a pc98 machine that's in sevice
limits my ability to test, but this allows pc98 to compile again.
np [Wed, 17 Oct 2018 02:05:31 +0000 (02:05 +0000)]
MFC r335352:
cxgbe(4): Some mailbox commands require access to the Tx pipeline and
can time out if it's backed up due to a non-stop deluge of PAUSE frames
from a misbehaving peer. Detect this situation and toggle MPS TxEn
to allow forward progress.
np [Wed, 17 Oct 2018 01:59:45 +0000 (01:59 +0000)]
MFC r334987:
cxgbe(4): Remove homemade version of htobe32 from the driver.
It was needed only for ia64 where it was implemented as a call to
bswapXX, which was always a real function. htobeXX with a constant
argument is calculated at compile-time everywhere else.
np [Wed, 17 Oct 2018 01:20:18 +0000 (01:20 +0000)]
MFC r338924:
cxgbe(4): Link related changes.
- Switch to using 32b port/link capabilities in the driver. The 32b
format is used internally by firmwares > 1.16.45.0 and the driver will
now interact with the firmware in its native format, whether it's 16b
or 32b. Note that the 16b format doesn't have room for 50G, 200G, or
400G speeds.
- Add a bit in the pause_settings knobs to allow negotiated PAUSE
settings to override manual settings.
- Ensure that manual link settings persist across an administrative
down/up as well as transceiver unplug/replug.
np [Wed, 17 Oct 2018 00:57:28 +0000 (00:57 +0000)]
MFC r333139:
cxgbe(4): Destroy the cdev before disabling interrupts in driver detach.
Filter work requests are submitted in the nexus cdev's ioctl which then
blocks waiting for a reply. If driver detach runs in this state and
disables interrupts the ioctl will never complete and detach will hang
in destroy_cdev.
np [Wed, 17 Oct 2018 00:45:01 +0000 (00:45 +0000)]
MFC r325840, r327811, and r329701.
r325840:
CXGBE: fix big-endian behaviour
The setbit/clearbit pair casts the bitfield pointer
to uint8_t* which effectively treats its contents as
little-endian variable. The ffs() function accepts int as
the parameter, which is big-endian. Use uint8_t here to
avoid mismatch, as we have only 4 doorbells.
ken [Fri, 12 Oct 2018 19:44:19 +0000 (19:44 +0000)]
MFC r339076
This has been edited slightly from the version in head. In head, the probe
sections of dadone() were split out into separate functions. In stable/11,
dadone() is still a single function.
So, for stable/11, this describes the change:
sys/cam/scsi/scsi_da.c:
In the DA_CCB_PROBE_DONE case in dadone(), free the data pointer
before returning.
------------------------------------------------------------------------
r339076 | ken | 2018-10-01 13:00:46 -0600 (Mon, 01 Oct 2018) | 12 lines
Fix a da(4) driver memory leak for SCSI SMR devices.
In the probe case for SCSI SMR Host Aware or Most Managed drives, be sure
to free allocated memory.
sys/cam/scsi/scsi_da.c:
In dadone_probezone(), free the data pointer before returning.
jhb [Thu, 11 Oct 2018 19:06:54 +0000 (19:06 +0000)]
MFC 338055: Remove some vestiges of IPI_LAZYPMAP on i386.
The support for lazy pmap invalidations on i386 was removed in r281707.
This removes the constant for the IPI and stops accounting for it when
sizing the interrupt count arrays.
hselasky [Thu, 11 Oct 2018 07:34:56 +0000 (07:34 +0000)]
MFC r339235:
Add missing steering rules for virtual function, VF, in mlx4en(4) driver.
When acting as a VF it is required to add steering rules for all unicast
addresses. Even if promiscious mode is selected. Else incoming data packets
will be dropped.
jhb [Wed, 10 Oct 2018 21:28:04 +0000 (21:28 +0000)]
Disable the KASSERT for curcpu == 0 in netisr for EARLY_AP_STARTUP.
In the EARLY_AP_STARTUP case, thread0 can migrate to another CPU
before this SYSINIT is run. However, the only part of this SYSINIT
that assumes it runs on CPU 0 is in the !EARLY_AP_STARTUP case when it
creates the netisr for the boot CPU. In the EARLY_AP_STARTUP case we
start up the netisr's for the first N CPUs during the SYSINIT itself
and don't depend on running on the boot CPU for correct operation.
This is a direct comit to stable/11 as the assertion was removed as part
of a different change in r302595.
According to the Intel SDM (Volme 3, 9.11.7) the BIOS signature MSR
should be zeroed before executing cpuid (although in practice it does
not seem to matter).
PR: 192487
Submitted by: Dan Lukes
Reported by: Henrique de Moraes Holschuh
emaste [Wed, 10 Oct 2018 15:37:10 +0000 (15:37 +0000)]
MFC r339019: clang: allow ifunc resolvers to accept arguments
Previously Clang required ifunc resolution functions to take no
arguments, presumably because GCC documented ifunc resolvers as taking
no arguments. However, GCC accepts resolvers accepting arguments, and
our rtld passes CPU ID information (cpuid, hwcap, etc.) to ifunc
resolvers. Just remove the check from the in-tree compiler for our in-
tree compiler.
projects / FreeBSD / FreeBSD.git / log