jhb [Tue, 3 Dec 2019 23:20:19 +0000 (23:20 +0000)]
Pass 0 to __builtin_frame_address() to appease modern GCC.
Modern versions of GCC warn about passing non-zero values to
__builtin_frame_address(). Passing 1 is a cosmetic change to remove
the db_trace_self() frame from the printed stack trace.
jhb [Tue, 3 Dec 2019 23:17:54 +0000 (23:17 +0000)]
Use uintptr_t instead of register_t * for the stack base.
- Use ustringp for the location of the argv and environment strings
and allow destp to travel further down the stack for the stackgap
and auxv regions.
- Update the Linux copyout_strings variants to move destp down the
stack as was done for the native ABIs in r263349.
- Stop allocating a space for a stack gap in the Linux ABIs. This
used to hold translated system call arguments, but hasn't been used
since r159992.
mckusick [Tue, 3 Dec 2019 23:07:09 +0000 (23:07 +0000)]
Currently the breadn_flags() and getblkx() interfaces are passed
the vnode, logical block number, and size of data block that is
being requested. They then use the VOP_BMAP function to calculate
the mapping from logical block number to physical block number from
which to access the data. This change expands the interface to also
pass the physical block number in cases where the VOP_MAP function
may no longer work, for example when a file is being truncated.
No functional change.
Reviewed by: kib
Tested by: Peter Holm
Sponsored by: Netflix
manu [Tue, 3 Dec 2019 22:08:54 +0000 (22:08 +0000)]
cpufreq_dt: Do not attach the device if the cpu isn't present
If we boot with hw.ncpu=X (available on arm and arm64 at least) we
shouldn't attach the cpufreq driver as cf_set_method will try to get
the cpuid and it doesn't exists.
This solves cpufreq panicing on RockChip RK3399 when booting with
hw.ncpu=4
manu [Tue, 3 Dec 2019 21:00:45 +0000 (21:00 +0000)]
Remove "all rights reserved" from copyright for the file I own.
Some of the files have both me and Jared McNeill and he gave me
permission to remove it from his files too.
manu [Tue, 3 Dec 2019 19:18:32 +0000 (19:18 +0000)]
arm64: rockchip: rl3399: Remove the ability to put the PLL in normal mode at boot
RK3399 PLLs have three modes :
- Normal, where they behave normally and their freq is calculated based on
the registers values.
- Slow, where the PLL freq is 24Mhz (well, the external oscillator).
- Deep Slow, used for suspend where the freq is 32Khz.
We used to put every CPU related PLL in normal mode but it can cause problem
if the firmware didn't setup the clocks register correctly.
And even if it did but left the pll in slow or deep slow mode that might be
because the PMIC suppling voltage for the CPU haven't been configured yet
and we cannot do that at this point.
So remove the ability to set PLLs to normal mode at boot to avoid any problems.
kevans [Tue, 3 Dec 2019 18:44:19 +0000 (18:44 +0000)]
lualoader: correct a typo from r354247
r354247 converted try_include to lfs + dofile with the loader.lua_path added
just before. Fortunately, there was a hardcoded /boot/lua fallback in case
loader.lua_path wasn't being set yet- I typo'd it as loader.lua_paths.
rlibby [Tue, 3 Dec 2019 17:43:57 +0000 (17:43 +0000)]
bitset: avoid pessimized code when bitset size is not constant
We have a couple optimizations for when the bitset is known to be just
one word. But with dynamically sized bitsets, it was actually more work
to determine the size than just to do the necessary computation. Now,
only use the optimization when the size is known to be constant.
rlibby [Tue, 3 Dec 2019 17:43:52 +0000 (17:43 +0000)]
mips busdma: bzero map on alloc
Maps from the mips busdma dmamap_zone were not completely initialized.
In particular, pagesneeded and pagesreserved were not initialized. This
could cause a crash.
Remove some dead fields from mips struct bus_dmamap while here.
hselasky [Tue, 3 Dec 2019 08:46:59 +0000 (08:46 +0000)]
Use refcount from "in_joingroup_locked()" when joining multicast
groups. Do not acquire additional references. This makes the IPv4 IGMP
code in line with the IPv6 MLD code.
Background:
The IPv4 multicast code puts an extra reference on the in_multi struct
when joining groups. This becomes visible when using daemons like
igmpproxy from ports, that multicast entries do not disappear from the
output of ifmcstat(8) when multicast streams are disconnected.
This fixes a regression issue after r349762.
While at it factor the ip_mfilter_insert() and ip6_mfilter_insert() calls
to avoid repeated "is_new" check.
kevans [Tue, 3 Dec 2019 02:30:52 +0000 (02:30 +0000)]
syscons.c: clang-format pass to reduce style inconsistencies
This was purely automatically massaged... some parts are still imperfect,
but this is close enough to make it more readable/easy to work on.
Unfortunately the vt/syscons/kdb situation slightly complicates changes to
tty locking, so some work will need to be done to remediate that.
jeff [Mon, 2 Dec 2019 22:42:05 +0000 (22:42 +0000)]
Fix a few places that free a page from an object without busy held. This is
tightening constraints on busy as a precursor to lockless page lookup and
should largely be a NOP for these cases.
jeff [Mon, 2 Dec 2019 22:34:19 +0000 (22:34 +0000)]
Don't run sched_preempt() inside of an extra critical section. This disables
the sched_preempt() switch optimization and causes the sched lock to be dropped
and immediately reacquired.
trasz [Mon, 2 Dec 2019 20:58:04 +0000 (20:58 +0000)]
Make use of the stats(3) framework in the TCP stack.
This makes it possible to retrieve per-connection statistical
information such as the receive window size, RTT, or goodput,
using a newly added TCP_STATS getsockopt(3) option, and extract
them using the stats_voistat_fetch(3) API.
See the net/tcprtt port for an example consumer of this API.
Compared to the existing TCP_INFO system, the main differences
are that this mechanism is easy to extend without breaking ABI,
and provides statistical information instead of raw "snapshots"
of values at a given point in time. stats(3) is more generic
and can be used in both userland and the kernel.
vmaffione [Mon, 2 Dec 2019 20:51:46 +0000 (20:51 +0000)]
bhyve: uniform printf format string newlines
Some of the printf statements only use LF to get a newline. However, a CR character is also required for the serial console to print debug logs in a nice way.
Fix those code locations that only use LF, by adding a CR character.
ken [Mon, 2 Dec 2019 19:57:39 +0000 (19:57 +0000)]
Fix a hang introduced in r351599.
My changes in 351599 (kindly committed by avg) made the cd(4) media check
asynchronous to avoid a sleep while holding a mutex.
There was a difficult to reproduce bug with those changes that caused a
hang on boot on some single processor machines/VMs. Leandro Lupori
managed to reproduce the bug, diagnose it, and supplied a patch! Here is
his analysis, from the PR:
======
I was able to reproduce the problem described in comment#14.
Actually, I wasn't trying to reproduce it, I just started seeing it a few
weeks ago, in CURRENT.
I can reproduce it consistently, by using QEMU to run a PowerPC64 VM with a
single core/thread (-smp 1).
It happens only when there is no media in the emulated CD-ROM, a device
that QEMU adds by default, unless -nodefaults is specified in command line.
I've debugged it and this is what I've found:
1- After the CD probe is successful, GEOM will try to open the device,
which will end up calling cdcheckmedia(), that sets CD state to
CD_STATE_MEDIA_PREVENT.
2- Next, scsi_prevent() is executed and succeeds, the CD_FLAG_DISC_LOCKED
flag is set and CD state moves to CD_STATE_MEDIA_SIZE.
3- Next, scsi_read_capacity() is executed and fails, state is set to
CD_STATE_MEDIA_ALLOW, cdmediaprobedone() is called and wakes up
cdcheckmedia().
4- Then, when cdstart() is invoked to process CD_STATE_MEDIA_ALLOW, it
first checks if CD_FLAG_DISC_LOCKED is set, and if so skips directly to
CD_STATE_MEDIA_SIZE state. This will repeat the steps of bullet 3, entering
an infinite MEDIA_SIZE command loop.
When there is a least another core/thread, the GEOM thread that performed
the initial cdopen() will get scheduled again, closing the CD device, that
will call cdprevent(PR_ALLOW) that clears the CD_FLAG_DISC_LOCKED flag and
breaks the loop.
So, apparently, the problem is CD_STATE_MEDIA_ALLOW being skipped when
CD_FLAG_DISC_LOCKED is set. If I understand correctly, in this case, the
state should be advanced to CD_STATE_MEDIA size only when the current state
is CD_STATE_MEDIA_PREVENT.
=====
ian [Mon, 2 Dec 2019 19:57:20 +0000 (19:57 +0000)]
Do not initialize the flags field in struct gpiobus_pin from the flags in
struct gpio_pin. It turns out these two sets of flags are completely
unrelated to each other.
Also, update the comment for GPIO_ACTIVE_LOW to reflect the fact that it
does get set, somewhat unobviously, by code that parses FDT data. The bits
from the FDT cell containing flags are just copied to gpiobus_pin.flags, so
there's never any obvious reference to the symbol GPIO_ACTIVE_LOW being
stored into the flags field.
ian [Mon, 2 Dec 2019 16:15:18 +0000 (16:15 +0000)]
Remove "all rights reserved" from copyright after getting a response from
Luiz that he also was not intentionally asserting that right, it was already
there when he added his name.
jhibbits [Mon, 2 Dec 2019 15:07:06 +0000 (15:07 +0000)]
revert r354714 "Boot arm64 kernel using booti command from U-boot."
After discussing with mmel@, it was clear this is insufficient to address
all the needs. mmel@ will commit his original patch, from
https://reviews.freebsd.org/D13861, and the additions needed from r354714
will be made afterward.
Requested by: mmel
Sponsored by: Juniper Networks, Inc.
dteske [Mon, 2 Dec 2019 05:24:16 +0000 (05:24 +0000)]
Fix spurious error from sysrc
When using sysrc to modify a file, the file should be created silently.
However, with the introduction of SVN r335280, an error of "No such file
or directory" would appear despite everything else working as-expected.
The nature of this spurious error is that SVN r335280 did not check if
the file exists first, before trying to fixup the line-endings in the
file just prior to modification.
PR: bin/240875
Reported by: Jose Luis Duran
MFC after: 3 days
ian [Sun, 1 Dec 2019 23:05:20 +0000 (23:05 +0000)]
Rewrite gpioiic(4) to use the gpio_pin_* API, and to conform to the modern
FDT bindings document for gpio-i2c devices.
Using the gpio_pin_* functions to acquire/release/manipulate gpio pins
removes the constraint that both gpio pins must belong to the same gpio
controller/bank, and that the gpioiic instance must be a child of gpiobus.
Removing those constraints allows the driver to be fully compatible with
the modern dts bindings for a gpio bitbanged i2c bus.
For hinted attachment, the two gpio pins still must be on the same gpiobus,
and the device instance must be a child of that bus. This preserves
compatibility for existing installations that have use gpioiic(4) with hints.
jhibbits [Sun, 1 Dec 2019 21:29:34 +0000 (21:29 +0000)]
powerpc: Add 'show frame <addr>' to show an arbitrary trap frame
This lets us print, for example, the user's trap frame when a panic occurs.
The frame address is given in the backtrace at the trap point, which can
then be passed to 'show frame'. This is useful for debugging as it can show
inputs that lead to a panic or fault. It can also be used to print trap
frames from other CPUs that get stuck.
i386 already has a similar command, but no others do.
ian [Sun, 1 Dec 2019 21:27:09 +0000 (21:27 +0000)]
Move most of the gpio_pin_* functions from ofw_gpiobus.c to gpiobus.c so
that they can be used by drivers on non-FDT-configured systems. Only the
functions related to acquiring pins by parsing FDT data remain in
ofw_gpiobus. Also, add two new functions for acquiring gpio pins based on
child device_t and index, or on the bus device_t and pin number. And
finally, defer reserving pins for gpiobus children until they acquire the
pin, rather than reserving them as soon as the child is added (before it's
even known whether the child will attach).
This will allow drivers configured with hints (or any other mechanism) to
use the same code as drivers configured via FDT data. Until now, a hinted
driver and an FDT driver had to be two completely different sets of code,
because hinted drivers could only use gpiobus calls to manipulate pins,
while fdt-configured drivers could not use that API (due to not always being
children of the bus that owns the pins) and had to use the newer
gpio_pin_xxxx() functions. Now drivers can be written in the more
traditional form, where most of the code is shared and only the resource
acquisition code at attachment time changes.
kevans [Sun, 1 Dec 2019 20:43:37 +0000 (20:43 +0000)]
Remove more needless <sys/tty.h> includes
As part of my journey to make it easy to determine what's relying on tty
bits, remove a couple more. Some of these just outright didn't need it,
while others did rely on <sys/tty.h> pollution for mutex headers.
kib [Sun, 1 Dec 2019 20:43:04 +0000 (20:43 +0000)]
Store the bottom of the shadow chain in OBJ_ANON object->handle member.
The handle value is stable for all shadow objects in the inheritance
chain. This allows to avoid descending the shadow chain to get to the
bottom of it in vm_map_entry_set_vnode_text(), and eliminate
corresponding object relocking which appeared to be contending.
Change vm_object_allocate_anon() and vm_object_shadow() to handle more
of the cred/charge initialization for the new shadow object, in
addition to set up the handle.
Reported by: jeff
Reviewed by: alc (previous version), jeff (previous version)
Tested by: pho
Sponsored by: The FreeBSD Foundation
Differrential revision: https://reviews.freebsd.org/D22541
tuexen [Sun, 1 Dec 2019 19:20:28 +0000 (19:20 +0000)]
Add a description for the TCP sysctl variable rfc6675_pipe.
It was introduced by r290122, but no documentation was provided.
This is taken from https://reviews.freebsd.org/D21798, since it
is not related to the feature added there.
Submitted by: Richard Scheffenegger
MFC after: 1 week
tuexen [Sun, 1 Dec 2019 18:05:02 +0000 (18:05 +0000)]
In order for the TCP Handshake to support ECN++, and further ECN-related
improvements, the ECN bits need to be exposed to the TCP SYNcache.
This change is a minimal modification to the function headers, without any
functional change intended.
tuexen [Sun, 1 Dec 2019 16:14:44 +0000 (16:14 +0000)]
Update the hostcache also for PTB messages received for SCTP/IPv6.
The corresponding code for SCTP/IPv4 was introduced in
https://svnweb.freebsd.org/base?view=revision&revision=317597
anish [Sun, 1 Dec 2019 04:00:08 +0000 (04:00 +0000)]
bhyve amd: amdvi_dump_cmds() log the command for which the command completion failed. Completion is checked in poll mode although it can be done using interrupts.
No need to log all the commands in command ring but only the last one for which completion failed.
Fix m_pullup() problem after removing PULLDOWN_TESTs and KAME EXT_*macros.
r354748-354750 replaced the KAME macros with m_pulldown() calls.
Contrary to the rest of the network stack m_len checks before m_pulldown()
were not put in placed (see r354748).
Put these m_len checks in place for now (to go along with the style of the
network stack since the initial commits). These are not put in for
performance but to avoid an error scenario (even though it also will help
performance at the moment as it avoid allocating an extra mbuf; not because
of the unconditional function call).
The observed error case went like this:
(1) an mbuf with M_EXT arrives and we call m_pullup() unconditionally on it.
(2) m_pullup() will call m_get() unless the requested length is larger than
MHLEN (in which case it'll m_freem() the perfectly fine mbuf) and migrate the
requested length of data and pkthdr into the new mbuf.
(3) If m_get() succeeds, a further m_pullup() call going over MHLEN will fail.
This was observed with failing auto-configuration as an RA packet of
200 bytes exceeded MHLEN and the m_pullup() called from nd6_ra_input()
dropped the mbuf.
(Re-)adding the m_len checks before m_pullup() calls avoids this problems
with mbufs using external storage for now.
kevans [Sat, 30 Nov 2019 20:10:50 +0000 (20:10 +0000)]
tty: implement TIOCNOTTY
Generally, it's preferred that an application fork/setsid if it doesn't want
to keep its controlling TTY, but it could be that a debugger is trying to
steal it instead -- so it would hook in, drop the controlling TTY, then do
some magic to set things up again. In this case, TIOCNOTTY is quite handy
and still respected by at least OpenBSD, NetBSD, and Linux as far as I can
tell.
I've dropped the note about obsoletion, as I intend to support TIOCNOTTY as
long as it doesn't impose a major burden.
delphij [Sat, 30 Nov 2019 20:06:53 +0000 (20:06 +0000)]
Reduce disk write load in /usr/libexec/save-entropy.
Before this commit, the save-entropy script rotates entropy files
like logs. This involves creating a new file that holds the entropy
and renaming of all existing entropy files. However, the entropy
data do not really need to be kept in a particular order, and
replacing the oldest file is sufficient.
This commit replaces the rotation with a scan in the
[1..entropy_save_num] space that finds the first empty slot, or
the slot of the oldest file, and writes entropy into that slot.
This also fixes an issue that prevents save-entropy from saving
any entropy when there is one non-regular file in any slot as a
side effect.
ian [Sat, 30 Nov 2019 19:16:44 +0000 (19:16 +0000)]
Add an OFWBUS_PNP_INFO() macro for devices that hang directly off the root
ofwbus. Also, apply some style(9) whitespace fixing to the
SIMPLEBUS_PNP_INFO() macro (no functional change).
mjg [Sat, 30 Nov 2019 17:24:42 +0000 (17:24 +0000)]
lockprof: use IPI-injecetd fences to fix hangs on stat dump and reset
The previously used quiesce_all_cpus walks all CPUs and waits until curthread
can run on them. Even on contemporary machines this becomes a significant
problem under load when it can literally take minutes for the operation to
complete. With the patch the stall is normally less than 1 second.
Reviewed by: kib, jeff (previous version)
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D21740
mjg [Sat, 30 Nov 2019 16:40:16 +0000 (16:40 +0000)]
vfs: swap placement between v_type and v_tag
The former is frequently accessed (e.g., in vfs_cache_lookup) and shares the
cacheline with v_usecount, avoidably adding to cache misses during concurrent
lookup. The latter is almost unused and probably can get garbage-collected.
The struct does not change in size despite enum vs char * discrepancy.
On 64-bit archs there used to be 4 bytes padding after v_type giving 480 bytes
in total.
tsoome [Sat, 30 Nov 2019 09:11:28 +0000 (09:11 +0000)]
loader.efi: efipart needs better support detecting nested partitions
Just as disks can have nested partitions, the same happens with cd devices,
so we need to detect device paths and make sure we will not mix the handles.
To address this:
we fetch handle array and create linked list of block devices.
we walk the list and detect parent devices and set children pd_parent.
for {fd, cd, hd}, we walk device list and pick up our devices and store to
corresponding list. We make sure we store parent device first.
For sorting we use 3 steps: We check for floppy, we check for cd and then
everything else must be hd.
In general, it seems the floppy devices have no parent.
CD can have both parents and children (multiple boot entries, partitions
from the hybrid disk image).
Tested by: cross+freebsd@distal.com on Cisco UCS systems, C200 series (C220M5, C240M4).
Also on MBP with UEFI 1.10
Reported by: Chriss Ross
MFC after: 1w
Differential Revision: https://reviews.freebsd.org/D22553
jeff [Fri, 29 Nov 2019 19:49:20 +0000 (19:49 +0000)]
Avoid acquiring the object lock if color is already set. It can not be
unset until the object is recycled so this check is stable. Now that we
can acquire the ref without a lock it is not necessary to group these
operations and we can avoid it entirely in many cases.
ian [Fri, 29 Nov 2019 18:05:54 +0000 (18:05 +0000)]
Ignore "gpio-hog" nodes when instantiating ofw_gpiobus children. Also,
in ofw_gpiobus_probe() return BUS_PROBE_DEFAULT rather than 0; we are not
the only possible driver to handle this device, we're just slightly better
than the base gpiobus (which probes at BUS_PROBE_GENERIC).
In the time since this code was first written, the gpio controller bindings
aquired the concept of a "hog" node which could be used to preset one or
more gpio pins as input or output at a specified level. This change doesn't
fully implement the hogging concept, it just filters out hog nodes when
instantiating child devices by scanning for child nodes in the fdt data.
The whole concept of having child nodes under the controller node is not
supported by the standard bindings, and appears to be a freebsd extension,
probably left over from the days when we had no support for cross-tree
phandle references in the fdt data.
kevans [Fri, 29 Nov 2019 14:46:13 +0000 (14:46 +0000)]
tty_rel_gone: add locking assertion
We already assert the lock is held later during tty_rel_free(), but it is
arguably good form to clarify locking expectations here as well at the
top-level that other drivers use.
kib [Fri, 29 Nov 2019 14:02:32 +0000 (14:02 +0000)]
Add a VN_OPEN_INVFS flag.
vn_open_cred() assumes that it is called from the top-level of a VFS
syscall. Writers must call bwillwrite() before locking any VFS
resource to wait for cleanup of dirty buffers.
ZFS getextattr() and setextattr() VOPs do call vn_open_cred(), which
results in wait for unrelated buffers while owning ZFS vnode lock (and
ZFS does not use buffer cache). VN_OPEN_INVFS allows caller to skip
bwillwrite.
Note that ZFS is still incorrect there, because it starts write on an
mp and locks a vnode while holding another vnode lock.
Reported by: Willem Jan Withagen <wjw@digiware.nl>
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
luporl [Fri, 29 Nov 2019 11:34:11 +0000 (11:34 +0000)]
[PPC] Remove extra \0 char inserted on vty by QEMU
Since version 2.11.0, QEMU became bug-compatible with
PowerVM's vty implementation, by inserting a \0 after
every \r going to the guest. Guests are expected to
workaround this issue by removing every \0 immediately
following a \r.
rlibby [Fri, 29 Nov 2019 06:25:07 +0000 (06:25 +0000)]
kern.mk: -Wno-error=stringop-overflow for gcc due to false positives
Demote gcc's Wstringop-overflow to Wno-error due to false positives.
E.g. the riscv64 build with gcc 8.3.0 has been failing with this warning
since r355062 [1]. A bug has been filed with gcc [2]. The warning was
first introduced in gcc 7.1 [3]. Hopefully we can avoiding suppressing
the warning in future gcc versions.
kevans [Fri, 29 Nov 2019 03:56:01 +0000 (03:56 +0000)]
tty_pts: don't rely on tty header pollution for sys/mutex.h
tty_pts.c relies on sys/tty.h for sys/mutex.h. Include it directly instead
of relying on this pollution to ease the diff for anyone that wants to try
converting the tty lock to anything other than a mutex.
cem [Fri, 29 Nov 2019 03:31:47 +0000 (03:31 +0000)]
Fix braino in previous bugfix r300174
The previous revision missed the exact same error in a copy paste block
of the same code in another function. Fix the identical case, too.
A DHCP client identifier is simply the hardware type (one byte)
concatenated with the hardware address (some variable number of bytes,
but at most 16). Limit the size of the temporary buffer to match and
the rest of the calculations shake out correctly.
PR: 238022
Reported by: Young <yangx92 AT hotmail.com>
Submitted by: Young <yangx92 AT hotmail.com>
MFC after: I don't plan to but you should feel free
Security: yes
dougm [Fri, 29 Nov 2019 02:06:45 +0000 (02:06 +0000)]
Functions that call vm_map_splay_merge sometimes set data fields
(e.g. root->left = NULL) to affect the behavior of that function. This
change stops that data manipulation, and instead calls a pair of
functions, one for the left direction and the other for the right,
with the function called depending whether or not we currently null
the root child in that direction to control the behavior of
vm_map_splay_merge.
rmacklem [Thu, 28 Nov 2019 23:34:23 +0000 (23:34 +0000)]
Fix two races while handling nfsuserd daemon start/stop.
A crash was reported where the nr_client field was NULL during an upcall
to the nfsuserd daemon. Since nr_client == NULL only occurs when the
nfsuserd daemon is being shut down, it appeared to be caused by a race
between doing an upcall and the daemon shutting down.
By inspection two races were identified:
1 - The nfsrv_nfsuserd variable is used to indicate whether or not the
daemon is running. However it did not handle the intermediate phase
where the daemon is starting or stopping.
This was fixed by making nfsrv_nfsuserd tri-state and having the
functions that are called during start/stop to obey the intermediate
state.
2 - nfsrv_nfsuserd was checked to see that the daemon was running at
the beginning of an upcall, but nothing prevented the daemon from
being shut down while an upcall was still in progress.
This race probably caused the crash.
The patch fixes this by adding a count of upcalls in progress and
having the shut down function delay until this count goes to zero
before getting rid of nr_client and related data used by an upcall.