Summary:
Various paths through hypot(x, y) will multiply x and y by a power of
two, perform the calculation in a range where IEEE-754 provides greater
precision, then undo the multiplication to determine the true result.
Undoing that multiplication is implemented as t1*w, where t1=2**k.
2**k is often computed by taking the high word of 1.0, then adding k<<20
(for doubles or long doubles) or k<<23 (for floats) to it, then
overwriting that high word. But when k is negative this left-shifts a
negative value -- and that's undefined behavior in many editions of C
and C++.
This patch should fix all hypot implementations to compute 2**k without
triggering this particular bit of undefined behavior.
Test Plan: I've only very lightly tested out the hypot(double, double)
change, in SpiderMonkey's JavaScript engine, for consistency with prior
behavior. The other functions' changes have more or less only been
eyeballed. Careful examination appreciated! Do note, however, that an
error in any of these changes would most likely produce a value that is
incorrect by a factor of two, so any mistake would most likely be
glaring if invoked.
Alexander Motin [Wed, 4 Dec 2019 15:14:14 +0000 (15:14 +0000)]
MFC r355165: Make DMAR allow Intel NTB device to access its own BAR0.
I have no good explanation why it happens, but I found that in B2B mode
at least Xeon v4 NTB leaks accesses to its configuration memory at BAR0
originated from the link side to its host side. DMAR predictably blocks
those, making access to remote scratchpad registers in B2B mode impossible.
This change creates identity mapping in DMAR covering the BAR0 addresses,
making the NTB work fine with DMAR enabled. It seems like allowing single
4KB range at 32KB offset may be enough, but I don't see a reason to be so
specific.
r355065:
Linux epoll: Don't deregister file descriptor after EPOLLONESHOT is fired
Linux epoll does not remove descriptor after one-shot event has been triggered.
Set EV_DISPATCH kqueue flag rather then EV_ONESHOT to get the same behavior.
Required by Linux Steam client.
PR: 240590
Reported by: Alex S <iwtcex@gmail.com>
Reviewed by: emaste, imp
Differential Revision: https://reviews.freebsd.org/D22513
r355066:
Linux epoll: Check both read and write kqueue events existence in EPOLL_CTL_ADD
Linux epoll EPOLL_CTL_ADD op handler should always check registration
of both EVFILT_READ and EVFILT_WRITE kevents to deceide if supplied
file descriptor fd is already registered with epoll instance.
r355067:
Linux epoll: Register events with zero event mask
Such an events are legal and should be interpreted as EPOLLERR | EPOLLHUP.
Register a disabled kqueue event in that case as we do not support EPOLLHUP yet.
Required by Linux Steam client.
PR: 240590
Reported by: Alex S <iwtcex@gmail.com>
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D22516
r355068:
Linux epoll: Allow passing of any negative timeout value to epoll_wait
Linux epoll allow passing of any negative timeout value to epoll_wait()
to cause unbound blocking
Eric van Gyzen [Tue, 3 Dec 2019 22:57:10 +0000 (22:57 +0000)]
MFC r354624
tip/cu: check for EOF on input on the local side
If cu reads an EOF on the input side, it goes into a tight loop
sending a garbage byte to the remote. With this change, it exits
gracefully, along with its child.
Ravi Pokala [Tue, 3 Dec 2019 22:51:25 +0000 (22:51 +0000)]
MFC r354102:
Args for buf_track() might be unused
If neither FULL_BUF_TRACKING nor BUF_TRACKING are defined, then the body of
buf_track() becomes empty. Mark the arguments with "__unused" so the
compiler doesn't complain about unused arguments in that case.
Ravi Pokala [Tue, 3 Dec 2019 22:49:24 +0000 (22:49 +0000)]
MFC r343583:
Remove unecessary "All rights reserved" from files under my or Panasas's
copyright.
When all member nations of the Buenos Aires Convention adopted the Berne
Convention, the phrase "All rights reserved" became unnecessary to assert
copyright. Remove it from files under my or Panasas's copyright. The files
related to jedec_dimm(4) also bear avg@'s copyright; he has approved this
change.
Kyle Evans [Tue, 3 Dec 2019 19:00:12 +0000 (19:00 +0000)]
MFC r354712: arm64: fix BUS_DMA_ALLOCNOW for non-paged aligned sizes
For any size that isn't page-aligned, we end up not pre-allocating enough
for a single mapping because we truncate the size instead of rounding up to
make sure the last bit is accounted for, leaving us one page shy of what we
need to fulfill a request.
Kyle Evans [Tue, 3 Dec 2019 18:58:45 +0000 (18:58 +0000)]
MFC r354541: csu: Fix dynamiclib/init_test:jcr_test on !HAVE_CTORS archs
.jcr still needs a 0-entry added in crtend, even on !HAVE_CTORS archs, as
we're still getting .jcr sections added -- presumably due to the reference
in crtbegin. Without this terminal, the .jcr section (without data) overlaps
with the next section and register_classes in crtbegin will be examining the
wrong item.
These files already have 'device' lines that they require; adding a
dependency on SOC_* options is an extra restriction that adds extra
verbosity when future supported Broadcom-based SOC will also feature the
same compatible device.
Users wishing to not compile these devices in should remove the 'device'
lines from their config.
Summary:
- basic: test application of patches created by diff -u at the
beginning/middle/end of file, which have differing amounts of context
before and after chunks being added
- limited_ctx: stems from PR 74127 in which a rogue line was getting added
when the patch should have been rejected. Similar behavior was
reproducible with larger contexts near the beginning/end of a file. See
r326084 for details
- file_creation: patch sourced from /dev/null should create the file
- file_nodupe: said patch sourced from /dev/null shouldn't dupe the contents
when re-applied (personal vendetta, WIP, see comment)
- file_removal: this follows from nodupe; the reverse of a patch sourced
from /dev/null is most naturally deleting the file, as is expected based
on GNU patch behavior (WIP)
r351866: patch(1): fix the file removal test, strengthen it a bit
To remain compatible with GNU patch, we should ensure that once we're
removing empty files after a reversed /dev/null patch we don't remove files
that have been modified. GNU patch leaves these intact and just reverses the
hunk that created the file, effectively implying --remove-empty-files for
reversed /dev/null patches.
r354328: patch(1): give /dev/null patches special treatment
We have a bad habit of duplicating contents of files that are sourced from
/dev/null and applied more than once... take the more sane (in most ways)
GNU route and complain if the file exists and offer reversal options.
This still falls short a little bit as selecting "don't reverse, apply
anyway" will still give you duplicated file contents. There's probably other
issues as well, but awareness is the first step to happiness.
Kyle Evans [Tue, 3 Dec 2019 18:50:18 +0000 (18:50 +0000)]
MFC r354246: liblua: add loader.lua_path
As described previously, loader.lua_path is absolute path where scripts are
installed. A future commit will use this to build paths for dofile in
try_include, rather than the current pcall/require setup that makes it more
difficult to coordinate loader aborts from local.lua -- we do not need the
flexibility of require(), and local.lua is in-fact not a 'module-like' file
as we will not be referencing anything from it.
Kyle Evans [Tue, 3 Dec 2019 18:38:51 +0000 (18:38 +0000)]
MFC r354236: mdmfs(8): add -k skel option to populate fs from a skeleton
mdmfs(8) lacks the ability to populate throwaway memory filesystems from an
existing directory.
This features permits an interesting setup where /var for instance lives on
a device where wear-leveling is something you want to avoid as much as
possible and nonetheless you don't want to lose your logs, ports metadata,
etc. Here are the steps:
1. Copy /var to /var.bak;
2. Mount an mfs into /var using -k /var.bak at startup;
3. Synchronize /var to /var.bak weekly and on shutdown.
Note that this more or less mimics OpenBSD's mount_mfs(8) -P flag.
Kyle Evans [Tue, 3 Dec 2019 18:28:39 +0000 (18:28 +0000)]
MFC rarm: correct kernelstack allocation size
This appears to be a copy-pasto from previous lines that propagated to v6
over the years. Indeed, nothing references kernelstack beyond
USPACE_SVC_STACK_TOP and it would be odd if anything did.
Kyle Evans [Tue, 3 Dec 2019 18:25:16 +0000 (18:25 +0000)]
MFC r354245, r354833, r354837: add flua to the base system
r354245: stand: consolidate knowledge of lua path
Multiple places coordinate to 'know' where lua scripts are installed. Knock
this down to being formally defined (and overridable) in exactly one spot,
defs.mk, and spread the knowledge to loaders and liblua alike. A future
commit will expose this to lua as loader.lua_path, so it can build absolute
paths to lua scripts as needed.
r354833: Add flua to the base system, install to /usr/libexec
FreeBSDlua ("flua") is a FreeBSD-private lua, flavored with whatever
extensions we need for base system operations. We currently support a subset
of lfs and lposix that are used in the rewrite of makesyscall.sh into lua,
added in r354786.
flua is intentionally written such that one can install standard lua and
some set of lua modules from ports and achieve the same effect.
linit_flua is a copy of linit.c from contrib/lua with lfs and lposix added
in. This is similar to what we do in stand/. linit.c has been renamed to
make it clear that this has flua-specific bits.
luaconf has been slightly obfuscated to make extensions more difficult. Part
of the problem is that flua is already hard enough to use as a bootstrap
tool because it's not in PATH- attempting to do extension loading would
require a special bootstrap version of flua with paths changed to protect
the innocent.
src.lua.mk has been added to make it easy for in-tree stuff to find flua,
whether it's bootstrap-flua or relying on PATH frobbing by Makefile.inc1.
r354837: flua: newer GCC complains about format-nonliteral at WARNS=2
Alexander Motin [Tue, 3 Dec 2019 16:51:26 +0000 (16:51 +0000)]
MFC r355023: Do not retry long ready waits if previous gave nothing.
I have some disks reporting "Logical unit is in process of becoming ready"
for about half an hour before finally reporting failure. During that time
CAM waits for the readiness during ~2 minutes for each request, that makes
system boot take very long time.
This change reduces wait times for the following requests to ~1 second if
previously long wait for that device has timed out.
Alexander Motin [Tue, 3 Dec 2019 16:48:21 +0000 (16:48 +0000)]
MFC r355010: Make CAM use root_mount_hold_token() to delay boot.
Before this change CAM used config_intrhook_establish() for this purpose,
but that approach does not allow to delay it again after releasing once.
USB stack uses root_mount_hold() to delay boot until bus scan is complete.
But once it is, CAM had no time to scan SCSI bus, registered by umass(4),
if it already done other scans and called config_intrhook_disestablish().
The new approach makes it work smooth, assuming the USB device is found
during the initial bus scan. Devices appearing on USB bus later may still
require setting kern.cam.boot_delay, but hopefully those are minority.
Alexander Motin [Tue, 3 Dec 2019 16:42:32 +0000 (16:42 +0000)]
MFC r341756 (by scottl):
Don't allocate the config_intrhook separately from the softc, it's small
enough that it costs more code to handle the malloc/free than it saves.
linprocfs: Make sure to report -1 as tty when we have no controlling tty.
When reporting a process' stats, we can't just provide the tty as an
unsigned long, as if we have no controlling tty, the tty would be NODEV, or
-1. Instaed, just special-case NODEV.
Andriy Gapon [Tue, 3 Dec 2019 07:22:16 +0000 (07:22 +0000)]
MFC r354349: if_ixv: disable RSS configuration on 82599 and X540 VFs
It is reported that those VFs share their RSS configuration with PF and,
thus, they cannot be configured independently.
Also:
- add missing opt_rss.h to if_ixv.c, otherwise RSS kernel option could
not be seen
- do not enable IXGBE_FEATURE_RSS on the older VFs
- set flowid / hash type to M_HASHTYPE_NONE or M_HASHTYPE_OPAQUE_HASH
(based on what the hardware reports) if IXGBE_FEATURE_RSS is not set
Cy Schubert [Mon, 2 Dec 2019 21:00:29 +0000 (21:00 +0000)]
MFC r355156:
Include fin, the packet information structure (fr_info_t), in the
l4sums DTrace probe, making more information available for the diagnosis
of IPv6 checksum errors.
Port illumos change: https://www.illumos.org/issues/11667
Move lz4.c out of zfs tree to opensolaris/common/lz4, adjust it to be
usable from kernel/stand/userland builds, so we can use just one single
source. Add lz4.h to declare lz4_compress() and lz4_decompress().
This addition will enable us to sync an open TXG to the main pool on
demand. The functionality is similar to sync(2) but 'zpool sync' will
return when data has hit the main storage instead of potentially just
the ZIL as is the case with the sync(2) cmd.
r345839: Assert that q can't be NULL. 'empty' is always non-NULL when DIREMPTY
r345894: Restore the ability of checking and fixing next free
r345897: Restore lfcl when LOSTDIR's chain was corrupted and overwritten
r345900: Implement checking of `.' and `..' entries of subdirectory.
r345901: Fix build.
r345976: Write string constant differently to improve readability.
r346220: Don't cast result from malloc().
r348602: Don't increment cl after increment.
r348767: preen should work independently with alwaysyes and alwaysno.
r348967: Avoid out of boundary access when checking invalid long filenames.
r349047: Blankspace. No actual code change.
r349048: In ask(): override default option if any of alwaysyes/alwaysno/rdonly is
r351502: Comment boot block checks and perform additional sanity checks:
r351623: Remove unneeded blank line. No functional change.
r352364: Avoid mixing cluster numbers and sector numbers. Makes code more readable.
Alexander Motin [Fri, 29 Nov 2019 01:00:06 +0000 (01:00 +0000)]
MFC r354752: Cleanup address range checks in ioat(4).
- Deduce allowed address range for bus_dma(9) from the hardware version.
Different versions (CPU generations) have different documented limits.
- Remove difference between address ranges for src/dst and crc. At least
docs for few recent generations of CPUs do not mention anything like that,
while older are already limited with above limits.
- Remove address assertions from arguments. While I do not think the
addresses out of allowed ranges should realistically happen there due to
the platforms physical address limitations, there is now bus_dma(9) to
make sure of that, preferably via IOMMU.
- Since crc now has the same address range as src/dst, remove crc_dmamap,
reusing dst2_dmamap instead.
Alexander Motin [Fri, 29 Nov 2019 00:25:39 +0000 (00:25 +0000)]
MFC r354753: Initialize *comp_update with valid value.
I've noticed that sometimes with enabled DMAR initial write from device
to this address is somehow getting delayed, triggering assertion due to
zero default being invalid.
Dimitry Andric [Thu, 28 Nov 2019 20:09:19 +0000 (20:09 +0000)]
MFC r354908:
Add explanatory comments for the different SRCS_xxx variables used in
the Makefiles for libllvm and libclang. While here, cleanup a commented
out SRCS entry in libllvmminimal's Makefile.
Emmanuel Vadot [Thu, 28 Nov 2019 18:44:06 +0000 (18:44 +0000)]
MFC r353917-r353919, r354396-r354397
r353917:
regulator: Add a regnode_method_init
This is a default init method for regulator that don't really
need one.
r353918:
axp81x: Use the default regnode_init method
r353919:
regulator: Add a regnode_set_constraint function
This method check that boot_on or always_on is set to 1 and if it
is it will try to enable the regulator.
The binding docs aren't clear on what to do but Linux enable the regulator
if any of those properties is set so we want to do the same.
The function first check the status to see if the regulator is
already enabled it then get the voltage to check if it is in a acceptable
range and then enables it.
This will be either called from the regnode_init method (if it's needed by the platform)
or by a SYSINIT at SI_SUB_LAST
r354396:
regulator: Add regulator_check_voltage function
This function will call the regnode_check_voltage method for a given regulator
and check if the desired voltage in reachable by it.
Also adds a default method that check the std_param and which should be enough
for most regulators and add it as the method for axp* rk805 and fixed regulators.
r354397:
arm: allwinner: aw_mmc: Check if the regulator support the voltage
Don't blindy say that we support both 3.3V and 1.8V.
If we have a regulator for the data lines, check that the voltage is
supported before adding the signaling caps.
If we don't have a regulator, just assume that the data lines are 3.3V
This unbreak eMMC on some allwinner boards.
Emmanuel Vadot [Thu, 28 Nov 2019 18:15:05 +0000 (18:15 +0000)]
MFC r352858, r352860, r353172
r352858:
Import DTS files from Linux 5.2
r352860:
Import DTS files from Linux 5.3
r353172:
arm: dts: ti: Fix mmc3 instance by setting it to disabled
DTS Import of Linux 5.3 added a patch that rework the L3 mmc instance
in the AM335x SoC but removed the status = 'disabled' on the node.
This cause the kernel to probe the device even if the board doesn't
have this mmc used and since we don't correctly activate the clock
for this module we panic with an external data abort.
Beaglebone(s) don't have this device anyway so simply disabling it.
Patch for the DTS was sent upstream.
https://patchwork.kernel.org/patch/11176921/
Emmanuel Vadot [Thu, 28 Nov 2019 17:45:57 +0000 (17:45 +0000)]
MFC r352853, r352903-r352904, r352936-r352937
r352853:
arm64: rockchip: Add usb2phy driver
This driver is for the usb phy present on rockchip SoC.
It only support RK3399 and host mode for now.
The driver expose the usb clock needed by the usb controller.
r352903:
arm64: rockchip: correct reset value
If bit is 0 the reset is not asserted.
Also register our self as a reset provider, this was commented
in r352850
Reported by: mmel
r352904:
arm64: rockchip: rk_clk_pll: Check mode on recalc
If the pll is in slow or deep slow mode return the correct frequency.
r352936:
arm64: rockchip: rk805: Switch to iicdev_{readfrom,writeto}
This simpify the code a bit.
r352937:
syr827: Switch to iicdev_{readfrom,writeto}
Also use IIC_INTRWAIT as we need this to work with the rockchip i2c driver.
r347097 by ganbold:
Add emmc clock definitions for Rockchip RK3399 SoC.
r351187 by mmel:
Improve rk_pinctrl driver:
- add support for 'output-low', 'output-high', 'output-low' and
'output-enable' properties. These are use in RK3288 DT files
- add support for RK3288
- to reduce overall file size, use local macros for initialization
of pinctrl description structures.
r351551:
arm64: rk3328: pinctrl: Add gpio banks and fix iomux
Since r351187 the pinctrl driver need to know the gpio bank as it
directly attach the gpio driver to handle some setup that might
be present in the dts, add the gpio banks table for rk3328.
While here fix some IOMUX definition that prevented to boot
on RK3328 as pinctrl wasn't configured correctly.
r351552:
arm64: rk3399: pinctrl: Add gpio banks and fix iomux
Since r351187 the pinctrl driver need to know the gpio bank as it
directly attach the gpio driver to handle some setup that might
be present in the dts, add the gpio banks table for rk3399.
While here fix some IOMUX definition that prevented to boot
on RK3399 as pinctrl wasn't configured correctly.
Module resets where not implemented when rockchip clocks were commited.
Implement them.
Since all resets registers are contiguous a driver only need to give
the start offset and the number of resets. This avoid to have to declare
every resets.
r352851:
arm64: rockchip: Fix map_gpio
The map_gpio function wasn't correct, the first element is the pin
and not the phandle.
r352852:
dwc: Add more delay for chip reset
On rockchip board it seems that the value in the DTS
are not enough for reseting the chip, I don't know if
the value are really incorrect or if DELAY is not precise
enough or if the rockchip gpio driver have some "lag" of some
kind or not.
For now just add more delay.
r350842:
allwinner: Rework the BUS_PASS on drivers
- Put all clock and control unit driver in BUS_PASS_RESOURCE except
for the DE2 CCU as it needs the main CCU to be available.
- Use BUS_PASS_CPU for a20_cpu_cfg as it makes more sense.
- For aw_syscon use SCHEDULER pass as we need it early for drivers
that attach in BUS_PASS_SUPPORTDEV
- For the rest we can use BUS_PASS_SUPPORTDEV
r350844:
allwinner: Add a new clock aw_clk_m
We used the aw_clk_nm clock for clock with only one divider factor
and used a fake multiplier factor. This cannot work properly as we
end up writing the "fake" factor to the register (and so always set
the LSB to 1).
Create a new clock for those.
The reason for not using the clk_div clock is because those clocks are
a bit special. Since they are (almost) all related to video we also need
to set the parent clock (the main PLL) to a frequency that they can support.
As the main PLL have some minimal frequency that they can support we need to
be able to set the main PLL to a multiple of the desired frequency.
Let say you want to have a 71Mhz pixel clock (typical for a 1280x800 display)
and the main PLL cannot go under 192Mhz, you need to set it to 3 times the
desired frequency and set the divider to 3 on the hdmi clock.
So this also introduce the CLK_SET_ROUND_MULTIPLE flag that allow for this kind
of scenario.
r350845:
Remove some duplicate code that end up in r350844
r350846:
allwinner: Add support to min/max in aw_clk_frac
The Fractionals clock in Allwinner device have some min/max frequencies
that they can do.
Add support for it.
r351099:
arm: allwinner: Set aw_ccu to BUS_PASS_BUS
In r350842 I've switched the bus pass to resource so it matches the other
clock drivers but this cannot work as this drivers is meant to match
the dts node '/clocks' and if we don't do it at this pass simplebus is
catching this node and we cannot attach.
This solve booting on Allwinner boards that are still using /clocks (A20 SoC)
r352848:
arm64: allwinner: a64: Add PLL_MIPI
PLL_MIPI is the last important PLL that we missed.
Add support for it.
Since it's one of the possible parent for TCON0 also add this clock
now that we can.
While here add some info about what video related clocks should be
enabled at boot and with what frequency.
r352859:
arm: allwinner: Add pll_mipi to the files
Ed Maste [Thu, 28 Nov 2019 02:18:19 +0000 (02:18 +0000)]
MFC r354897: sshd: make getpwclass wrapper MON_ISAUTH not MON_AUTH
In r339216 a privsep wrapper was added for login_getpwclass to address
PR 231172. Unfortunately the change used the MON_AUTH flag in the
wrapper, and MON_AUTH includes MON_AUTHDECIDE which triggers an
auth_log() on each invocation. getpwclass() does not participate in the
authentication decision, so should be MON_ISAUTH instead.
PR: 234793
Submitted by: Henry Hu
Reviewed by: Yuichiro NAITO
MFC after: 1 week
Alan Cox [Wed, 27 Nov 2019 19:34:33 +0000 (19:34 +0000)]
MFC r350579,r350741,r352584
Enable superpage promotion within the kernel pmap.
Ordinarily, during a superpage promotion or demotion within a pmap, the
pmap's lock ensures that other operations on the pmap don't observe the
old mapping being broken before the new mapping is established. However,
pmap_kextract() doesn't acquire the kernel pmap's lock, so it may observe
the broken mapping. And, if it does, it returns an incorrect result.
This revision implements a lock-free solution to this problem in
pmap_update_entry() and pmap_kextract() because pmap_kextract() can't
acquire the kernel pmap's lock.
In case a translation fault on the kernel address space occurs from
within a critical section, we must perform a lock-free check on the
faulting address.
bhyve: rework mevent processing to fix a race condition
At the end of both mevent_add() and mevent_update(), mevent_notify()
is called to wakeup the I/O thread, that will call kevent(changelist)
to update the kernel.
A race condition is possible where the client calls mevent_add() and
mevent_update(EV_ENABLE) before the I/O thread has the chance to wake
up and call mevent_build()+kevent(changelist) in response to mevent_add().
The mevent_add() is therefore ignored by the I/O thread, and
kevent(fd, EV_ENABLE) is called before kevent(fd, EV_ADD), resuliting
in a failure of the kevent(fd, EV_ENABLE) call.
bhyve: add support for virtio-net mergeable rx buffers
Mergeable rx buffers is a virtio-net feature that allows the hypervisor
to use multiple RX descriptor chains to receive a single receive packet.
Without this feature, a TSO-enabled guest is compelled to publish only
64K (or 32K) long chains, and each of these large buffers is consumed
to receive a single packet, even a very short one. This is a waste of
memory, as a RX queue has room for 256 chains, which means up to 16MB
of buffer memory for each (single-queue) vtnet device.
With the feature on, the guest can publish 2K long chains, and the
hypervisor will merge them as needed.
This change also enables the feature in the netmap backend, which
supports virtio-net offloads. We plan to add support for the
tap backend too.
Note that differently from QEMU/KVM, here we implement one-copy receive,
while QEMU uses two copies.
projects / FreeBSD / FreeBSD.git / log