Add support for prio-tagged traffic for RDMA in ibcore.
When receiving a PCP change all GID entries are reloaded.
This ensures the relevant GID entries use prio tagging,
by setting VLAN present and VLAN ID to zero.
The priority for prio tagged traffic is set using the regular
rdma_set_service_type() function.
Fake the real network device to have a VLAN ID of zero
when prio tagging is enabled. This is logic is hidden inside
the rdma_vlan_dev_vlan_id() function which must always be used
to retrieve the VLAN ID throughout all of ibcore and the
infiniband network drivers.
The VLAN presence information then propagates through all
of ibcore and so incoming connections will have the VLAN
bit set. The incoming VLAN ID is then checked against the
return value of rdma_vlan_dev_vlan_id().
RoCEv2 Annex states that for RoCEv2 over IPv4, the corresponding
IPv4 address is encoded into the GID according to the following rule:
GID= :ffff:<IPv4 address>
Remove the 0xff0e prefix for RoCEv2 packets with IPv4 and leave it
zeroed and change rdma_is_multicast_addr() to consider the new logic.
For multicast functions in ibcore, verify that LIDs are multicast LIDs.
The Infiniband spec defines "A multicast address is defined by a
MGID and a MLID" (section 10.5).
Add check to verify that the MLID value is in the correct address
range.
RoCE Annex (A16.9.10/11) declares that during attach (detach) QP to a
multicast group, if the QP is associated with a RoCE port, the
multicast group MLID is unused and is ignored.
During attach or detach multicast, when the QP is associated with a
port, it is enough to check the port's link layer and validate the
LID only if it is Infiniband. Otherwise, avoid validating the
multicast LID.
Implement a more generic solution for detecting loopback.
The problem was that the default netdevice was resolved
for loopback also when VLAN was used. Use real network
device instead of loopback device for bound device
interface.
How to test:
ucmatose -b 127.0.0.1 -p 20090
ucmatose -s 5.6.5.1 -p 20090
Note that RDMA treats the IPv4 and IPv6 loopback
addresses like any address.
If the MGID/MLID pair is not on the list return an error in ibcore.
A list of MGID/MLID pairs is built when doing a multicast attach. When
the multicast detach is called, the list is searched, and regardless of
the search outcome, the driver detach is called.
If an MGID/MLID pair is not on the list, driver detach should not be
called, and an error should be returned. Calling the driver without
removing an MGID/MLID pair from the list can leave the core and driver
out of sync.
When two handlers used the same object in the old schema, we blocked
the process in the kernel. The new schema just returns -EBUSY. This
could lead to different behaviour in applications between the old
schema and the new schema. In most cases, using such handlers
concurrently could lead to crashing the process. For example, if
thread A destroys a QP and thread B modifies it, we could have the
destruction happens before the modification. In this case, we are
accessing freed memory which could lead to crashing the process.
This is true for most cases. However, attaching and detaching
a multicast address from QP concurrently is safe. Therefore, we
preserve the original behaviour by adding a lock there.
Only update source address when resolving is successful in ibcore.
When resolving an IP address in ibcore, only update the source address
upon normal completion. The ibcore address resolve function does not
care about the scope ID value of the IPv6 link-local addresses and expects
this information has already been extracted into the bound_dev_if field.
Because the same IPv6 link-local address can exist on multiple interfaces
the ibcore address resolver gets confused and returns ENETUNREACH.
Instead of updating both source address and bound_dev_if just keep the
address set to any address until resolving completes. For the sake of code
symmetry a similar change has been applied to the IPv4 address resolve path.
Process address resolve requests at least one time per second in ibcore.
When setting a large address resolve timeout it was observed that the
address resolving would succeed at the timeout and not when the address
was available. Make sure the address resolving requests are processed no
slower than one time every second.
While at it use "int" for jiffies instead of "unsigned long" to match
FreeBSD ticks.
Bruce Evans [Tue, 17 Jul 2018 07:42:14 +0000 (07:42 +0000)]
Add a macro nan_mix() and use it to get NaN results that are (bitwise)
independent of the precision in most cases. This is mainly to simplify
checking for errors. r176266 did this for e_pow[f].c using a less
refined expression that often didn't work. r176276 fixes an error in
the log message for r176266. The main refinement is to always expand
to long double precision. See old log messages (especially these 2)
and the comment on the macro for more general details.
Specific details:
- using nan_mix() consistently for the new and old pow*() functions was
the only thing needed to make my consistency test for powl() vs pow()
pass on amd64.
- catrig[fl].c already had all the refinements, but open-coded.
- e_atan2[fl].c, e_fmod[fl].c and s_remquo[fl] only had primitive NaN
mixing.
- e_hypot[fl].c already had a different refined version of r176266. Refine
this further. nan_mix() is not directly usable here since we want to
clear the sign bit.
- e_remainder[f].c already had an earlier version of r176266.
- s_ccosh[f].c,/s_csinh[f].c already had a version equivalent to r176266.
Refine this further. nan_mix() is not directly usable here since the
expression has to handle some non-NaN cases.
- s_csqrt.[fl]: the mixing was special and mostly wrong. Partially fix the
special version.
Revert 336358 and step away fron machine for the day...
VERSREQ < 7.+ physically will not work with new config(8) due to major bump,
which is why I bumped it in the first place... Back to the original version
Rick Macklem [Mon, 16 Jul 2018 21:32:50 +0000 (21:32 +0000)]
Modify the reasons for not issuing a delegation in the NFSv4.1 server.
The ESXi NFSv4.1 client will generate warning messages when the reason for
not issuing a delegation is two. Two refers to a resource limit and I do
not see why it would be considered invalid. However it probably was not the
best choice of reason for not issuing a delegation.
This patch changes the reasons used to ones that the ESXi client doesn't
complain about. This change does not affect the FreeBSD client and does
not appear to affect behaviour of the Linux NFSv4.1 client.
RFC5661 defines these "reasons" but does not give any guidance w.r.t. which
ones are more appropriate to return to a client.
config-generated hints.c/env.c from r335998 and later are incompatible with
earlier kernels due to no longer setting envmode/hintmode. A minor bump for
this is insufficient, as matching major version with a later minor version
is still viewed as backwards-compatible.
This was an MI kernel change, soo all VERSREQ's are bumped.
sysrc(8): Send error message to stderr (not stdout)
PR: bin/229806
Reported by: Andreas Sommer <andreas.sommer87@googlemail.com>
MFC after: 3 days
X-MFC-to: stable/11 stable/10 stable/9
Sponsored by: Smule, Inc.
Andrew Turner [Mon, 16 Jul 2018 18:21:29 +0000 (18:21 +0000)]
Don't use the static keyword with DPCPU defines in arm64 modules.
On arm64 compiler will create PC-relative loads and stores for static data.
This means it doesn't emit a relocation. Unfortunately the in-kernel linker
expects there to be one for DPCPU defines so it can modify its value so the
code will use the correct DPCPU region.
To workaround the lack of a relocation with static data remove it when
building modules on arm64. The kernel is unaffected as it doesn't rely on
modifying these relocations to find the data.
PR: 225684
Reported by: Johannes Lundberg <johalun0@gmail.com>
Reported by: Jose Luis Duran <jlduran@gmail.com>
Reported by: Greg V <greg@unrelenting.technology>
Reviewed by: bz
Sponsored by: ABT Systems Ltd
Differential Revision: https://reviews.freebsd.org/D16145
Andrew Turner [Mon, 16 Jul 2018 15:39:33 +0000 (15:39 +0000)]
Create an empty stdint.h for arm_neon.h to include.
The armv8crypto module includes arm_neon.h for the compiler intrinsic
functions. This includes the userland stdint.h file that doesn't exist in
the kernel. Fix this by providing an empty stdint.h to be used when we
include arm_neon.h.
Alex Richardson [Mon, 16 Jul 2018 10:57:26 +0000 (10:57 +0000)]
No longer install sys/nv.h and sys/cnv.h in lib/libnv/Makefile
Use tools/build/Makefile to install the headers into ${WORLDTMP}/legacy
instead. Compared to r336026 this has the minor advantage that it avoids
unncessary header installation when building the non-bootstrap libnv.
indent(1): rewrite the integer/floating constant scanning part of lexi.c
Remove procedural code that did the scanning, which was faulty and didn't
support complex constants such as 0x1p-61. Replace it with a finite state
machine expressed as a transition table. The table was rewritten by hand
from lx's output, given parts of grammar expressed as regular expressions.
lx is Katherine Flavel's lexer generator, currently available at
https://github.com/katef/libfsm and the parts of grammar were taken from
http://quut.com/c/ANSI-C-grammar-l-2011.html and extended to support binary
integer constants which are a popular GCC extension.
ig4(4) does not support suspend/resume but present on the hardware where
such functionality is critical, like laptops. Remove PNP info to avoid
breaking suspend/resume on the systems where ig4(4) load is not explicitly
requested by the user.
Michael Tuexen [Sun, 15 Jul 2018 20:41:16 +0000 (20:41 +0000)]
Don't require a local sshd for the local TCP state dtrace test
This change is similar to the one done in r286171 for
tst.ipv4localtcp.ksh. This not only reduces the requirements on the
system used for testing but results also in a graceful teardown of
the TCP connection.
Reviewed by: gnn@
Sponsored by: Netflix, Inc.
Differential Revision: https://reviews.freebsd.org/D16276
Michael Tuexen [Sun, 15 Jul 2018 20:34:22 +0000 (20:34 +0000)]
Fix the UDP tests for dtrace.
The code imported from opensolaris was depending on ping supporting
UDP for sending probes. Since this is not supported by ping on FreeBSD
use a perl script instead.
The remote test requires the usage of ksh93, so state that in the
sheband.
Enable the local test, but keep the remote test disabled, since it
requires a remote machine on the LAN.
Alan Cox [Sun, 15 Jul 2018 19:25:15 +0000 (19:25 +0000)]
Test PGA_REFERENCED after calling pmap_ts_referenced(), rather than before,
so that a reference from a concurrently destroyed mapping is observed
during the current scan.
Marius Strobl [Sun, 15 Jul 2018 19:04:23 +0000 (19:04 +0000)]
Assorted TSO fixes for em(4)/iflib(9) and dead code removal:
- Ever since the workaround for the silicon bug of TSO4 causing MAC hangs
was committed in r295133, CSUM_TSO always got disabled unconditionally
by em(4) on the first invocation of em_init_locked(). However, even with
that problem fixed, it turned out that for at least e. g. 82579 not all
necessary TSO workarounds are in place, still causing MAC hangs even at
Gigabit speed. Thus, for stable/11, TSO usage was deliberately disabled
in r323292 (r323293 for stable/10) for the EM-class by default, allowing
users to turn it on if it happens to work with their particular EM MAC
in a Gigabit-only environment.
In head, the TSO workaround for speeds other than Gigabit was lost with
the conversion to iflib(9) in r311849 (possibly along with another one
or two TSO workarounds). Yet at the same time, for EM-class MACs TSO4
got enabled by default again, causing device hangs. Therefore, change the
default for this hardware class back to have TSO4 off, allowing users
to turn it on manually if it happens to work in their environment as
we do in stable/{10,11}. An alternative would be to add a whitelist of
EM-class devices where TSO4 actually is reliable with the workarounds in
place, but given that the advantage of TSO at Gigabit speed is rather
limited - especially with the overhead of these workarounds -, that's
really not worth it. [1]
This change includes the addition of an isc_capabilities to struct
if_softc_ctx so iflib(9) can also handle interface capabilities that
shouldn't be enabled by default which is used to handle the default-off
capabilities of e1000 as suggested by shurd@ and moving their handling
from em_setup_interface() to em_if_attach_pre() accordingly.
- Although 82543 support TSO4 in theory, the former lem(4) didn't have
support for TSO4, presumably because TSO4 is even more broken in the
LEM-class of MACs than the later EM ones. Still, TSO4 for LEM-class
devices was enabled as part of the conversion to iflib(9) in r311849,
causing device hangs. So revert back to the pre-r311849 behavior of
not supporting TSO4 for LEM-class at all, which includes not creating
a TSO DMA tag in iflib(9) for devices not having IFCAP_TSO4 set. [2]
- In fact, the FreeBSD TCP stack can handle a TSO size of IP_MAXPACKET
(65535) rather than FREEBSD_TSO_SIZE_MAX (65518). However, the TSO
DMA must have a maxsize of the maximum TSO size plus the size of a
VLAN header for software VLAN tagging. The iflib(9) converted em(4),
thus, first correctly sets scctx->isc_tx_tso_size_max to EM_TSO_SIZE
in em_if_attach_pre(), but later on overrides it with IP_MAXPACKET
in em_setup_interface() (apparently, left-over from pre-iflib(9)
times). So remove the later and correct iflib(9) to correctly cap
the maximum TSO size reported to the stack at IP_MAXPACKET. While at
it, let iflib(9) use if_sethwtsomax*().
This change includes the addition of isc_tso_max{seg,}size DMA engine
constraints for the TSO DMA tag to struct if_shared_ctx and letting
iflib_txsd_alloc() automatically adjust the maxsize of that tag in case
IFCAP_VLAN_MTU is supported as requested by shurd@.
- Move the if_setifheaderlen(9) call for adjusting the maximum Ethernet
header length from {ixgbe,ixl,ixlv,ixv,em}_setup_interface() to iflib(9)
so adjustment is automatically done in case IFCAP_VLAN_MTU is supported.
As a consequence, this adjustment now is also done in case of bnxt(4)
which missed it previously.
- Move the reduction of the maximum TSO segment count reported to the
stack by the number of m_pullup(9) calls (which in the worst case,
can add another mbuf and, thus, the requirement for another DMA
segment each) in the transmit path for performance reasons from
em_setup_interface() to iflib_txsd_alloc() as these pull-ups are now
done in iflib_parse_header() rather than in the no longer existing
em_xmit(). Moreover, this optimization applies to all drivers using
iflib(9) and not just em(4); all in-tree iflib(9) consumers still
have enough room to handle full size TSO packets. Also, reduce the
adjustment to the maximum number of m_pullup(9)'s now performed in
iflib_parse_header().
- Prior to the conversion of em(4)/igb(4)/lem(4) and ixl(4) to iflib(9)
in r311849 and r335338 respectively, these drivers didn't enable
IFCAP_VLAN_HWFILTER by default due to VLAN events not being passed
through by lagg(4). With iflib(9), IFCAP_VLAN_HWFILTER was turned on
by default but also lagg(4) was fixed in that regard in r203548. So
just remove the now redundant and defunct IFCAP_VLAN_HWFILTER handling
in {em,ixl,ixlv}_setup_interface().
- Nuke other redundant IFCAP_* setting in {em,ixl,ixlv}_setup_interface()
which is (more completely) already done in {em,ixl,ixlv}_if_attach_pre()
now.
- Remove some redundant/dead setting of scctx->isc_tx_csum_flags in
em_if_attach_pre().
- Remove some IFCAP_* duplicated either directly or indirectly (e. g.
via IFCAP_HWCSUM) in {EM,IGB,IXL}_CAPS.
- Don't bother to fiddle with IFCAP_HWSTATS in ixgbe(4)/ixgbev(4) as
iflib(9) adds that capability unconditionally.
- Remove some unused macros from em(4).
- Bump __FreeBSD_version as some of the above changes require the modules
of drivers using iflib(9) to be recompiled.
Okayed by: sbruno@ at 201806 DevSummit Transport Working Group [1]
Reviewed by: sbruno (earlier version), erj
PR: 219428 (part of; comment #10) [1], 220997 (part of; comment #3) [2]
Differential Revision: https://reviews.freebsd.org/D15720
Rick Macklem [Sun, 15 Jul 2018 18:54:44 +0000 (18:54 +0000)]
Shut down the TCP connection to a DS in the pNFS client when Renew fails.
When a NFSv4.1 client mount using pNFS detects a failure trying to do a
Renew (actually just a Sequence operation), the code would simply try
again and again and again every 30sec.
This would tie up the "nfscl" thread, which should also be doing other
things like Renews on other DSs and the MDS.
This patch adds code which closes down the TCP connection and marks it
defunct when Renew detects an failure to communicate with the DS, so
further Renews will not be attempted until a new working TCP connection to
the DS is established.
It also makes the call to nfscl_cancelreqs() unconditional, since
nfscl_cancelreqs() checks the NFSCLDS_SAMECONN flag and does so while holding
the lock.
This fix only applies to the NFSv4.1 client whne using pNFS and without it
the only effect would have been an "nfscl" thread busy doing Renew attempts
on an unresponsive DS.
Marius Strobl [Sun, 15 Jul 2018 18:03:56 +0000 (18:03 +0000)]
Remove code to disable IFCAP_VLAN_HWFILTER by default for ixgbe(4) as VLAN
events are passed through by lagg(4) ever since r203548. Deactivation of
this capability by default due to lagg(4) was already not done for ixgbev(4)
and has been - although inadvertently - broken when em(4)/igb(4)/lem(4) and
ixl(4) were converted to iflib(9) in r311849 and r335338 respectively.
Warner Losh [Sun, 15 Jul 2018 05:29:39 +0000 (05:29 +0000)]
Use EF_SEG_READ_STRING instead of EF_SEG_READ when reading strings.
Normally, we can get away with just reading the 1k buffer for the
string, since the placement of the data is generally no where near the
end of the file. However, it's possible that the string is within the
last 1k of the file, in which case the read will fail, and we'll not
produce the proper records needed for devmatch to work. By reading
using EF_SEG_READ_STRING, we automatically work around these problems
while still retaining safety.
This fix a problem with devmatch where we wouldn't load certain
modules (like ums). This didn't always happen (my tree didn't exhibit
it, while nathan's did because his optimization options were more
agressive).
Matt Macy [Sun, 15 Jul 2018 00:47:06 +0000 (00:47 +0000)]
acquire inp lock around ip6_pcbopt to fix IPV6_TCLASS panic
Simple fix to address panics relating to setting IPV6_TCLASS
with setsockopt(). The premise of this change is that it is
ok to call malloc with M_NOWAIT while holding a lock on the
in6p.
If it later turns out that it is not ok, then major surgery
will be required, as ip6_setpktopt() will have to be fixed
(as it also calls malloc with M_NOWAIT) which pulls in the
ip6_pcbopts(), ip6_setpktopts(), ip6_setpktopt() call chain.
Matt Macy [Sun, 15 Jul 2018 00:23:10 +0000 (00:23 +0000)]
msun: add ld80/ld128 powl, cpow, cpowf, cpowl from openbsd
This corresponds to the latest status (hasn't changed in 9+
years) from openbsd of ld80/ld128 powl, and source cpowf, cpow,
cpowl (the complex power functions for float complex, double
complex, and long double complex) which are required for C99
compliance and were missing from FreeBSD. Also required for
some numerical codes using complex numbered Hamiltonians.
Thanks to jhb for tracking down the issue with making
weak_reference compile on powerpc.
When asked to review, bde said "I don't like it" - but
provided no actionable feedback or superior implementations.
Alan Cox [Sat, 14 Jul 2018 20:14:00 +0000 (20:14 +0000)]
Invalidate the mapping before updating its physical address.
Doing so ensures that all threads sharing the pmap have a consistent
view of the mapping. This fixes the problem described in the commit
log message for r329254 without the overhead of an extra page fault
in the common case. (Now that all pmap_enter() implementations are
similarly modified, the workaround added in r329254 can be removed,
reducing the overhead of COW faults.)
With this change we can reuse the PV entry from the old mapping,
potentially avoiding a call to reclaim_pv_chunk(). Otherwise, there is
nothing preventing the old PV entry from being reclaimed. In rare
cases this could result in the PTE's page table page being freed,
leading to a use-after-free of the page when the updated PTE is written
following the allocation of the PV entry for the new mapping.
Rick Macklem [Sat, 14 Jul 2018 19:51:44 +0000 (19:51 +0000)]
Fix the pNFS client when mirrors aren't on the same machine.
Without this patch, the client side NFSv4.1 pNFS code erroneously did writes
and commits to both DS mirrors using the TCP connection of the first one.
For my test setup this worked, since I have both DSs running on the same
machine, but it would have failed when the DSs are on separate machines.
This patch fixes the code to use the correct TCP connection for each DS.
This patch should only affect the NFSv4.1 client when using "pnfs" mounts
to mirrored DSs.
Michael Tuexen [Sat, 14 Jul 2018 19:49:14 +0000 (19:49 +0000)]
Fix shebangs and execute bit of test scripts.
Since we don't have /usr/bin/ksh, use a generic way of specifying
ksh. Some of the tests only run with ksh93, so use this shell
for these tests. Two of the tests don't have the execute bit set,
so fix this, too.
Reviewed by: markj@
Sponsored by: Netflix, Inc.
Differential Revision: https://reviews.freebsd.org/D16270
Alan Cox [Sat, 14 Jul 2018 17:20:27 +0000 (17:20 +0000)]
Add support for pmap_enter(..., psind=1) to the i386 pmap. In other words,
add support for explicitly requesting that pmap_enter() create a 2 or 4 MB
page mapping. (Essentially, this feature allows the machine-independent
layer to create superpage mappings preemptively, and not wait for automatic
promotion to occur.)
Export pmap_ps_enabled() to the machine-independent layer.
Add a flag to pmap_pv_insert_pde() that specifies whether it should fail or
reclaim a PV entry when one is not available.
Refactor pmap_enter_pde() into two functions, one by the same name, that is
a general-purpose function for creating PDE PG_PS mappings, and another,
pmap_enter_4mpage(), that is used to prefault 2 or 4 MB read- and/or
execute-only mappings for execve(2), mmap(2), and shmat(2).
Michael Tuexen [Sat, 14 Jul 2018 17:12:04 +0000 (17:12 +0000)]
Add support for TCP state names used by Solaris.
For compatibility, add the TCP state names used by Solaris
and given in the Dtrace Guide available at
https://docs.oracle.com/cd/E37838_01/html/E61035/glhgu.html#OSDTGglhmv
Reviewed by: markj@
Sponsored by: Netflix, Inc.
Differential Revision: https://reviews.freebsd.org/D16269
Remove RIPEMD-160 fingerprint modules for veriexec, since it has very
little practical use and would not be recommended for anyone to use in
a production environment.
Mark Johnston [Sat, 14 Jul 2018 16:06:53 +0000 (16:06 +0000)]
Fix vnic fallback PHY name matching after r334880.
In some cases it seems that the PHY mode can only be identified by
matching against the corresponding device node name in the FDT. r334880
broke this for the case where the node name contains a unit address.
Fix the problem by allowing a match in that case.
It can occur during ordinary use of softupdates, or perhaps if writes to the
underlying media fail (causing bufs to be redirtied). Either way, it is not
particularly actionable.
Synproxy was accidentally broken by r335569. The 'return (action)' must be
executed for every non-PF_PASS result, but the error packet (TCP RST or ICMP
error) should only be sent if the packet was dropped (i.e. PF_DROP) and the
return flag is set.
PR: 229477
Submitted by: Andre Albsmeier <mail AT fbsd.e4m.org>
MFC after: 1 week
When shutting down a vnet jail pf_shutdown() clears the remaining states, which
through pf_clear_states() calls pf_unlink_state().
For synproxy states pf_unlink_state() will send a TCP RST, which eventually
tries to schedule the pf swi in pf_send(). This means we can't remove the
software interrupt until after pf_shutdown().
Warner Losh [Sat, 14 Jul 2018 06:43:37 +0000 (06:43 +0000)]
Minor adjustments:
o Fix the parsing of the device path. a last minute change terminated
it too soon.
o Kill setting LINES. We don't need to do it, and even if we did hard
coding it to 24 is wrong.
o Now that the console is working again for the loader, adjust the
printfs to be more in line with other platforms.
Warner Losh [Sat, 14 Jul 2018 01:46:19 +0000 (01:46 +0000)]
Add reporting of whether or not a keyboard is detected. In addition,
note that r336270's commit message was slightly incorrect. It changed
the default setting of the console to honor the ConOut
variable. Overrides via the command line are still possible, and we
use the devices in ConOut to set the proper console. If, for example,
serial cosnole is specified, we'll set console to "efi" if ConOut has
a serial port list and to either "efi comconsole" or "comconsole efi"
if not depending on whether -D or -D -h was specified.
Warner Losh [Sat, 14 Jul 2018 00:40:38 +0000 (00:40 +0000)]
uefi stand: Guess the console better
For server machines, ComOut is set to the set of devices that the efi
console suppots. Parse it to see if we have serial, video or both.
Make that take precidence over the command line args. boot1.efi parses
them, but loader.efi doesn't. It's not clear where to read boot.conf
from, so we don't do that. The command line args can still be set via
efibootmgr, which is more inline with the UEFI boot manager to replace
that. These args are typically used only to set serial vs video and
the com speed line. We can infer that from ComOut, so do so.
Remember the com speed and hw.uart.console to match.
Rick Macklem [Fri, 13 Jul 2018 20:03:05 +0000 (20:03 +0000)]
Close down the TCP connection to a pNFS DS when it is disabled.
So long as the TCP connection to a pNFS DS isn't shared with other DSs,
it can be closed down when the DS is being disabled in the pNFS client.
This causes any RPCs in progress to fail.
This patch only affects the NFSv4.1 pNFS client when errors occur
while doing I/O on a DS.
Warner Losh [Fri, 13 Jul 2018 18:19:33 +0000 (18:19 +0000)]
Use if rather than case for a simple boolean. gcc thinks blks is
undefined sometimes with the case, but enc is always 0 or 1, so
and if / else is better anyway.
Ian Lepore [Fri, 13 Jul 2018 17:50:25 +0000 (17:50 +0000)]
Extend loader(8) geli support to all architectures and all disk-like devices.
This moves the bulk of the geli support from lib386/biosdisk.c into a new
geli/gelidev.c which implements a devsw-type device whose dv_strategy()
function handles geli decryption. Support for all arches comes from moving
the taste-and-attach code to the devopen() function in libsa.
After opening any DEVT_DISK device, devopen() calls the new function
geli_probe_and_attach(), which will "attach" the geli code to the open_file
struct by creating a geli_devdesc instance to replace the disk_devdesc
instance in the open_file. That routes all IO for the device through the
geli code.
A new public geli_add_key() function is added, to allow arch/vendor-specific
code to add keys obtained from custom hardware or other sources.
With these changes, geli support will be compiled into all variations of
loader(8) on all arches because the default is WITH_LOADER_GELI.
Warner Losh [Fri, 13 Jul 2018 17:41:28 +0000 (17:41 +0000)]
There's two files in the sys tree named inflate.c, in addition
to it being a common name elsewhere. Rename the old kzip one
to subr_inflate.c.
This actually fixes the build issues on sparc64 that my inclusion of
.PATH ${SYSDIR}/kern created in r336244, so also revert the broken
workaround I committed in r336249.
This slipped passed me because apparently, I never did a clean build.
Alan Cox [Fri, 13 Jul 2018 17:12:50 +0000 (17:12 +0000)]
Invalidate the mapping before updating its physical address.
Doing so ensures that all threads sharing the pmap have a consistent
view of the mapping. This fixes the problem described in the commit
log message for r329254 without the overhead of an extra fault in the
common case. (Once the riscv pmap_enter() implementation is similarly
modified, the workaround added in r329254 can be removed, reducing the
overhead of CoW faults.)
See also r335784 for amd64. The mips implementation of pmap_enter()
already reused the PV entry from the old mapping.
projects / FreeBSD / FreeBSD.git / log