ae [Thu, 17 May 2018 10:01:47 +0000 (10:01 +0000)]
MFC r333458:
Fix the printing of rule comments.
Change uint8_t type of opcode argument to int in the print_opcode()
function. Use negative value to print the rest of opcodes, because
zero value is O_NOP, and it can't be uses for this purpose.
jhb [Wed, 16 May 2018 21:04:19 +0000 (21:04 +0000)]
MFC 332891,332892: Fixes for atomic_*cmpset() on arm.
332891:
Fix some harmless type mismatches in the ARM atomic_cmpset implementations.
The return value of atomic_cmpset() and atomic_fcmpset() is an int (which
is really a bool) that has the values 0 or 1. Some of the inlines were
using the type being operated on (e.g. uint32_t) as either the return type
of the function, or the type of a local 'ret' variable used to hold the
return value. Fix all of these to just use plain 'int'. Due to C promotion
rules and the fact that the value can only be 0 or 1, these should all be
harmless.
332892:
Implement 32-bit atomic_fcmpset() in userland for armv4/v5.
- Add an implementation of atomic_fcmpset_32() using RAS for armv4/v5.
This fixes recent world breakage due to use of atomic_fcmpset() in
userland.
- While here, be more careful to not expose wrapper macros for 64-bit
atomic_*cmpset to userland for armv4/v5 as only 32-bit cmpset is
implemented.
This has been reviewed, but not runtime-tested, but should fix the arm.arm
and arm.armeb worlds that have been broken for a while.
r331340:
cxgbe(4): Tunnel congestion drops on a port should be cleared when the
stats for that port are cleared.
r331342:
cxgbe(4): Do not read MFG diags information from custom boards.
r331472:
cxgbe(4): Always initialize requested_speed to a valid value.
This fixes an avoidable EINVAL when the user tries to disable AN after
the port is initialized but l1cfg doesn't have a valid speed to use.
r332050:
cxgbe(4): Always display an error message if SIOCSIFFLAGS will leave
IFF_UP and IFF_DRV_RUNNING out of sync. ifhwioctl in the kernel pays no
attention to the return code from the driver ioctl during SIOCSIFFLAGS
so these messages are the only indication that the ioctl was called but
failed.
r333276:
cxgbe(4): Update all firmwares to 1.19.1.0.
r333448:
cxgbe(4): Disable write-combined doorbells by default.
This had been the default behavior but was changed accidentally as part
of the recent iw_cxgbe+OFED overhaul. Fix another bug in that change
while here: the global knob affects all the adapters in the system and
should be left alone by per-adapter code.
ae [Tue, 15 May 2018 11:43:05 +0000 (11:43 +0000)]
MFC r333244:
Immediately propagate EACCES error code to application from tcp_output.
In r309610 and r315514 the behavior of handling EACCES was changed, and
tcp_output() now returns zero when EACCES happens. The reason of this
change was a hesitation that applications that use TCP-MD5 will be
affected by changes in project/ipsec.
TCP-MD5 code returns EACCES when security assocition for given connection
is not configured. But the same error code can return pfil(9), and this
change has affected connections blocked by pfil(9). E.g. application
doesn't return immediately when SYN segment is blocked, instead it waits
when several tries will be failed.
Actually, for TCP-MD5 application it doesn't matter will it get EACCES
after first SYN, or after several tries. Security associtions must be
configured before initiating TCP connection.
I left the EACCES in the switch() to show that it has special handling.
Reported by: Andreas Longwitz <longwitz at incore dot de>
Approved by: re (marius)
hselasky [Tue, 15 May 2018 09:40:52 +0000 (09:40 +0000)]
MFC r333362:
Fix for missing network interface address event when adding the default IPv6
based link-local address.
The default link local address for IPv6 is added as part of bringing the
network interface up. Move the call to "EVENTHANDLER_INVOKE(ifaddr_event,)"
from the SIOCAIFADDR_IN6 ioctl(2) handler to in6_notify_ifa() which should
catch all the cases of adding IPv6 based addresses to a network interface.
Add a witness warning in case the event handler is not allowed to sleep.
Approved by: re (marius)
Reviewed by: network (ae), kib
Differential Revision: https://reviews.freebsd.org/D13407
Sponsored by: Mellanox Technologies
gonzo [Tue, 15 May 2018 02:26:50 +0000 (02:26 +0000)]
MFC r331906:
Approved by: re (gjb)
Fix accidental USB port resets by GPIO on Zynq/Zedboard boards
The Zynq/Zedboard GPIO driver attempts to tri-state all GPIO pins on
boot up but the order in which I reset the hardware can cause the pins
to be briefly held low before being tri-stated. This is a problem on
boards that use GPIO pins to reset devices.
In particular, the Zybo and ZC-706 boards use a GPIO pin as a USB PHY
reset. If U-boot enables the USB port before booting the kernel, the
GPIO driver attach causes a glitch on the USB PHY reset and the USB
port loses power. My fix is to have the GPIO driver leave the pins in
whatever configuration U-boot placed them.
PR: 225713
Submitted by: Thomas Skibo <thoma555-bsd@yahoo.com>
r329188: Use tabs in io.d, fix alignment issues, remove extra newlines
r329334: Add errno definitions to /usr/lib/dtrace/errno.d
r329353: Add inline to errno.d for translating int to string
r329914: Updates and enhancements to io.d to aid DTrace scripting
r329995: Updates and enhancements to signal.d to aid DTrace scripting
r329996: Consistent casing for fallback SIGCHLD (s/Unknown/unknown/)
r330559: Introduce dwatch(1) as a tool for making DTrace more useful
r330560: Bump dwatch(1) internal version from 1.0-beta-91 to 1.0
r330672: Fix display of wrong pid from dtrace_sched(4)
r332865: Add `-dev' option to aid debugging of profiles
r332866: Add profile for send(2)/recv(2) syscalls
r332867: Remove the line used to demonstrate `-dev' option
r333513: Bugfix, usage displayed with `-1Q'
r333514: Separate default values so `-[BK] num' don't affect usage
r333515: Simplify info message test
r333516: Export ARGV to profiles loaded via load_profile()
r333517: Allow `-E code' to override profile EVENT_DETAILS
r333518: Expose process for ip/tcp/udp
r333519: Refactor sendrecv profile
gjb [Mon, 14 May 2018 17:43:43 +0000 (17:43 +0000)]
MFC r333473:
Add a special GCE_LICENSE variable to Makefile.gce, which when set,
will include license metadata in the resultant GCE image.
GCE_LICENSE is unset by default, as it primarily pertains to images
produced by the FreeBSD Project, but for downstream FreeBSD consumers,
it can be set in the make(1) environment in the format of:
The "license" is not a license, per se, but required metadata that
is required by the GCE marketplace. For the FreeBSD Project, the
license name is simply 'freebsd', with the description of 'FreeBSD'.
Approved by: re (marius)
Sponsored by: The FreeBSD Foundation
trasz [Mon, 14 May 2018 15:35:54 +0000 (15:35 +0000)]
MFC r333493:
Set kldxref_enable="YES" for ARM images. Without it, the images are missing
the /boot/kernel/linker.hints file, which breaks loading some of the modules
with dependencies, eg cfiscsi.ko.
This is a minimal fix for ARM images, in order to safely MFC it before
11.2-RELEASE. Afterwards, however, I believe we should actually just change
the default (as in, etc/defaults/rc.conf). The reason is that it's required
for every image that's being cross-built, as kldxref(1) cannot handle files
for non-native architectures. For the one that is not - amd64 - having it
on by default doesn't change anything - the script is noop if the linker.hints
already exists.
The long-term solution would be to rewrite kldxref(1) to handle other
architectures, and generate linker.hints at build time.
Approved by: re (marius@)
Sponsored by: DARPA, AFRL
jtl [Sat, 12 May 2018 01:55:24 +0000 (01:55 +0000)]
r285910 attempted to make shutdown() be POSIX compliant by returning
ENOTCONN when shutdown() is called on unconnected sockets. This change was
slightly modified by r316874, which returns ENOTCONN in the case of an
unconnected datagram socket, but still runs the shutdown code for the
socket. This specifically supports the case where the user-space code is
using the shutdown() call to wakeup another thread blocked on the socket.
In PR 227259, a user is reporting that they have code which is using
shutdown() to wakup another thread blocked on a stream listen socket. This
code is failing, while it used to work on FreeBSD 10 and still works on
Linux.
It seems reasonable to add another exception to support something users are
actually doing, which used to work on FreeBSD 10, and still works on Linux.
And, it seems like it should be acceptable to POSIX, as we still return
ENOTCONN.
This is a direct commit to stable/11. The listen socket code changed
substantially in head, and the code change there will be substantially
more complex. In the meantime, it seems to make sense to commit this
trivial fix to stable/11 given the fact that users appear to depend on
this behavior, this appears to have been an unintended change in stable/11,
and we did not announce the change.
PR: 227259
Reviewed by: ed
Approved by: re (gjb)
Sponsored by: Netflix, Inc.
Differential Revision: https://reviews.freebsd.org/D15021
Tested by: Eric Masson (emss at free.fr)
gjb [Fri, 11 May 2018 21:46:53 +0000 (21:46 +0000)]
Create a sun7i-a20-bananapi.dtb hard link to bananapi.dtb to fix
a boot failure on the Banana Pi SoC.
This is a direct commit to stable/11, as the sun7i-a20-bananapi.dtb
file exists in head, but appears to have been part of a larger
rework of dtb-related files that may have larger consequences than
hard link creation. Note: creating a hard link to dtb files was
an original fix in 12-CURRENT beforehand, introduced in r319603.
Approved by: re (marius)
Sponsored by: The FreeBSD Foundation
gjb [Thu, 10 May 2018 23:58:33 +0000 (23:58 +0000)]
Rename stable/11 from PRERELEASE to BETA1 as part of the 11.2-RELEASE
cycle.
Update the default pkg(8) repository to the 'quarterly' branch to
prevent further 11.2 builds from downgrading packages when invoking
'pkg upgrade' for the duration of the cycle.
Approved by: re (implicit)
Sponsored by: The FreeBSD Foundation
sbruno [Wed, 9 May 2018 16:14:12 +0000 (16:14 +0000)]
MFC r333019 r333046 r333085 r333086 r333132
smartpqi(4):
- Microsemi SCSI driver for PQI controllers.
- Found on newer model HP servers.
- Restrict to AMD64 only as per developer request.
The driver provides support for the new generation of PQI controllers
from Microsemi. This driver is the first SCSI driver to implement the
PQI queuing model and it will replace the aacraid driver for Adaptec
Series 9 controllers. HARDWARE Controllers supported by the driver include:
HPE Gen10 Smart Array Controller Family
OEM Controllers based on the Microsemi Chipset.
emaste [Wed, 9 May 2018 14:50:32 +0000 (14:50 +0000)]
MFC r332966: Add deprecation notice for lmc(4)
We intend to remove support before FreeBSD 12 is branched. These are
available only as 32-bit PCI devices. The driver has an ambiguous
license and I have not been successful in contacting the driver's author
in order to address this.
The planned deprecation has been announced on -current and -stable; if
we receive feedback that the driver is still useful and we are able to
resolve the license issue this deprecation notice can be reverted.
Relnotes: Yes
Approved by: re
Sponsored by: The FreeBSD Foundation
emaste [Wed, 9 May 2018 14:38:07 +0000 (14:38 +0000)]
MFC r332446: switch i386 memstick installer images to MBR
Some BIOSes have trouble booting from GPT in non-UEFI mode. This is
commonly reported with Lenovo laptops, including my x220. As we do not
currently support booting FreeBSD/i386 via UEFI there's no reason to
prefer GPT.
The "vestigial swap partition" was added in r265017 to work around an
issue with loader's GPT support, so we should not need it when using
MBR.
We may want to make the same change to amd64, although the issue there is
mitigated by such systems booting via UEFI in the common case.
PR: 227422
Approved by: re
Relnotes: Yes
Sponsored by: The FreeBSD Foundation
emaste [Tue, 8 May 2018 17:03:33 +0000 (17:03 +0000)]
MFC r333368: Prepare DB# handler for deferred trigger of watchpoints.
Prepare DB# handler for deferred trigger of watchpoints.
Since pop %ss/mov %ss instructions defer all interrupts and exceptions
for the next instruction, it is possible that the userspace watchpoint
trap executes on the first instruction of the kernel entry for
syscall/bpt.
In this case, DB# should be treated similarly to NMI: on amd64 we must
always load GSBASE even if the trap comes from kernel mode, and load
the kernel page table root into %cr3. Moreover, the trap must
use the dedicated stack, because we are still on the user stack when
trapped on syscall entry.
For i386, we must reload %cr3. The syscall instruction is not configured,
so there is no issue with executing on user stack when trapping.
Due to some CPU erratas it is not always possible to detect that the
userspace watchpoint triggered by inspecting %dr6. In trap(), compare the
trap %rip with the known unsafe entry points and if matched pretend that
the watchpoint did not fire at all.
Thank you to the MSRC Incident Response Team, and in particular Greg
Lenti and Nate Warfield, for coordinating the response to this issue
across multiple vendors.
Thanks to Computer Recycling at The Working Center of Kitchener for
making hardware available to allow us to test the patch on additional
CPU families.
Reviewed by: jhb
Discussed with: Matthew Dillon
Tested by: emaste
Approved by: re (so blanket)
Security: CVE-2018-8897
Security: FreeBSD-SA-18:06.debugreg
Sponsored by: The FreeBSD Foundation
erj [Mon, 7 May 2018 23:23:11 +0000 (23:23 +0000)]
MFC r333149: ixl(4): Update to 1.9.9-k
Major changes:
- Support for descriptor writeback mode (required by ixlv(4) for AVF support)
- Ability to disable firmware LLDP agent by user
- Fix for TX queue hang when using TSO
- Separate descriptor ring sizes for TX and RX rings
Approved by: re (marius)
Relnotes: yes
Sponsored by: Intel Corporation
gjb [Mon, 7 May 2018 16:21:53 +0000 (16:21 +0000)]
MFC r333262, r333264:
r333262:
Ensure the ports and src trees are available on GCE images,
satisfying a requirement to allow FreeBSD to be considered
a top-tier supported OS in Google Compute Engine.
r333264:
Fix a typo.
Approved by: re (kib)
Sponsored by: The FreeBSD Foundation
philip [Mon, 7 May 2018 06:58:19 +0000 (06:58 +0000)]
MFC r333247: Import tzdata 2018e
North Korea switches back to +09 on 2018-05-05.
This version more correctly models time stamps in time zones with
negative DST such as Europe/Dublin (from 1971 on), Europe/Prague
(1946/7), and Africa/Windhoek (1994/2017). This does not affect the
UT offsets, only time zone abbreviations and the tm_isdst flag.
emaste [Fri, 4 May 2018 14:49:37 +0000 (14:49 +0000)]
MFC r333234: zfs_ioctl: avoid out-of-bound read
admbugs: 796
Submitted by: Domagoj Stolfa <ds815@cam.ac.uk>
Reported by: Ilja Van Sprundel <ivansprundel@ioactive.com>
Approved by: re (early MFC as an EN candidate)
marius [Thu, 3 May 2018 15:40:56 +0000 (15:40 +0000)]
MFC: r327312, r327842, r327865
- Add initial support for Intel Ice Lake and Cannon Lake Ethernet MACs.
- Add workaround for Intel Sky Lake and Kabby Lake Ethernet MAC erratum
1.5.4.5.
- Fix uses of 1 << 31.
MFC r333016:
Merge r1.22-1.23 from NetBSD:
Don't assume M_PKTHDR is set only on the first mbuf of the chain.
The check is replaced by (m1 != m), which is equivalent to the previous
code: we want to modify m->m_pkthdr.len only when 'm' was not passed in
m_adj().
Fix a pretty bad mistake, that has always been there:
m_adj(m1, -(m1->m_len - roff));
if (m1 != m)
m->m_pkthdr.len -= (m1->m_len - roff);
This is wrong: m_adj() will modify m1->m_len, so we're using a wrong
value when manually adjusting m->m_pkthdr.len.
Reported by: Maxime Villard <max at m00nbsd dot net>
Obtained from: NetBSD
MFC r332886:
icmp6_reflect() sends ICMPv6 message with new IPv6 header. So, it is
considered as originated by our host packet. And thus rcvif should be
NULL, since it is used by ipfw(4) to determine that packet was originated
from this host. Some of icmp6_reflect() consumers reuse mbuf and m_pkthdr
without resetting rcvif pointer. To avoid this always reset m_pkthdr.rcvif
pointer to NULL in icmp6_reflect(). Also remove such line and comment
describing this from icmp6_error(), since it does not longer matters.
avg [Thu, 3 May 2018 07:47:03 +0000 (07:47 +0000)]
MFC r332752: set kdb_why to "trap" when calling kdb_trap from trap_fatal
This will allow to hook a ddb script to "kdb.enter.trap" event.
Previously there was no specific name for this event, so it could only
be handled by either "kdb.enter.unknown" or "kdb.enter.default" hooks.
Both are very unspecific.
Having a specific event is useful because the fatal trap condition is
very similar to panic but it has an additional property that the current
stack frame is the frame where the trap occurred. So, both a register
dump and a stack bottom dump have additional information that can help
analyze the problem.
I have added the event only on architectures that have trap_fatal()
function defined. I haven't looked at other architectures. Their
maintainers can add support for the event later.
Sample script:
kdb.enter.trap=bt; show reg; x/aS $rsp,20; x/agx $rsp,20
avg [Thu, 3 May 2018 06:34:07 +0000 (06:34 +0000)]
MFC r332426: allow ZFS pool to have temporary name for duration of current import
The change adds -t <name> option to zpool create and -t option to zpool
import in its form with an old name and a new name. This allows to
import (or create) a pool under a name that's different from its real,
permanent name without affecting that name. This is useful when working
with VM images or images of other physical systems if they happen to
have a ZFS pool with the same name as the host system.
pfctl: Don't break connections on skipped interfaces on reload
On reload we used to first flush everything, including the list of skipped
interfaces. This can lead to termination of these connections if they send
packets before the new configuration is applied.
Note that this doesn't currently happen on 12 or 11, because of special EACCES
handling introduced in r315514. This special behaviour in tcp_output() may
change, hence the fix in pfctl.
PR: 214613
Submitted by: Andreas Longwitz <longwitz at incore.de>
MFC 332735:
Fix two off-by-one errors when allocating MSI and MSI-X interrupts.
x86 enforces an (arbitray) limit on the number of available MSI and
MSI-X interrupts to simplify code (in particular, interrupt_source[]
is statically sized). This means that an attempt to allocate an MSI
vector needs to fail if it would go beyond the limit, but the checks
for exceeding the limit had an off-by-one error. In the case of MSI-X
which allocates interrupts one at a time this meant that IRQ 768 kept
getting handed out multiple times for msix_alloc() instead of failing
because all MSI IRQs were in use.
MFC r333015:
Add network device event for priority code point, PCP, changes.
When the PCP is changed for either a VLAN network interface or when
prio tagging is enabled for a regular ethernet network interface,
broadcast the IFNET_EVENT_PCP event so applications like ibcore can
update its GID tables accordingly.
MFC r332902: pwd_mkdb: default to network (big) endian hash order
For cross-architecture reproducibility. The db(3) functions work with
hashes of either endianness, and the current (v4) version password db
entries already store integers in network order. Do so with the hash as
well so that identical password databases can be created on big- and
little-endian hosts.
The -B and -L flags exist to set the endianness for legacy (v3) entries
when the -l flag is used, and they will still control hash endianness
(at least until the backwards compatibility infrastructure is removed
[a change that will not be merged to stable/11]).
MFC 332733:
Workaround fixed I/O port resources encoded as I/O port ranges in _CRS.
ACPI I/O port descriptors use _MIN and _MAX fields to specify the set
of allowable base (start) addresses for an I/O port resource along with
a _LEN field specifying the length. A fixed resource is supposed to be
encoded with _MIN == _MAX, but some buggy firmwares instead set _MAX to
the end of the fixed range. Relocating I/O ranges only make sense in
_PRS (possible resource settings), not in _CRS (current resource settings),
so if an I/O port range with _MAX set set to the end of the range is
present in _CRS, treat it as a fixed I/O port resource starting at
_MIN.
dim [Fri, 27 Apr 2018 19:21:39 +0000 (19:21 +0000)]
MFC r332833:
Recommit r332501, with an additional upstream fix for "Cannot lower
EFLAGS copy that lives out of a basic block!" errors on i386.
Pull in r325446 from upstream clang trunk (by me):
[X86] Add 'sahf' CPU feature to frontend
Summary:
Make clang accept `-msahf` (and `-mno-sahf`) flags to activate the
`+sahf` feature for the backend, for bug 36028 (Incorrect use of
pushf/popf enables/disables interrupts on amd64 kernels). This was
originally submitted in bug 36037 by Jonathan Looney
<jonlooney@gmail.com>.
As described there, GCC also uses `-msahf` for this feature, and the
backend already recognizes the `+sahf` feature. All that is needed is
to teach clang to pass this on to the backend.
The mapping of feature support onto CPUs may not be complete; rather,
it was chosen to match LLVM's idea of which CPUs support this feature
(see lib/Target/X86/X86.td).
I also updated the affected test case (CodeGen/attr-target-x86.c) to
match the emitted output.
Pull in r328944 from upstream llvm trunk (by Chandler Carruth):
[x86] Expose more of the condition conversion routines in the public
API for X86's instruction information. I've now got a second patch
under review that needs these same APIs. This bit is nicely
orthogonal and obvious, so landing it. NFC.
Pull in r329414 from upstream llvm trunk (by Craig Topper):
[X86] Merge itineraries for CLC, CMC, and STC.
These are very simple flag setting instructions that appear to only
be a single uop. They're unlikely to need this separation.
Pull in r329657 from upstream llvm trunk (by Chandler Carruth):
[x86] Introduce a pass to begin more systematically fixing PR36028
and similar issues.
The key idea is to lower COPY nodes populating EFLAGS by scanning the
uses of EFLAGS and introducing dedicated code to preserve the
necessary state in a GPR. In the vast majority of cases, these uses
are cmovCC and jCC instructions. For such cases, we can very easily
save and restore the necessary information by simply inserting a
setCC into a GPR where the original flags are live, and then testing
that GPR directly to feed the cmov or conditional branch.
However, things are a bit more tricky if arithmetic is using the
flags. This patch handles the vast majority of cases that seem to
come up in practice: adc, adcx, adox, rcl, and rcr; all without
taking advantage of partially preserved EFLAGS as LLVM doesn't
currently model that at all.
There are a large number of operations that techinaclly observe
EFLAGS currently but shouldn't in this case -- they typically are
using DF. Currently, they will not be handled by this approach.
However, I have never seen this issue come up in practice. It is
already pretty rare to have these patterns come up in practical code
with LLVM. I had to resort to writing MIR tests to cover most of the
logic in this pass already. I suspect even with its current amount
of coverage of arithmetic users of EFLAGS it will be a significant
improvement over the current use of pushf/popf. It will also produce
substantially faster code in most of the common patterns.
This patch also removes all of the old lowering for EFLAGS copies,
and the hack that forced us to use a frame pointer when EFLAGS copies
were found anywhere in a function so that the dynamic stack
adjustment wasn't a problem. None of this is needed as we now lower
all of these copies directly in MI and without require stack
adjustments.
Lots of thanks to Reid who came up with several aspects of this
approach, and Craig who helped me work out a couple of things
tripping me up while working on this.
Pull in r329673 from upstream llvm trunk (by Chandler Carruth):
[x86] Model the direction flag (DF) separately from the rest of
EFLAGS.
This cleans up a number of operations that only claimed te use EFLAGS
due to using DF. But no instructions which we think of us setting
EFLAGS actually modify DF (other than things like popf) and so this
needlessly creates uses of EFLAGS that aren't really there.
In fact, DF is so restrictive it is pretty easy to model. Only STD,
CLD, and the whole-flags writes (WRFLAGS and POPF) need to model
this.
I've also somewhat cleaned up some of the flag management instruction
definitions to be in the correct .td file.
Adding this extra register also uncovered a failure to use the
correct datatype to hold X86 registers, and I've corrected that as
necessary here.
Pull in r330264 from upstream llvm trunk (by Chandler Carruth):
[x86] Fix PR37100 by teaching the EFLAGS copy lowering to rewrite
uses across basic blocks in the limited cases where it is very
straight forward to do so.
This will also be useful for other places where we do some limited
EFLAGS propagation across CFG edges and need to handle copy rewrites
afterward. I think this is rapidly approaching the maximum we can and
should be doing here. Everything else begins to require either heroic
analysis to prove how to do PHI insertion manually, or somehow
managing arbitrary PHI-ing of EFLAGS with general PHI insertion.
Neither of these seem at all promising so if those cases come up,
we'll almost certainly need to rewrite the parts of LLVM that produce
those patterns.
We do now require dominator trees in order to reliably diagnose
patterns that would require PHI nodes. This is a bit unfortunate but
it seems better than the completely mysterious crash we would get
otherwise.
Together, these should ensure clang does not use pushf/popf sequences to
save and restore flags, avoiding problems with unrelated flags (such as
the interrupt flag) being restored unexpectedly.
Requested by: jtl
PR: 225330
MFC r332898:
Pull in r329771 from upstream llvm trunk (by Craig Topper):
[X86] In X86FlagsCopyLowering, when rewriting a memory setcc we need
to emit an explicit MOV8mr instruction.
Previously the code only knew how to handle setcc to a register.
This should fix a crash in the chromium build.
This fixes various assertion failures while building ports targeting
i386:
* www/firefox: isReg() && "This is not a register operand!"
* www/iridium, www/qt5-webengine: (I.atEnd() || std::next(I) ==
def_instr_end()) && "getVRegDef assumes a single definition or no
definition"
* devel/powerpc64-gcc: FromReg != ToReg && "Cannot replace a reg with
itself"
MFC 332657:
Properly do a deep copy of the ioctls capability array for fget_cap().
fget_cap() tries to do a cheaper snapshot of a file descriptor without
holding the file descriptor lock. This snapshot does not do a deep
copy of the ioctls capability array, but instead uses a different
return value to inform the caller to retry the copy with the lock
held. However, filecaps_copy() was returning 1 to indicate that a
retry was required, and fget_cap() was checking for 0 (actually
'!filecaps_copy()'). As a result, fget_cap() did not do a deep copy
of the ioctls array and just reused the original pointer. This cause
multiple file descriptor entries to think they owned the same pointer
and eventually resulted in duplicate frees.
The only code path that I'm aware of that triggers this is to create a
listen socket that has a restricted list of ioctls and then call
accept() which calls fget_cap() with a valid filecaps structure from
getsock_cap().
To fix, change the return value of filecaps_copy() to return true if
it succeeds in copying the caps and false if it fails because the lock
is required. I find this more intuitive than fixing the caller in
this case. While here, change the return type from 'int' to 'bool'.
Finally, make filecaps_copy() more robust in the failure case by not
copying any of the source filecaps structure over. This avoids the
possibility of leaking a pointer into a structure if a similar future
caller doesn't properly handle the return value from filecaps_copy()
at the expense of one more branch.
I also added a test case that panics before this change and now passes.
MFC: r332813
Fix use of pointer after being set NULL.
Using a pointer after setting it NULL is probably not a good plan.
Spotted by inspection during changes for Flexible File Layout Ioerr handling.
This code path obviously isn't normally executed.
MFC: r332790
Fix OpenDowngrade for NFSv4.1 if a client sets the OPEN_SHARE_ACCESS_WANT* bits.
The NFSv4.1 RFC specifies that the OPEN_SHARE_ACCESS_WANT bits can be set
in the OpenDowngrade share_access argument and are basically ignored.
I do not know of a extant NFSv4.1 client that does this, but this little
patch fixes it just in case.
It also changes the error from NFSERR_BADXDR to NFSERR_INVAL since the NFSv4.1
RFC specifies this as the error to be returned if bogus bits are set.
(The NFSv4.0 RFC didn't specify any error for this, so the error reply can
be changed for NFSv4.0 as well.)
Found by inspection while looking at a problem with OpenDowngrade reported
for the ESXi 6.5 NFSv4.1 client.